[Monetdb-developers] MonetDB(5) and modules
I noticed that MonetDB5 uses modules, but compiles them as shared libraries. Maybe other targets do the same here. autogen appears to have (had) some partial support for modules, and the attached patch fixes/re-enables that support. In short it passes -module to libtool during link phase, such that the object is generated as loadable module. Why did I look at this? Mainly because on Darwin there is a difference between those objects that are loaded by dlopen(3) (loadable modules) and those that are used by the link editor ld(1) (shared libraries). The latter have type DYLIB whereas the former have type MH_BUNDLE. A so-called "bundle" doesn't have an install_name, as it can't be used by the link editor. Now initially all went well during compilation until I hit this error: /Library/Gentoo/usr/bin/ld: ../atoms/.libs/lib_color.so is input for the dynamic link editor, is not relocatable by the static link editor again This message is correct on Darwin, as batcolor.mx links against lib_color.so. libtool already detected this case: *** Warning: Linking the shared library lib_batcolor.la against the loadable module *** lib_color.so is not portable! ** Warning, lib lib_color.so is a module, not a shared library ** And there doesn't seem to be a static archive available ** The link will probably fail, sorry I don't recall ever seeing problems with these loads (apart from on Panther which didn't grok it at all) on my (as of today out-of-date) OSX 10.4, so I'm not sure how relevant it is to actually fix this. It looks like support to load shared libraries via dlopen actually was added, so we need not to worry about it at all. Actually, the man-page says it all: "dlopen() can load dynamic libraries and bundles." "In Mac OS X 10.4, dlopen was rewritten to be a native part of dyld." So far for sharing my experiences in this area. As far as I know, 10.3 support for MonetDB was shot already long ago (as it should), so maybe we should remove the remaining bits that could/can trigger -module libtool invocation, as it *will* cause trouble.
participants (1)
-
Fabian Groffen