View Issue Details

IDProjectCategoryView StatusLast Update
0016961FPCPackagespublic2010-07-19 19:38
ReporterDmitry Boyarintsev Assigned ToJonas Maebe  
PrioritynormalSeveritytweakReproducibilityhave not tried
Status closedResolutionfixed 
Fixed in Version2.6.0 
Summary0016961: OpenAL for Darwin (MacOSX, iOS) framework usage patch
DescriptionThe patch simplifies OpenAL usage under OSX.

There's OpenAL framework in MacOSX (iOS) by default so dynamic linking can be used. Though no dynamic library file should be used.

Without the patch static library is required by default for OSX OpenAL.
TagsNo tags attached.
Fixed in Revision15611
FPCOldBugId
FPCTarget
Attached Files

Activities

2010-07-17 12:32

 

openal.patch (629 bytes)   
Index: src/openal.pas
===================================================================
--- src/openal.pas	(revision 15448)
+++ src/openal.pas	(working copy)
@@ -16,10 +16,18 @@
   {$DEFINE DYNLINK}
 {$ENDIF}
 
+{$IFDEF DARWIN}
+  {$DEFINE DYNLINK}
+{$ENDIF}
+
 {$IFDEF DYNLINK}
 const
 {$IF Defined(WINDOWS)}
   openallib = 'openal32.dll';
+{$ELSEIF Defined(DARWIN)}
+  openallib = '/System/Library/Frameworks/OpenAL.framework/OpenAL';
+  {$UNDEF DYNLINK}
+  {$LINKFRAMEWORK OpenAL}
 {$ELSEIF Defined(UNIX)}
   openallib = 'libopenal.so';
 {$ELSE}
@@ -35,4 +43,4 @@
 
 implementation
 
-end.
\ No newline at end of file
+end.
openal.patch (629 bytes)   

2010-07-18 11:59

 

openal2.patch (488 bytes)   
Index: src/openal.pas
===================================================================
--- src/openal.pas	(revision 15574)
+++ src/openal.pas	(working copy)
@@ -16,7 +16,7 @@
   {$DEFINE DYNLINK}
 {$ENDIF}
 
-{$IFDEF DYNLINK}
+{$IF Defined(DYNLINK)}
 const
 {$IF Defined(WINDOWS)}
   openallib = 'openal32.dll';
@@ -25,6 +25,8 @@
 {$ELSE}
   {$MESSAGE ERROR 'DYNLINK not supported'}
 {$IFEND}
+{$ELSEIF Defined(Darwin)}
+{$linkframework OpenAL}
 {$ELSE}
   {$LINKLIB openal}
 {$ENDIF}
openal2.patch (488 bytes)   

Jonas Maebe

2010-07-18 11:59

manager   ~0039429

Does the attached patch also work?

Dmitry Boyarintsev

2010-07-19 08:05

developer   ~0039442

yes, it does work.

But isn't linking a framework is dynamic loading, rather than statick linking?
How should the header change if someone would really like to use a static OpenAL library (i.e. custom OSX library build)?

Jonas Maebe

2010-07-19 11:40

manager   ~0039446

> But isn't linking a framework is dynamic loading, rather than statick linking?

First, let's get the terminology disambiguated:
* static linking mean linking in a static library (libOpenAL.a), which means that all object files from libOpenAL.a that are required by the program are linked into the program. At run time, no extra files are required
* dynamic linking means that you tell the linker the name of the dynamic library to link against. At run time, the program will look for the library in the "install location" of the library you linked against at compile time (in case of a system library, that's the same place where it's installed by default)
* dynamic loading means that you do not tell the linker to link against any library, but that you programmatically load the required library at run time using the functionality from e.g. the dynlibs unit

The current OpenAL unit simply contains {$linklib openal}. That means, on Mac OS X, that the linker will first search in the linker's library path for libopenal.dylib (dynamic library), and if it cannot find it, it will look for libopenal.a (static library).

My patch instead tells the linker that it should use the OpenAL framework, for which it will look in the standard framework search path. Your patch does exactly the same as my patch, except that it's a bit more complex -- note that your "openallib" definition is not used anywhere, since its use is ifdef'ed by DYNLINK in all of the include files, and moreover on Mac OS X you need an explicit {$linklib openal} anyway.

You cannot create a single unit that is usable both for linking against a framework and against a static library. For that, you have to create two separate units.

Dmitry Boyarintsev

2010-07-19 14:38

developer   ~0039460

Sure, I can see that your patch does exactly the same. My initial thought was exactly the same patch as you did, but then I started to doubt.

But i cannot agree with you that it's impossible to create the single unit. OpenAL is example of such unit
If one removes all {$linklib} and {$linkframework} from the header, he/she is able to control linking a static library or framework via FPC (linker) command-line. No changes in the code is required in this case.

Anyway, I have absolutely no objections against your patch, please apply.

Jonas Maebe

2010-07-19 16:18

manager   ~0039462

Ok, it's applied.

You're right that if we allow the choice between {$linklib ..} and {$linkframework ..} to the user of the unit, that the same unit can be used for both. That would however be inconsistent with how all of the other "C library interface" units in the packages dir work...

Issue History

Date Modified Username Field Change
2010-07-17 12:32 Dmitry Boyarintsev New Issue
2010-07-17 12:32 Dmitry Boyarintsev File Added: openal.patch
2010-07-18 11:59 Jonas Maebe File Added: openal2.patch
2010-07-18 11:59 Jonas Maebe Note Added: 0039429
2010-07-18 11:59 Jonas Maebe Status new => feedback
2010-07-19 08:05 Dmitry Boyarintsev Note Added: 0039442
2010-07-19 11:40 Jonas Maebe Note Added: 0039446
2010-07-19 14:38 Dmitry Boyarintsev Note Added: 0039460
2010-07-19 16:18 Jonas Maebe Fixed in Revision => 15611
2010-07-19 16:18 Jonas Maebe Status feedback => resolved
2010-07-19 16:18 Jonas Maebe Fixed in Version => 2.5.1
2010-07-19 16:18 Jonas Maebe Resolution open => fixed
2010-07-19 16:18 Jonas Maebe Assigned To => Jonas Maebe
2010-07-19 16:18 Jonas Maebe Note Added: 0039462
2010-07-19 19:38 Dmitry Boyarintsev Status resolved => closed