Hi,
One other thing. We went and added a bunch of MacOSX specific things
to move away from the standard unix dlfcn.h functions for loading
shared libraries all throughout the code and in its place we used
NSAddImage and its friends to handle shared library loading.
The funny thing is that now for MacOSX 10.4, Apple has deprecated the
entire use of NSAddImage completely and wants everyont to actually
use the dlfcn.h style functions instead for shared library loading.
Here are the snippets from the MacOSX developer website:
Quote:
The functions described in this section are declared in /usr/include/
mach-o/dyld.h. The use of these functions is discouraged. You should
use the more efficient functions described in “Dynamic Loader
Compatibility Functions”.
NSAddImage
Adds the specified Mach-O image to the currently running process.
NSAddLibrary
Adds a dynamic shared library to the search list.
NSAddLibraryWithSearching
Adds a dynamic shared library to the search list—using the various
dyld environment variables—as if the library were linked into the
program.
NSAddressOfSymbol
Returns the address in the program’s address space of the data
represented by the given symbol. The data may be a variable, a
constant, or the first instruction of a function.
NSLibraryNameForModule
Returns the name of the library that contains the given module.
NSLookupSymbolInImage
Returns a reference to the specified symbol from the specified image.
NSNameOfSymbol
Returns the name of the given symbol.
Quote:
Dynamic Loader Compatibility Functions
These are the recommended functions to use to interact with the
dynamic loader. These functions work in Mac OS X v10.3 and v10.4.
However, in Mac OS X v10.4 they are more efficient that other image-
loading functions. These functions are declared in /usr/include/dlfcn.h.
dladdr
Finds the image and nearest symbol corresponding to an address.
Available only in dynamically linked programs.
dlclose
Closes a dynamic library or bundle.
dlerror
Provides diagnostic information corresponding to problems with calls
to dlopen, dlsym, and dlclose in the same thread.
dlopen
Loads and links a dynamic library or bundle.
dlsym
Returns the address of a symbol.
These are standard unix shared library functions. Which means we
should be able to remove most if not all of the MACOSX specific
ifdefs in sal/osl/unx/module.c and in all of the other places that
load shared libraries (such as the vcl code for adding X11
extensions, etc).
This should help reduce the amount of MacOSX specific code to support.
What do people think?
Kevin
On Oct 21, 2005, at 9:15 AM, Kevin B. Hendricks wrote:
Hi,
I think that adding synchronization in module.c patch is just fine
here. There is nothing global being used in the code as far as I
can tell that would prevent it from being re-entrant. So the calls
to NSAddImage which are internal MacOSX routines must be the
culprit here. It would be interesting to look at the libdl code to
see if it uses a mutex when using similar functions. Any
additional overhead of obtaining a mutex would be meaningless next
to the time to actually load any shared library.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
