On Wed, 2002-10-09 at 16:15, Robert Boehne wrote: > Christoph, > > The patch against libtool.m4 is different from what is in > CVS branch-1-4. Does today's branch-1-4 have the problem > your patch intends to fix? It appears that this may > be fixed in CVS. > If you would, please get Libtool cvs branch-1-4, if you > don't have access to it for some reason, send me an email > (directly) and I'll mail you a tarball.
OK, here's essentially the same patch but against the 1.4 tree. Another thing I was wondering, while I'm at it. Darwin has a strange behavior in that there are two different ways that symbols can be created for the dynamic loader, either "flat" namespace, or "twolevel" namespace. It has something to do with the prebinding support that's built into the library dynamic loader for darwin and symbol clashes between libraries. (for more on what this means, see:) http://developer.apple.com/techpubs/macosx/ReleaseNotes/TwoLevelNamespaces.html Currently libtool forces it to the flat namespace, which will fix compilation with some older software that wasn't written with prebinding in mind, but it's really non-optimal. Is there any way we could add support for some type of command-line option to choose the twolevel namespace? There is currently no way to choose at build time other than to hack libtool, which is very non-optimal (and also means that the Darwin KDE tree could never be fully integrated into KDE mainline, since they will only accept libtool changes that have been accepted into libtool CVS or a release). I'm not sure if you have any way (or more importantly, if it breaks/bends libtools goals) of adding platform-specific flags or some other way to implementing choosing the namespace behaviour at link time, but that would be incredibly helpful. Forcing everything to a flat namespace is really a workaround for libraries that are doing dodgy things with public symbols, from what I understand.
Index: libtool.m4 =================================================================== RCS file: /cvsroot/libtool/libtool/libtool.m4,v retrieving revision 1.166.2.43 diff -u -b -r1.166.2.43 libtool.m4 --- libtool.m4 10 Sep 2002 13:50:54 -0000 1.166.2.43 +++ libtool.m4 9 Oct 2002 20:45:11 -0000 @@ -1583,7 +1583,7 @@ # cross-compilation, but unfortunately the echo tests do not # yet detect zsh echo's removal of \ escapes. Also zsh mangles # `"' quotes if we put them in here... so don't! - archive_cmds='$nonopt $(test .$module = .yes && echo -bundle || echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs $deplibs$linker_flags -install_name $rpath/$soname $verstring' + archive_cmds='$CC -r -keep_private_externs -nostdlib -o ${lib}-master.o $libobjs +&& $CC $(test .$module = .yes && echo -bundle || echo -dynamiclib) +$allow_undefined_flag -o $lib ${lib}-master.o $deplibs$linker_flags $(test .$module +!= .yes && echo -install_name $rpath/$soname $verstring)' # We need to add '_' to the symbols in $export_symbols first #archive_expsym_cmds="$archive_cmds"' && strip -s $export_symbols' hardcode_direct=yes Index: ltmain.in =================================================================== RCS file: /cvsroot/libtool/libtool/ltmain.in,v retrieving revision 1.259.2.24 diff -u -b -r1.259.2.24 ltmain.in --- ltmain.in 9 Sep 2002 18:27:14 -0000 1.259.2.24 +++ ltmain.in 9 Oct 2002 20:45:12 -0000 @@ -3175,6 +3175,14 @@ ;; esac + case $host in + *darwin*) + # Don't allow lazy linking, it breaks C++ global constructors + compile_command="$compile_command ${wl}-bind_at_load" + finalize_command="$finalize_command ${wl}-bind_at_load" + ;; + esac + compile_command="$compile_command $compile_deplibs" finalize_command="$finalize_command $finalize_deplibs"