Questions before I submit patches...
In porting KDE to MacOS X, we've exercised a lot of weird issues surrounding the interaction between libtool and apple's linker. I'd like to submit patches, but before I can, some of the hacks we've had to add need to be genericised for proper submission. One of the big issues is the flat/two-level namespace issue in more recent versions of Darwin (1.3, coincides with MacOS X 10.1) and higher. As an aside, if you want more on what two-level namespaces are, see: http://developer.apple.com/techpubs/macosx/DeveloperTools/ProjectBuilder/ProjectBuilder.help/Contents/Resources/English.lproj/Linker/Using_Two_L__Namespaces.html (that should be one line... sorry if it wraps) Many unix applications have nasty issues when two-level namespaces are in effect. However, if something *can* be built with two-level namespaces enabled, it would be preferable. The current default in libtool is to force everything to a flat namespace. It would seem the best thing to do is to have an option to allow you to decide which behavior to use at build time, so that software that is twolevel-compliant can enable it, and older software that doesn't understand that can still be used without changes with a newer libtool. This would mean adding an os-specific flag to a script that 99.9% of the time won't even be run on OSX, which kind of sucks, so I'm hoping you guys would have a better suggestion for an alternative. What is the best way to go about doing this and still be a nice neighbor? =) TIA, Benjamin Reed [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4.2 on Darwin
While we're on the subject of darwin and libtool, we've been needing to
make changes to libtool to make KDE compile on darwin that haven't been
discussed in this thread.
Darwin's GCC has a number of very weird states it can get into during
the linking stage because of it's crappy ld (grin), and I don't think
many things have exercised them until we tried to get something really
big to build with libtool.
Attached is a patch with some of the fixes that have gone into the
KDE-Darwin tree. I haven't done all of these changes myself, Dave
Vasilevsky (who has posted libtool patches previously, I think) is the
one who found most of these issues.
The libtool.m4 bit includes the fixed module test discussed here in the
last couple of days, as well as the -install_name bug, but it also fixes
some symbol issues when linking some C++ bits. It basically has to
implement a two-pass compile to make linking happy. The second part
(the ltmain.in bit) disables lazy linking because of C++ issues as well.
The patch is made against libtool CVS top-of-tree as of a few minutes
ago; if you have any problems with it or need changes, let me know. It
would be great to have darwin linking properly out-of-the-box with
libtool. =)
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.265
diff -u -b -r1.265 libtool.m4
--- libtool.m4 4 Oct 2002 15:34:50 - 1.265
+++ libtool.m4 8 Oct 2002 22:00:05 -
@@ -2631,6 +2631,12 @@
_LT_AC_TAGVAR(ld_shlibs, $1)=no
;;
+ darwin*)
+shared_flag='-dynamiclib'
+_LT_AC_TAGVAR(archive_cmds, $1)='$CC -r -keep_private_externs -nostdlib -o
+${lib}-master.o $libobjs && $CC -dynamiclib -install_name $rpath/$soname
+$predep_objects ${lib}-master.o $deplibs $postdep_objects $compiler_flags -o $lib'
+output_verbose_link_cmd='$CC -dynamiclib $CFLAGS -v conftest.$objext 2>&1 | egrep
+"\-L"'
+;;
+
dgux*)
case $cc_basename in
ec++)
@@ -4950,7 +4956,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!
- _LT_AC_TAGVAR(archive_cmds, $1)='$CC $(test .$module = .yes && echo -bundle ||
echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs $deplibs$linker_flags
-install_name $rpath/$soname $verstring'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$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
#_LT_AC_TAGVAR(archive_expsym_cmds, $1)="$_LT_AC_TAGVAR(archive_cmds, $1)"' &&
strip -s $export_symbols'
_LT_AC_TAGVAR(hardcode_direct, $1)=yes
Index: ltmain.in
===
RCS file: /cvsroot/libtool/libtool/ltmain.in,v
retrieving revision 1.301
diff -u -b -r1.301 ltmain.in
--- ltmain.in 25 Sep 2002 04:26:20 - 1.301
+++ ltmain.in 8 Oct 2002 22:00:06 -
@@ -3644,6 +3644,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"
Re: libtool 1.4.2 on Darwin
On Wednesday, October 9, 2002, at 01:20 AM, Christoph Egger wrote: >> so diff would be just in the last part around `-install_name >> $parth/$soname` >> > > Good to know. Is there an anonymous CVS access? If yes, where and how? > Then I could give you a diff against this branch, if merging makes you > trouble. The patch I posted yesterday for darwin contains the -install_name fixes already if you want to use that... ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4.2 on Darwin
> Yes, you already said that. The stuff above is about the libtool 1.4 > _branch_, while the libtool-darwin patch is in the mainstream development tree. Right, and I have not yet seen anything that said there will be a libtool 1.4.3 release, only that there will be a libtool release in general, so I posted the patch against the tree that it sounds like most development is going on in. It should be very easy to backport. > BTW: When will the first libtool version be released containing the > libtool-darwin patch officially? Got me, this is the first time I've ever even written anything to the libtool list I think, I'm just a lurker. =) I don't even know if anyone with commit access has looked at the patch, for that matter. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4.2 on Darwin
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 - 1.166.2.43
+++ libtool.m4 9 Oct 2002 20:45:11 -
@@ -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 - 1.259.2.24
+++ ltmain.in 9 Oct 2002 20:45:12 -
@@ -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"
Re: libtool 1.4.2 on Darwin
On Wed, 2002-10-09 at 19:10, Robert Boehne wrote: > If we added support for library namespace, all of the > Darwin developers would start developing software with > Libtool that used it, and therefore wouldn't link on > other systems, correct? I'm not claiming I have ever > seen a Mac running X+ so you'll have to correct me if I'm wrong. > Libtool's philosophy is mostly to provide the common > subset of linker/loader/compiler features, and to specifically > NOT support features that aren't available elsewhere. Now, > this isn't always the case, but if you wanted to add support > for library namespaces for other platforms *IN_Libtool* > then it would be reasonable, but more work. I doubt that > is possible anyway. Right, that's why there's a problem... libtool is already making the decision for developers on Darwin (to a flat namespace), but that's not always the best course of action; if possible it would be better to link with a twolevel namespace to not have symbol collisions in the future. The current behaviour is like libtool forcing -O0 on gcc because it's less likely to cause compilation errors. The flat namespace bit was added to libtool assumedly because early in Darwin's history with libtool it fixed some packages' building, but it's not necessarily optimal. Unfortunately I don't know the full consequences of changing it, which is why it would be nice to choose on the libtool command-line, and leave it up to developers. It could be a no-op on platforms that don't support multi-level namespaces (ie, every platform but Darwin), but let the developer choose if he is of a mind to. I don't have a problem with trying to hack this in, I expect it's not terribly difficult, but I don't think I could get a patch for you before any kind of release freeze, and I don't know in what manner (or if) it would play well with the way libtool implements these things. =) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4.2 on Darwin -- namespace support on the command-line
On Thu, 2002-10-10 at 11:11, Boehne, Robert wrote: > A similar case is the use of $ORIGIN/ in a hardcoded > library path. Not many OS's support it, and anyone > who depends on it would limit the possible supported > platform list down to only those that do. Ahh, I see what you're saying. No, that's not what I meant. > If Libtool supports this feature, anything that used > it would only link on Darwin (AFAICT), and that is > a very Bad Thing(tm). If your Darwin-specific package > uses Libtool, and requires this library namespace > feature, you shouldn't be using Libtool anyway. > Libtool isn't intended to wrap every OS specific feature, > it is intended to be a universal subset of linker > features that is common to any OS (or implemented > in Libtool itself). > > I wouldn't be inclined to accept a patch that simply > turned on this flag on Darwin when linking, but I would > be inclined to accept a patch that supported library > namespaces on every (or at leat most) platform known > to Libtool. The problem with that is technical, I don't > think it would be possible to do that. So I simply > suggest your efforts be concentrated elsewhere. This is what I was trying to say. You would have a libtool command-line that would be like: libtool --mode=link --namespace=flat gcc blah blah blah ...and on darwin, it would create a link line like: gcc -flat_namespace -undefined suppress blah blah blah ...and on all other platforms (which don't, as far as I'm aware, have a flat/twolevel namespace), it would create a line like: gcc blah blah blah i.e., the namespace flag would only apply to darwin, and wouldn't affect linking on any other platforms (unless some other platform was to implement library/symbol lookups in the way darwin does, in which case they would need to set whatever flags they need for namespace support). --namespace=foo would be implemented as something like: ---(snip!)--- case $namespace_arg in flat) case $host_os in *darwin*) lt_flags_namespace="-flat_namespace -undefined suppress" ;; esac ;; twolevel) case $host_os in *darwin*) lt_flags_namespace="" ;; esac ;; esac ---(snip!)--- consider that pseudocode, I don't understand libtool's naming conventions enough to say how it would look, but you get the general idea. This would make it safe to send the namespace flag upstream to developers whose packages are not darwin-linker-safe, and it would not break any other platforms then. Does that make sense? Is this something that jives with how libtool does things? ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool "module" behavior and darwin
One of the problems we're running into getting KDE working on Darwin is libtool's concept of a "module", and how it's mapped onto Darwin's linker behavior. On Darwin, unlike most other unixen (as far as I'm aware), loadable modules and dynamic shared libraries are 2 distinctly different entities, and are treated differently by the dynamic loader. Libtool translates this difference as: if the libtool command-line passes -module, it creates a Darwin "bundle", otherwise it creates a shared library. Both are PIC, but bundles cannot be linked against. To get around issues with prebinding and speed of C++ code loading, especially on linux, KDE creates many of it's executables as shared libraries, linked twice, once as a module and once a binary. So the "kbackgammon" program is kbackgammon.so and kbackgammon, with main() existing in kbackgammon.so, and kbackgammon being linked against the .so and an empty dummy.cpp file to make linkers happy as far as making a program. The problem comes when trying to build things the KDE way on Darwin -- a number of things get linked against these modules for other purposes (sharing code, symbol resolution, etc.) but Darwin can't do that. Darwin does not allow linking against bundles (modules), only against shared libraries. By default, probably hundreds of makefiles in KDE have lines like: ---(snip!)--- kbackgammon_la_LDFLAGS = $(all_libraries) $(KDE_RPATH) -module -avoid-version kbackgammon_LDADD = kbackgammon.la $(LIB_KDEGAMES) $(LIB_KSYCOCA) kbackgammon_SOURCES = dummy.cpp ---(snip!)--- ...this is a no-no, kbackgammon is trying to link against a bundle, and bombs with: ---(snip!)--- ld: ./.libs/kbackgammon.so is input for the dynamic link editor, is not relocatable by the static link editor again ---(snip!)--- I can change every one of these makefiles so that kbackgammon_la_LDFLAGS doesn't have -module on it, and it builds a shared library instead, but then KDE takes a (very noticable) performance hit in dlopening these big shared libraries compared to dlopening a bundle. If I remove kbackgammon altogether, and only build the .so, KDE's dlopening facilities will load the bundle version of kbackgammon.so just fine, and it's fast, but there's no way to run kbackgammon from the command-line or another app. We've been discussing this on the Fink project's irc channel, and it seem the most feasible solution (barring taking an off-the-cuff estimate of a 20 or 30% speed hit on loading apps) is to make it so that if libtool is trying to link against a bundle, it will link against the .a if it's available instead. While I and some of the other finkers have hacked on libtool some, I am not sure any of us even know where to start to implement this behavior in libtool. Do you guys have any pointers or suggestions as to where to make these changes, or a better way of handling this issue? ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool "module" behavior and darwin
On Sunday, November 24, 2002, at 04:54 PM, Guido Draheim wrote: The only hint that I can give has the form of a question: Did you try kbackgammon_LDADD = -static kbackgammon.la $(LIB_KDEGAMES) $(LIB_KSYCOCA) kbackgammon_SOURCES = dummy.cpp $ ./libtool --help --mode=link | grep static -all-static do not do any dynamic linking at all -static do not do any dynamic linking of libtool libraries ^^^ I'm sure this would work, I was hoping there would be a decently easy way to have libtool include *only* the .a's that have bundle counterparts, so that shared libraries we link against still get linked shared... ie, so it ends up doing "g++ -o foo.dylib /path/to/bundular-library.a -lkdecore -lqt" and so on... ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool "module" behavior and darwin
On Sunday, November 24, 2002, at 05:13 PM, Guido Draheim wrote: I mean, that should also be seen on other platforms than darwin, right? Or am I mistaken here? (I wouldn't count myself to know large parts of libtool indepth, well, then again, who still does ;-) ...) Well, on pretty much every other platform nowadays, there's little (no?) difference on-disk between a module and a regular shared library... elf doesn't care. If you're dlopening it, it'll get found regardless. In darwin that's not the case... dlopen is emulated in the first place, but the dynamic loader really acts nothing like dl on most other platforms. It may be that no one ran into this before because their platform wasn't as strange as darwin. =) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Fink-devel] Re: libtool "module" behavior and darwin
On Sunday, November 24, 2002, at 05:17 PM, Guido Draheim wrote: That's actually the difference between "-all-static" and "-static" IIRC. The "-static" should only link its .la's as static, and non-la's dynamic. But perhaps I am mistaken too, that's why I did ask if you did try somewhen. Well, plenty of the la's in kde's tree are dynamic and not bundles (like, libkdecore). If I did -static, I would end up with every binary in kdelibs linked statically... =) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Fink-devel] Re: libtool "module" behavior and darwin
On Sunday, November 24, 2002, at 05:44 PM, Guido Draheim wrote: You mean they are listed as ".la" on the link-line? To stick with the example, there is a LIB_KDEGAMES = libkdegames.la in your makefiles? aargh, kde maniacs at work No, it would be, libfoo_la_LIBADD = $(top_builddir)/kdecore/libkdecore.la How else would you link against a library that's not installed yet? Well, anyways, as in the other subthread: may be we'd instruct all -module .la to be linked as .a, on all platforms, and leave all the other .la be dynalinked. That would help here, and from my POV not be incorrect on other platforms either. Hey, I may be wrong, so what do others think? Seems like no matter how "correct" it is, you'd be breaking (depending on your definition of breaking =) 95% of the platforms that it works on, just for the 5% where it doesn't... We're already used to working around the linker and ld.so (well, dyld) on darwin, since it's just plain odd. Seems silly to make modules unloadable on elf platforms just for us, when, to me, loading modules is a feature. It just happens to be a feature I don't have on Darwin. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Fink-devel] Re: libtool "module" behavior and darwin
That's great news. I cannot, however, promise to have these available anytime soon. I would appreciate help. Anyone? I can certainly help out with this. While waiting for more input on this thread, I actually ended up coming up with the same solution last night. I woke up this morning to find my kdelibs build done, and your (Nick's) response in my inbox telling me to do the same thing. If the netbsd patches aren't up-to-date with head, I will clean them up until they are, and help out in getting everything back into KDE HEAD. I've got commit access to KDE, although I try not to use it since it seems like I screw everything up every time I try to commit to their tree. =) So I guess the outcome of this is that yes, KDE is doing the wrong thing, but on most platforms it doesn't matter. Maybe libtool should instead give a warning when linking against a .la that was compiled with -module about not being portable, instead of coming up with some elaborate hack? I'm not sure if that's a "good enough" solution or not, but it would at least be something... ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
flat namespaces redux
So the discussion came up on the fink irc channel again about libtool and namespaces. I recall being rejected in wanting to add support for linker namespaces in libtool in the thread following this post: http://www.mail-archive.com/libtool@gnu.org/msg03042.html ...but looking at the archives, I don't see a post following my --namespace= proposal, so I have no idea where we left off. =) As more stuff gets ported to OSX and they interact with each other, having things build with flat namespaces is becoming more and more of an issue. The problem is not necessarily that libtool needs to natively understand darwin library namespaces, but that it currently *forces* flat, which can cause weird and dangerous bugs in built libraries, and isn't the default linking behavior for the platform. In F J Franklin's post here: http://www.mail-archive.com/libtool@gnu.org/msg03058.html He suggested changing it to "-multiply_defined suppress prebind", which seems to be the solution, if libtool doesn't want to support specifying the namespace on the libtool command-line. This would make libtool default to making twolevel libraries (which is darwin's linker default, in fact), but you could still pass "-flat_namespace -undefined suppress" to the command-line if you have a poorly behaving app. Does that seem like a workable solution? ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: flat namespaces redux
On Sunday, February 2, 2003, at 11:23 AM, Benjamin Reed wrote: He suggested changing it to "-multiply_defined suppress prebind", which seems to be the solution, if libtool doesn't want to support specifying the namespace on the libtool command-line. This would make libtool default to making twolevel libraries (which is darwin's linker default, in fact), but you could still pass "-flat_namespace -undefined suppress" to the command-line if you have a poorly behaving app. Hrm, replying to myself, sign of a schizophrenic. =) It was also brought up that one of the reasons for having libtool understand namespaces is to have the ability to transition stuff that currently depends on flat namespaces to build, but doesn't know it. Making it an option would let us leave flat as the default, but provide the ability to work with package maintainers to get things building twolevel that can. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: flat namespaces redux
Well, I think that building thing two level namespace ought to be the libtool default also, flat_namespace is needed for some things but causes problems for many others, how about trying both by default? cc -multiply_defined suppress -prebind blah || cc -flat_namespace -undefined suppress blah I'm not so sure this is a good idea. Seems like this would make things harder for packages, since problems *besides* the namespace could also force it into building flat. Say I'm building libkdeui, which depends on libkdecore and qt. If the link line was written on a linuxy system (ie, the linker allows indirect library references), it would end up doing something like: 1. libkdeui's LIBADD is "-lkdecore" 2. the first half of the link complains that -lqt-mt is indirectly referenced 3. it builds the library flat, and continues on when what *should* happen is it dies at #2, and we add -lqt-mt to libkdeui's LIBADD like it should be. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: flat namespaces redux
On Tuesday, February 4, 2003, at 09:46 PM, Albert Chin wrote: I think we should support the two-level namespace, even if it is OSX-specific. I look at libtool more as a way to easily build shared libraries across multiple platforms. Think about AIX. An AIX shared library (non-brtl) can contain *both* a static and shared member. We don't emulate this across all platforms. The main issue is that right now, libtool is doing the equivalent of "on darwin, force all libraries to be built statically." There is no way to force a twolevel namespace using libtool without doing a sed on ltmain.sh or the resultant configure and stripping out the -flat_namespace libtool puts on the link line. :P At least if it gets switched to "-multiply_defined suppress", you still have the option of making the library flat by adding "-undefined supress -flat_namespace" after the fact. If there was some way to turn it off, it would at least be workable. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
relinking broken on macosx?
well, now that Peter's patches are in libtool, it appears to be working again on MacOSX -- however, for some reason it seems to be trying to relink some libraries (not sure why, library paths are coded into the lib already, there's really no reason to ever relink on MacOSX). I'm trying to update the OSX port of KDE to use the new libtool for testing, and arts ends up dying like this: ---(snip!)--- /bin/sh ../libtool --mode=install /sw/bin/install -c -p libartsflow_idl.la /tmp/arts/sw/lib/libartsflow_idl.la libtool: install: warning: relinking `libartsflow_idl.la' (cd /sw/src/arts-1.1.0-18/arts-1.1/flow; /bin/sh ../libtool --mode=relink g++ -Wnon-virtual-dtor -Wno-long-long -Wundef -Wall -pedantic -W -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -O2 -fno-exceptions -fno-check-new -ftemplate-depth-99 -L/sw/lib -o libartsflow_idl.la -rpath /sw/lib -no-undefined -version-info 1:0 artsflow.lo ../mcop/libmcop.la -inst-prefix-dir /tmp/arts) g++ -r -Wl,-bind_at_load -keep_private_externs -nostdlib -o .libs/libartsflow_idl.1.0.0.dylib-master.o .libs/artsflow.o && g++ -dynamiclib -o .libs/libartsflow_idl.1.0.0.dylib .libs/libartsflow_idl.1.0.0.dylib-master.o -ldl -L/sw/lib /sw/lib/libmcop.dylib -L/usr/lib/gcc/darwin/3.1 -L/usr/lib/gcc/darwin -L/usr/libexec/gcc/darwin/ppc/3.1/../../.. -lstdc++ -lgcc -lSystem -install_name /sw/lib/libartsflow_idl.1.dylib -compatibility_version 2 -current_version 2.0 g++: /sw/lib/libmcop.dylib: No such file or directory libtool: install: error: relink `libartsflow_idl.la' with the above command before installing it /bin/sh ../libtool --mode=install /sw/bin/install -c -p libartsflow.la /tmp/arts/sw/lib/libartsflow.la libtool: install: warning: relinking `libartsflow.la' (cd /sw/src/arts-1.1.0-18/arts-1.1/flow; /bin/sh ../libtool --mode=relink g++ -Wnon-virtual-dtor -Wno-long-long -Wundef -Wall -pedantic -W -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -O2 -fno-exceptions -fno-check-new -ftemplate-depth-99 -L/sw/lib -o libartsflow.la -rpath /sw/lib -no-undefined -version-info 1:0 -Xlinker -framework -Xlinker CoreAudio fft.lo libartsflow_la.all_cc.lo ../mcop/libmcop.la libartsflow_idl.la ../flow/gslpp/libgslpp.la -L/usr/X11R6/lib -L/sw/lib -L/sw/lib -L/sw/lib -L/usr/X11R6/lib -L/sw/lib -L/sw/lib -laudiofile -lm ../flow/gsl/libgsl.la -lpoll -inst-prefix-dir /tmp/arts) g++ -r -Wl,-bind_at_load -keep_private_externs -nostdlib -o .libs/libartsflow.1.0.0.dylib-master.o .libs/fft.o .libs/libartsflow_la.all_cc.o -all_load ../flow/gslpp/.libs/libgslpp.a ../flow/gsl/.libs/libgsl.a && g++ -dynamiclib -o .libs/libartsflow.1.0.0.dylib .libs/libartsflow.1.0.0.dylib-master.o -logg -L/sw/src/arts-1.1.0-18/arts-1.1/mcop/.libs -lmcop -L/sw/lib /sw/lib/libartsflow_idl.dylib -L/usr/X11R6/lib /sw/lib/libaudiofile.dylib /sw/lib/libmcop.dylib -ldl /sw/lib/libvorbisfile.dylib /sw/lib/libvorbisenc.dylib /sw/lib/libvorbis.dylib -lm /sw/lib/libogg.dylib /sw/lib/libmad.dylib -lpoll -L/usr/lib/gcc/darwin/3.1 -L/usr/lib/gcc/darwin -L/usr/libexec/gcc/darwin/ppc/3.1/../../.. -lstdc++ -lgcc -lSystem -Wl,-framework -Wl,CoreAudio -install_name /sw/lib/libartsflow.1.dylib -compatibility_version 2 -current_version 2.0 g++: /sw/lib/libartsflow_idl.dylib: No such file or directory g++: /sw/lib/libmcop.dylib: No such file or directory libtool: install: error: relink `libartsflow.la' with the above command before installing it make[3]: *** [install-libLTLIBRARIES] Error 1 make[2]: *** [install-am] Error 2 make[1]: *** [install-recursive] Error 1 make: *** [install-recursive] Error 1 ---(snip!)--- Going into the flow/.libs directory, I see this: ---(snip!)--- libartsflow_idl.1.0.0.dylibU libartsflow_idl.1.dylib libartsflow_idl.dylib libartsflow_idl.la libartsflow_idl.lai ---(snip!)--- ...you'll notice it looks like it's appending a "U" to the filename for some reason. I can only assume that's either a bug in the first place, or it's some kind of intermediate file name that isn't getting renamed again after the relink. Any ideas what's going on? ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: relinking broken on macosx?
On Tuesday, February 25, 2003, at 08:12 PM, Benjamin Reed wrote: well, now that Peter's patches are in libtool, it appears to be working again on MacOSX -- however, for some reason it seems to be trying to relink some libraries (not sure why, library paths are coded into the lib already, there's really no reason to ever relink on MacOSX). OK, I've been tinkering with some other stuff -- if I patch ltmain.sh so that need_relink is never set to "yes", everything builds except for one problem: ---(snip!)--- ../mcopidl/mcopidl -t ../flow/artsflow.idl ../mcopidl/mcopidl -t ../flow/artsflow.idl dyld: ../mcopidl/mcopidl can't open library: /sw/lib/libmcop.1.dylib (No such file or directory, errno = 2) dyld: ../mcopidl/mcopidl can't open library: /sw/lib/libmcop.1.dylib (No such file or directory, errno = 2) ---(snip!)--- They're trying to run something that hasn't yet been installed, as part of the build. I thought libtool made wrapper scripts to do DYLD_LIBRARY_PATH magic, but it appears this is not the case. If I set DYLD_LIBRARY_PATH to "../mcop/.libs", the build continues and finishes (and everything has proper paths and such -- so it looks like relinking isn't necessary). I'm not sure where to look to hack on this, does anyone have ideas on the proper fix for this? ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: relinking broken on macosx?
On Tuesday, February 25, 2003, at 10:30 PM, Peter O'Gorman wrote: Ben, I have a patch to disable relinking, for some reason on current libtool, _LT_AC_TAGVAR(hardcode_direct, $1)=yes This is wrong, and makes libtool think relinking is required, set it to no. I am not sure if you also need to set _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir' I haven't looked in ltmain, it may need this var to be set to actually disable relinking, as you can see doing this is pretty meaningless. Yup, this works for me -- libtool 1.5 now properly builds arts and other KDE stuff on KDE-Darwin without any patches. Attached is the patch against current CVS... (OK, so one patch, but I'm working under the assumption this will be accepted =) Thanks for the help, everyone, libtool 1.5 is looking pretty solid now on OSX. libtool-darwin-hardcode-fixes.patch Description: Binary data ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: darwin.6.diff
Peter O'Gorman wrote: Hi, While we need to link all deplibs (actually link against them, not just -L to the dir) on darwin, we only need to do so for shared libraries. This patch fixes that. Also, I had left a couple of printf's in the ltdl code for dyld, and incorrectly returned a 1 in dlcose when the close was successful, and a 0 when it failed, did not set an error string either. Patch is inline and attached. Almost the same as my last patch, except it now sets the dlerror string for the dlcose failing. I just gave this a test run and built the KDE tree with no libtool modifications (other than copying libtool 1.5+darwin.6.diff) on MacOSX, so it looks like it handles things properly here. +1 :) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Cyclic dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bob Friesenhahn wrote: On 12 Jun 2003, Thomas Maier wrote: I think I have a problem with libtool and cyclic dependencies. Say, I want to build two libraries a.la and b.la. a uses things from b and vice versa. When compiling these libs without libtool, first I compile one, then the other. When linking a program p that uses a *or* b, I have to link p with a *and* b. Fine. I only checked that because I had Uugh. Even without libtool, creating libraries with interdependencies causes portability problems because some linkers (which even includes linkers in older versions of Linux) require that the libraries be listed in inverse dependency (left to right) order. Not only that, but on MacOSX for prebinding to occur all symbols have to be resolvable at link time, and even for linking in general unless you explicitly tell it otherwise (which libtool normally does, but there are cases in which it won't). For the future portability, I implore that you go with what Bob suggested. :) - -- Benjamin Reed a.k.a. Ranger Rick -- http://ranger.befunk.com/ A computer scientist is someone who, when told to 'Go to Hell', sees the 'go to', rather than the destination, as harmful. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+6LECUu+jZtP2Zf4RAk0AAJ9HmsV93gcIUgRt7E4XjEYrD4ASKQCfVxQi 11ZQhczXh6rC9l6JF7RN0Sc= =kO7T -END PGP SIGNATURE- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
handling of -framework in .la's?
I'm not sure how to go about fixing this, but I'm running into an issue in trying to build KDE from CVS against Qt/Mac 3.2.0. The problem is, Qt 3.2 now creates a .la file, which contains -framework lines like so: ---(snip!)--- # libqt-mt.la - a libtool library file # Generated by qmake/libtool (1.06c) (Qt 3.2.0) on: Sun Aug 10 21:14:53 2003 # The name that we can dlopen(3). dlname='libqt-mt.3.dylib' # Names of this library. library_names='libqt-mt.3.2.0.dylib libqt-mt.3.dylib libqt-mt.dylib' # The name of the static archive. old_library='libqt-mt.a' # Libraries that this one depends upon. dependency_libs='-framework Carbon -framework QuickTime -lresolv -lz -framework OpenGL -framework AGL' # Version information for libqt-mt current=32 age=0 revision=0 # Is this an already installed library. installed=yes # Files to dlopen/dlpreopen. dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/opt/local/lib' ---(snip!)--- ...then, while building with --debug, it dies like so: ---(snip!)--- + deplibs=AGL -framework OpenGL -framework -lz -lresolv QuickTime -framework Carbon -framework /opt/local/lib/libqt-mt.la -ldl /usr/lib//libiconv.la /usr/lib/libiconv.la /usr/lib/libiconv.la -L/opt/local/lib /opt/local/lib/libintl.la /usr/lib/libiconv.la /opt/local/lib/libintl.la -L/opt/local/lib /opt/local/lib/libglib-2.0.la /usr/lib/libiconv.la /opt/local/lib/libintl.la /opt/local/lib/libglib-2.0.la -L/opt/local/lib /opt/local/lib/libgthread-2.0.la /usr/lib/libiconv.la /opt/local/lib/libintl.la /opt/local/lib/libglib-2.0.la -L/opt/local/lib /opt/local/lib/libgmodule-2.0.la -ldl /usr/lib//libiconv.la /usr/lib/libiconv.la /opt/local/lib/libintl.la /opt/local/lib/libglib-2.0.la /opt/local/lib/libgthread-2.0.la /opt/local/lib/libgmodule-2.0.la -L/opt/local/lib -L/usr/X11R6/lib ../mcop/libmcop.la -L/opt/local/lib -L/usr/X11R6/lib + test X = Xyes + tmp_libs= -framework Carbon -framework QuickTime -lresolv -lz -framework OpenGL -framework AGL + continue + lib= + found=no + test no = yes + test -f '' + echo 'libtool: link: cannot find the library `'\''' libtool: link: cannot find the library `' + exit 1 make[2]: *** [libqtmcop.la.closure] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ---(snip!)--- At this time, "$deplib" is set to "Carbon", so clearly it's considering "-framework" and "Carbon" as 2 different "libraries". Changing them to use -Xlinker or -Wl, has no effect, it still bombs with the same complaint. Any ideas how to handle this? -- We put a lot of thought into our defaults. We like them. If we didn't, we would have made something else be the default. So keep your cotton-pickin' hands off our defaults. Don't touch. Consider them mandatory. "Mandatory defaults" has a nice ring to it. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Building .so files only.
On Aug 29, 2003, at 12:55 AM, Daniel Reed wrote: To produce only .la and .so files, you can pass -module -avoid-version to libtool. In Automake, you can do this by using something similar to: pkglib_LTLIBRARIES = mymod.la mymod_la_SOURCES = mymod.c mymod_la_LDFLAGS = -module -avoid-version This also removes the requirement that the library name start with "lib." This may work on Linux, but on some platforms, this produces a very different file from a library created without -module. "modules" are meant to only be used as a plugin, ie dlopened or something similar. With the module flag, it's a plugin; without, it's a shared library. If you're using -module to make shared libs (that will get linked against by other things), your project isn't portable. ;) -- We put a lot of thought into our defaults. We like them. If we didn't, we would have made something else be the default. So keep your cotton-pickin' hands off our defaults. Don't touch. Consider them mandatory. "Mandatory defaults" has a nice ring to it. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Suppressing -single_module in Mac OS X 10.3
Sushil Kambampati wrote: Hi, Can someone please tell me what should I do to suppress the -single_module flag when linking with libtool in Mac OS X 10.3? Thanks in advance. See my post to teh unix-porting list; your gcc is broken... -- Benjamin Reed a.k.a. Ranger Rick -- http://ranger.befunk.com/ gpg: 6401 D02A A35F 55E9 D7DD 71C5 52EF A366 D3F6 65FE A computer scientist is someone who, when told to 'Go to Hell', sees the 'go to', rather than the destination, as harmful. pgp0.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
current cvs evaluates shrext before args are parsed
Since on darwin shrext is dependent on whether the library is a module or not, shrext is set to a test that gets eval'd later. It appears that sometime in the last month or two, changes have made it so that shrext is evaluated *before* the command-line arguments are parsed, and thus shrext is always .dylib because $module is set to no. I've not yet tracked down where this happened, but this is likely going to cause issues on darwin. The output of using "sh -x libtool" for building an arts -module is here, if you need to see a trace: http://ranger.befunk.com/debug/libtool.log ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
more on shrext
On a closer inspection, it appears that the problem is with kde's libtool handling. since they put libtool.m4 as part of their acinclude.m4, I think the quoting is getting removed when it's getting run through configure. I'm having trouble figuring out where the fault lies. I see that shrext is being passed through some "delay_single_quote_subst" thing, so shouldn't it, in theory, not get munged? ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
bug in 1.5 branch?
I'm trying to build aRts using the 1.5 branch (as of a day or two ago) on Mac OS X, and when I build it gives this error: ---(snip!)--- 10-0-4-104:/sw/build/arts-1.3.0-1/arts-1.3.0 root# make -j1 cd . && /bin/sh ./config.status config.h config.status: creating config.h config.status: config.h is unchanged cd ./flow/ && make artsflow.cc ../mcopidl/mcopidl -t ../flow/artsflow.idl dyld: /sw/build/arts-1.3.0-1/arts-1.3.0/mcopidl/.libs/mcopidl can't open library: /sw/lib/libmcop.1.dylib (No such file or directory, errno = 2) make[1]: *** [artsflow.cc] Trace/BPT trap make: *** [flow/artsflow.cc] Error 2 ---(snip!)--- when I edit the mcopidl script to print out DYLD_LIBRARY_PATH, it says: DYLD_LIBRARY_PATH = /sw/build/arts-1.3.0-1/arts-1.3.0/mcopidl/./mcop/.libs:/sw/lib it *should* be /sw/build/arts-1.3.0-1/arts-1.3.0/mcopidl/../mcop/.libs:/sw/lib (two dots instead of one). mcopidl's Makefile.am looks like this: ---(snip!)--- bin_PROGRAMS = mcopidl mcopidl_SOURCES = mcopidl.cc yacc.cc scanner.cc namespace.cc mcopidl_LDFLAGS = $(all_libraries) mcopidl_LDADD = ../mcop/libmcop.la ---(snip!)--- ...so it's doing the right thing, just somehow it's getting the wrong path to mcop's .libs directory. Any ideas? ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
reproducible libtool error in 1.5.14 on Mac OS X 10.3
The error occurs when libtool is called with a subdirectory when
creating libraries and binaries linked against those libraries and a
wrapper script is created.
Attached is a script that reproduces the error, and the output is as
follows:
---(snip!)---
10-0-4-38:~/tmp ranger$ ./libtool-1.5.14-darwin-error.sh
g++ -c foo/libtest.cpp -fno-common -DPIC -o foo/.libs/libtest.o
g++ -c foo/libtest.cpp -o foo/libtest.o >/dev/null 2>&1
rm -fr foo/.libs/libtest.0.0.0.dylib foo/.libs/libtest.0.dylib
foo/.libs/libtest.a foo/.libs/libtest.dylib foo/.libs/libtest.la
foo/.libs/libtest.lai
g++ -dynamiclib -single_module ${wl}-undefined ${wl}dynamic_lookup -o
foo/.libs/libtest.0.0.0.dylib foo/.libs/libtest.o -install_name
/usr/lib/libtest.0.dylib -Wl,-compatibility_version -Wl,1
-Wl,-current_version -Wl,1.0
(cd foo/.libs && rm -f libtest.0.dylib && ln -s libtest.0.0.0.dylib
libtest.0.dylib)
(cd foo/.libs && rm -f libtest.dylib && ln -s libtest.0.0.0.dylib
libtest.dylib)
ar cru foo/.libs/libtest.a foo/libtest.o
ranlib foo/.libs/libtest.a
creating foo/libtest.la
(cd foo/.libs && rm -f libtest.la && ln -s ../libtest.la libtest.la)
g++ -c bar/main.cpp -fno-common -DPIC -o bar/.libs/main.o
g++ -c bar/main.cpp -o bar/main.o >/dev/null 2>&1
g++ -o bar/.libs/testprog bar/.libs/main.o -Wl,-bind_at_load
foo/.libs/libtest.dylib
creating bar/testprog
dyld: /Users/ranger/tmp/bar/.libs/testprog can't open library:
/usr/lib/libtest.0.dylib (No such file or directory, errno = 2)
./libtool-1.5.14-darwin-error.sh: line 34: 8145 Trace/BPT trap
bar/testprog
---(snip!)---
#!/bin/sh
export MACOSX_DEPLOYMENT_TARGET=10.3
mkdir -p foo bar
cat
