GNOME Bugzilla – Bug 569085
Configure script uses wrong filename extension for plugins under Mac OS X
Last modified: 2011-09-04 12:05:00 UTC
Please describe the problem: The "configure.ac" of "babl" contains this incorrect code: { echo "$as_me:$LINENO: checking for some Win32 platform" >&5 echo $ECHO_N "checking for some Win32 platform... $ECHO_C" >&6; } case "$target_or_host" in *-*-darwin*) # darwin shrext=.dylib dynamiclib=-dynamiclib ;; As a result it uses the incorrect extensions for shared objects. ".dylib" is only the correct extensions for shared libraries. Plugins are not shared libraries. Steps to reproduce: 1. Extract sources 2. Run "./configure". Actual results: "SHREXT" in "extensions/Makefile" gets set to ".dylib". Expected results: "SHREXT" in "extensions/Makefile" gets set to ".so". Does this happen every time? Yes. Other information:
Created attachment 127206 [details] [review] Use the correct suffix for plugins under Mac OS X
The supplied patch is not good enough. "extensions/Makefile.am" also needs some work because plugins need to be built with different options under Mac OS X. The whole Makefile should be rewritten to use "libtool" properly.
The patch file is unusable in its current form as it is a diff between configure.ac and configure. Make the changes you feel are needed to configure.ac and provide a patch that was generated by comparing the modified and unmodified versions of the configure.ac file.
The patch is broken anyway as mentioned before. "extensions/Makefile" needs to be rewritten to use to "libtool" for building. Alternatively "configure.ac" and "extensions/Makefile.am" to be changed in way that the following settings are used under Mac OS X: 1.) "SHREXT" is set to ".so". 2.) "DYNAMICLIB" is set to "-bundle". 3.) "LDADD" is set to ""$(top_builddir)/babl/.libs/libbabl-$(BABL_API_VERSION).dylib $(MATH_LIB)". I'm sorry but my "autoconf" knowledge is not good enough for that.
Hi! Could you backup your claim about .dylib being the wrong extension? The GEGL plug-ins are just as much shared libraries as any shared library from a technical point of view.
Mac OS X doesn't use ELF it uses the Mach-O binary which works differently. There are (at least) three types of binaries: > file /usr/pkg/bin/wireshark /usr/pkg/bin/wireshark: Mach-O executable ppc > file /usr/pkg/lib/libwireshark.0.0.1.dylib /usr/pkg/lib/libwireshark.0.0.1.dylib: Mach-O dynamically linked shared library ppc > file /usr/pkg/lib/wireshark/plugins/1.0.4/ciscosm.so /usr/pkg/lib/wireshark/plugins/1.0.4/ciscosm.so: Mach-O bundle ppc The first is an executable. The second one is a shared library. The third one is a plugin that will be loaded by the application via dlopen(3). Correct me if I'm wrong but the files in "lib/babl-0.0" seem to belong in the third category.
Concur with extension analysis in Comment #6...there really are two different types of "shared libraries" on darwin, a distinction that is not present on ELF/linux platforms. The difference is essentially between a dyld-linked library and a runtime dlopen()ed module. The former is linked via -lFOO, is compiled with -dynamiclib, and gets extension .dylib in order to be recognized by gcc and ld. The latter is compiled with -bundle and *can* have any extension (it's up to whoever writes the dlopen() calls to know what filename to use). However, by convention, it's usually .so for most cross-platformish things, including gmodule access, libtool-driven build systems, and libltdl access. So the two types of things (linkable libs and loadable modules) need to be handled totally independently, not lumped together. libtool automatically Does It Correctly on all platforms (by default uses "whatever flag and extension is appropriate for building a linkable lib" unless -module is passed, in which case it uses "whatever flag and extension is appropriate for a dlopen()able module", and also provides the dlopen extension in a variable.
Even if programs can use arbitrary filename extension for bundles I would recomment to use ".so" nevertheless because that's the extension that "libtool" uses.
daniel's patch in bug #519610 is the right thing to do
We use libtool in a pretty straight-forward way when building now. Is the issue still present?
Fink no longer has extension-portability/libtool hacks in its babl-0.1.4 packaging.
Does that mean the issue is resolved?
Resolved for me (whereas previously fink *did* have a set of hacks because it did suffer from the reported bug). However, I'm not the reporter here.
The patch is no longer necessary, the bug can be closed. Sorry for not reporting this earlier. The package in "pkgsrc" was updated and the patch removed without be noticing.