[Monetdb-developers] MonetDB(5) and modules

Fabian Groffen Fabian.Groffen at cwi.nl
Fri Oct 26 14:53:50 CEST 2007


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.
-------------- next part --------------
? p
Index: am.py
===================================================================
RCS file: /cvsroot/monetdb/buildtools/autogen/autogen/am.py,v
retrieving revision 1.57
diff -u -r1.57 am.py
--- am.py	22 Oct 2007 12:18:37 -0000	1.57
+++ am.py	26 Oct 2007 12:46:59 -0000
@@ -725,7 +725,7 @@
         fd.write(am_additional_install_libs(libname, sep, libmap["LIBS"], am))
 
     ldflags = []
-    if sep == '_' and pref == '':
+    if sep == '_':
         ldflags.append('-module')
     if libmap.has_key("LDFLAGS"):
         for x in libmap["LDFLAGS"]:
@@ -829,10 +829,15 @@
 
         if libsmap.has_key("LIBS"):
             _libs += libsmap["LIBS"];
-        if libsmap.has_key("LDFLAGS"):
-            _libs += libsmap["LDFLAGS"];
         if len(_libs) > 0:
             fd.write(am_additional_libs(libname, sep, "LIB", _libs, am))
+        ldflags = []
+        if sep == '_':
+            ldflags.append('-module')
+        if libsmap.has_key("LDFLAGS"):
+            ldflags += libsmap["LDFLAGS"];
+        if len(ldflags) > 0:
+            fd.write(am_additional_flags(libname, sep, "LIB", ldflags, am))
 ##        if sep == '_':
 ##            fd.write(am_additional_flags(libname, sep, "LIB", ['-module'], am))
 


More information about the developers-list mailing list