[Fink-devel] Re: libtool "module" behavior and darwin
Ooops, so I did not read the patch too closely - thanks for the clarification. IOW, there are now two dummy binaries, one is the system executable, the other is the dlopen-able module, and both depend on a single system lib*.la - cute! just to check back with the darwin'ers: a dlopen().so can link with a .dylib and everything gets resolved nicely? cheers, -- guido Nick Hudson wrote: On Monday 25 November 2002 10:04 am, Guido Draheim wrote: It's the correct solution AFAICS - from the same sources two libtool libraries are built - one is a system library that gets linked to the system binary. And the module libtool archive is separate from that. Both .la will be able to pick up the same .lo being compiled along, so it is nothing more than a single extra link stage in the make process. IOW, on linux/solaris this would be LINK *.lo -o kbackgammon.so LINK *.lo -o libkbackgammon.so on systems like darwin it would boil down into LINK *.lo -o kbackgammon.so LINK *.lo -o libkbackgammon.dylib Getting back to the question that followed from the original link problem: I am not sure whether the user-binary called "kbackgammon" does actually need a shared library to be built from. In the setup above, there would still need to be installed _two_ libraries into the target system, plus the dummy binary. Binding the '-module' kbackgammon.la as '-static' would still push two copies of the same .lo's into the system. Here's what happends... The bulk of the code ends up in the shared library libkbackgammon_main.la. The kbackgammon.la module and the kbackgammon are both very small (a single function called main that calls kdemain) and they both depend on this dynamic library. It seems the original author did want to avoid having two copies of the program's library objects around, and this is in fact possible in most elf systems. The rpath will guide the system loader to find its -module so-library, whereever that one will end up. It is in fact a dependency on some system characteristics that are portable among modern systems being mostly elf based - but breaks when trying to port kde somewhere else. (btw, does that link-to-module work with cygwin?) I wtill think the original stuff was plain messy. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: libtool "module" behavior and darwin
It's the correct solution AFAICS - from the same sources two libtool libraries are built - one is a system library that gets linked to the system binary. And the module libtool archive is separate from that. Both .la will be able to pick up the same .lo being compiled along, so it is nothing more than a single extra link stage in the make process. IOW, on linux/solaris this would be LINK *.lo -o kbackgammon.so LINK *.lo -o libkbackgammon.so on systems like darwin it would boil down into LINK *.lo -o kbackgammon.so LINK *.lo -o libkbackgammon.dylib Getting back to the question that followed from the original link problem: I am not sure whether the user-binary called "kbackgammon" does actually need a shared library to be built from. In the setup above, there would still need to be installed _two_ libraries into the target system, plus the dummy binary. Binding the '-module' kbackgammon.la as '-static' would still push two copies of the same .lo's into the system. It seems the original author did want to avoid having two copies of the program's library objects around, and this is in fact possible in most elf systems. The rpath will guide the system loader to find its -module so-library, whereever that one will end up. It is in fact a dependency on some system characteristics that are portable among modern systems being mostly elf based - but breaks when trying to port kde somewhere else. (btw, does that link-to-module work with cygwin?) That limits the portability of kde as whole, perhaps, and so the presented patch should really be merged back into kde, taking the burden to make two libraries even on elf systems. Still, I am asking myself if it might be in fact a good idea to guide all systems to link '-module' .la as static, that is not to give a '-lmodulelib' to the linker but a 'modulelib.a' - on all systems. Atleast, I'd propose to have a check - and utter a warning message when s.o. is trying to link a '-module' archive into a system binary. We could then see if someone comes around and barks at us what that warning message has to say. That might allow us to see where too that .so possiblity has been (ab)used. cheers, guido Nick Hudson wrote: On Sunday 24 November 2002 6:23 pm, Benjamin Reed wrote: 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. This was talked about some time ago by Michael Matz and myself. 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. I have create patches to the KDE build system that solves a related problem that affects NetBSD a.out platforms. I believe they should fix the Darwin problem. Unfortunately Michael never folded them back into KDE. I guess he is too busy. :( Nick $NetBSD: patch-aa,v 1.1 2002/05/31 14:02:54 skrll Exp $ --- kbackgammon/Makefile.am.orig Fri Oct 5 12:52:05 2001 +++ kbackgammon/Makefile.am @@ -2,21 +2,22 @@ INCLUDES = -I$(top_srcdir)/libkdegames -I$(top_srcdir)/libkdegames/kgame/ -I$(srcdir)/engines $(all_includes) bin_PROGRAMS = kbackgammon -lib_LTLIBRARIES = kbackgammon.la +lib_LTLIBRARIES = libkbackgammon_main.la kbackgammon.la -CLEANFILES = dummy.cpp - -kbackgammon_la_LIBADD = $(LIB_KDEUI) $(LIB_KSYCOCA) -lkdeprint \ +libkbackgammon_main_la_LIBADD = $(LIB_KDEUI) $(LIB_KSYCOCA) -lkdeprint \ ./engines/libkbgengines.la -kbackgammon_la_SOURCES = main.cpp kbg.cpp kbgboard.cpp kbgtextview.cpp \ +libkbackgammon_main_la_SOURCES = main.cpp kbg.cpp kbgboard.cpp kbgtextview.cpp \ kbgstatus.cpp +kbackgammon_la_LIBADD = libkbackgammon_main.la +kbackgammon_la_SOURCES = kbackgammon_main.cpp + kbackgammon_la_METASOURCES = AUTO kbackgammon_la_LDFLAGS = $(all_libraries) $(KDE_RPATH) -module -avoid-version -kbackgammon_LDADD = kbackgammon.la $(top_builddir)/libkdegames/libkdegames.la \ +kbackgammon_LDADD = libkbackgammon_main.la $(top_builddir)/libkdegames/libkdegames.la \ $(LIB_KSYCOCA) -kbackgammon_SOURCES = dummy.cpp +kbackgammon_SOURCES = kbackgammon_main.cpp kbackgammon_LDFLAGS = $(all_libraries) $(KDE_RPATH) noinst_HEADERS = version.h kbg.h kbgboard.h kbgtextview.h kbgstatus.h @@ -34,9 +35,6 @@ messages: rc.cpp LIST=`find . -name \*.h -o -name \*.hh -o -name \*.H -o -name \*.hxx -o -name \*.hpp -o -name \*.cpp -o -name \*.cc -o -name \*.cxx -o -name \*.ecpp -o -name \*.C`; \ $(XGETTEXT) $$LIST -o $(podir)/kbackgammon.pot - -dummy.cpp: - echo > dummy.cpp install-data-local: rm -rf $(kde_appsdir)/Games/kbackgammon.desktop -
Re: [Fink-devel] Re: libtool "module" behavior and darwin
Benjamin Reed wrote: 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? echo ' erocedkl- sbil./erocedk/)riddliub_pot($L- ' | rev (I didn't say that, okay...) 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... for platforms, it might be 95%, for use cases it will not break anything for the 999 that I have ever looked at - anyone to know the number 1000 where it would break things? 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. May I correct your wording hereon: Other systems allow to dlopen() system sharedlibs. The current problem is the inverse of this: Linking dlopen()-modules into system binaries. Both are strictly interdepent, right? IF that is the case THEN it is bad behaviour of a programmer to actually TRY to link a dlopen() module into a system binary since he makes a platform specific assumption - being not portable at all. I think, libtool should not warrant non-portable assumption, and instead enforce the only portable assumption - as that -module sharedobjects should not be part in a system link. Well, it didn't enforce it up to now, so... --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: libtool "module" behavior and darwin
Benjamin Reed wrote: 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... =) 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 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? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: libtool "module" behavior and darwin
Benjamin Reed wrote: 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... 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. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: libtool "module" behavior and darwin
Benjamin Reed wrote: [...] ---(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!)--- [...] > 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? doh, so some kde programmers have tricked libtool. To make sharedlibrary creation being platform independent is tricky in itself, and module support has made for a lot of dark corners on the way to it. 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 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
