Re: GNU Libtool 1.5.8 released.
On Fri, 2004-08-13 at 05:37, Daniel Reed wrote: > ) On Fri, 13 Aug 2004, Ralf Corsepius wrote: > ) > However, you can not identify the multilib-variant and the multilib > ) > subdir being used from $host, because it is chosen depending upon the > ) > flags being passed to gcc: > ) > sparc-sun-solaris2.8-gcc .. -> . (sparcv7) > ) > sparc-sun-solaris2.8-gcc -m64 .. -> sparcv9 > > In the scheme we use, $host would be sparc64-sun-solaris2.8 . AFAIU, all'd you do here, is to invent a convention to be able to apply a similar hack to libtool addressing sparc-sun-solaris as the RH patch does. This does not solve the troubles libtool is facing with multilibs in general. Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On Fri, 2004-08-13 at 04:15, Bob Friesenhahn wrote: > On Fri, 13 Aug 2004, Ralf Corsepius wrote: > >> > >> Well, the difference, in my little mind at least, is that the commercial > >> unixes can all be identified in libtool using $host, > > Right, you can identify $host and in case of Solaris even the OS version > > as part of $host (solaris2.8). > > > > However, you can not identify the multilib-variant and the multilib > > subdir being used from $host, because it is chosen depending upon the > > flags being passed to gcc: > > sparc-sun-solaris2.8-gcc .. -> . (sparcv7) > > sparc-sun-solaris2.8-gcc -m64 .. -> sparcv9 > > If I wrap gcc up in a script which provides secret -m options, then > you can't see what I am doing. Neener, neener, neener! :-) > > It seems that the only valid test to determine the default output > architecture is to compile code and then use 'file' or some other > utility to determine the architecture. What for? If you have a look at RH's patch, the actual problems they are trying to solve are: * Setting up sys_lib_search_path_spec, i.e. to retrieve gcc's internal library search path, which, due to the impact of multilibs does not match with the traditional library search path. * Setting up sys_lib_dlsearch_path_spec, i.e. to merge the compilers settings with those of the dynamical linker. "file" doesn't help much here, in general, because multilibs don't necessarily produce different output in "file". RH is able to apply it, because in their particular case, both multilib variants can be distinguished by using "file". In other case this won't work. [Consider soft-float/fpu multilib variants (very common on embedded targets), same ABI, same instruction sets (soft-float using a subset of the "fpu" instruction set)] > In order to produce multilib > output, libtool would need to know the specific options necessary to > obtain each desired variant. These options are compiler and linker > specific. Exactly. However, in case of GCC this should be doable (cf. gcc -print-multi-lib). Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
) On Fri, 13 Aug 2004, Ralf Corsepius wrote: ) > However, you can not identify the multilib-variant and the multilib ) > subdir being used from $host, because it is chosen depending upon the ) > flags being passed to gcc: ) > sparc-sun-solaris2.8-gcc .. -> . (sparcv7) ) > sparc-sun-solaris2.8-gcc -m64 .. -> sparcv9 In the scheme we use, $host would be sparc64-sun-solaris2.8 . -- Daniel Reed <[EMAIL PROTECTED]> http://people.redhat.com/djr/ http://naim.n.ml.org/ The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On Fri, 13 Aug 2004, Ralf Corsepius wrote: Well, the difference, in my little mind at least, is that the commercial unixes can all be identified in libtool using $host, Right, you can identify $host and in case of Solaris even the OS version as part of $host (solaris2.8). However, you can not identify the multilib-variant and the multilib subdir being used from $host, because it is chosen depending upon the flags being passed to gcc: sparc-sun-solaris2.8-gcc .. -> . (sparcv7) sparc-sun-solaris2.8-gcc -m64 .. -> sparcv9 If I wrap gcc up in a script which provides secret -m options, then you can't see what I am doing. Neener, neener, neener! :-) It seems that the only valid test to determine the default output architecture is to compile code and then use 'file' or some other utility to determine the architecture. In order to produce multilib output, libtool would need to know the specific options necessary to obtain each desired variant. These options are compiler and linker specific. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On Thu, 2004-08-12 at 18:12, Peter O'Gorman wrote: > Bob Friesenhahn wrote: > > > On Thu, 12 Aug 2004, Tim Mooney wrote: > > > >> Why just Linux? Isn't this essentially the same issue that the multi-ABI > >> commercial UNIXes have? > > > > > > Seems like it to me. I am not sure. Solaris-gcc applies traditional multilibs, i.e. it is using multilib subdirs (A subdir of PREFIX/lib). I don't know how "multiarchs" are implemented in RH's ix86_64 gcc. /usr/lib64 is not a subdir of PREFIX/lib > For example, Solaris puts 64-bit libraries in a > > 'sparcv9' subdirectory. The 'sparcv7' directory is used for libraries > > built for older SPARC processor types. Libraries optimized for 32-bit > > Ultrasparc are put in the traditional location. > > Well, the difference, in my little mind at least, is that the commercial > unixes can all be identified in libtool using $host, Right, you can identify $host and in case of Solaris even the OS version as part of $host (solaris2.8). However, you can not identify the multilib-variant and the multilib subdir being used from $host, because it is chosen depending upon the flags being passed to gcc: sparc-sun-solaris2.8-gcc .. -> . (sparcv7) sparc-sun-solaris2.8-gcc -m64 .. -> sparcv9 => There is no fixed "host" to multilib subdir mapping. IMO, RH's multilib-patch is just a "band-aid" (read: hack) to help them keep libtool going on their systems, but is not a generalizable approach. How do other Linux vendors (Debian, SuSE etc.) handle this issue? I would expect them to be facing the same problems as RH and to have similar work-arounds applied to libtool. Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Convenieve libraries and applications.
Joe Orton wrote: A good solution I found seemed to be to use partial linking rather than convenience libraries, which libtool was happy to do if you use: libtool --mode=link gcc -o libpart.o some.lo random.lo objs.lo But I don't know how portable ld -r is. All Unix linkers have supported this for at least the past 25 years. (I don't know if it's actually OK/portable to assume that objects with symbols not referenced from main MUST get pulled into an executable if that object is passed on the link line, but we rely on that already) I actually hacked my libtool 1.4.3 to use partial linking to create shared libraries as well. E.g. it now spits out ld -r -o libfoo.lo $(OBJS) ld -G -o libfoo.so libfoo.lo This makes things go a lot faster when you run libtool --mode=install if it needs to relink the target library. -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On 2004-08-11T20:43-0400, Daniel Reed wrote: ) ) > ) > > libtool-1.4.2-multilib.patch ) Would it be reasonable to make this a ./configure option at libtool build ) time? Actually, it wouldn't. :) The actual problem is that software packaged with stock Libtool does not build properly in our multilib build roots. Right now, we have to manually re-bootstrap several of our packages to use our modified libtool.m4. My goal is to allow us to stop doing that :) (I would like to be able to remove the autotools from our build roots altogether.) So, instead of a libtool-compile-time option, would it be reasonable to a) use an environment variable to set this behavior, or b) have Libtool add an option to libtoolized ./configure scripts, or something else? -- Daniel Reed <[EMAIL PROTECTED]> http://people.redhat.com/djr/ http://naim.n.ml.org/ There go my people. I must find out where they are going so I can lead them. -- Alexandre Ledru-Rollin ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On Fri, 13 Aug 2004, Peter O'Gorman wrote: Well, the difference, in my little mind at least, is that the commercial unixes can all be identified in libtool using $host, but linux will have the same $host regardless of being debian, redhat, suse, etc... So the need here, specifically is to identify the directories used by various linux distributions, so that adding something which satisfies RedHat (in this case), does not break debian. In other words, the Linux folks should put their heads together and agree on a standard way of doing things, right? :-) I agree that the proprietary Unix vendors are much easier to deal with and that OS identification/version tests should be sufficient in many cases. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
Bob Friesenhahn wrote: On Thu, 12 Aug 2004, Tim Mooney wrote: Why just Linux? Isn't this essentially the same issue that the multi-ABI commercial UNIXes have? Seems like it to me. For example, Solaris puts 64-bit libraries in a 'sparcv9' subdirectory. The 'sparcv7' directory is used for libraries built for older SPARC processor types. Libraries optimized for 32-bit Ultrasparc are put in the traditional location. Well, the difference, in my little mind at least, is that the commercial unixes can all be identified in libtool using $host, but linux will have the same $host regardless of being debian, redhat, suse, etc... So the need here, specifically is to identify the directories used by various linux distributions, so that adding something which satisfies RedHat (in this case), does not break debian. Peter -- Peter O'Gorman - http://www.pogma.com ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On Thu, 12 Aug 2004, Tim Mooney wrote: In regard to: Re: GNU Libtool 1.5.8 released., Peter O'Gorman said (at...: Or even something like --with-multilibformat='lib64' versus --with-multilibformat='$host_os/lib' ? Well, lets think a bit. We want to add the 64bit specific directories for linux. Why just Linux? Isn't this essentially the same issue that the multi-ABI commercial UNIXes have? Seems like it to me. For example, Solaris puts 64-bit libraries in a 'sparcv9' subdirectory. The 'sparcv7' directory is used for libraries built for older SPARC processor types. Libraries optimized for 32-bit Ultrasparc are put in the traditional location. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
In regard to: Re: GNU Libtool 1.5.8 released., Peter O'Gorman said (at...: Or even something like --with-multilibformat='lib64' versus --with-multilibformat='$host_os/lib' ? Well, lets think a bit. We want to add the 64bit specific directories for linux. Why just Linux? Isn't this essentially the same issue that the multi-ABI commercial UNIXes have? Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
Daniel Reed wrote: On 2004-08-12T09:00+0900, Peter O'Gorman wrote: ) Daniel Reed wrote: ) > On 2004-08-11T10:06+0900, Peter O'Gorman wrote: ) > ) Daniel Reed wrote: ) > ) > > libtool-1.4.2-multilib.patch ) > ) > This patch is needed for multilib support. It has been sent upstream ) > ) > but basically rejected in its current form as being too Red Hat specific. ) > ) > [Is this still the case? Is there an alternate solution for this problem, or ) > ) > is .multilib still the only one?] ) Thanks for the url. I have to agree with Scott, looks like adding this patch ) here would be a bad thing, it may break other linux distros. Someone, ) someday, will come up with a generic way of doing this that works on all ) flavours of GNU/linux. They don't seem to have done so yet. Would it be reasonable to make this a ./configure option at libtool build time? Something like --enable-redhat-multilib or --with-multilib-flavor=RedHat ? Or even something like --with-multilibformat='lib64' versus --with-multilibformat='$host_os/lib' ? Well, lets think a bit. We want to add the 64bit specific directories for linux. Different linux distro's seem to be going with different places to put their 64 bit libs? Do all of them stay consistent? e.g. RedHat is /lib64 /usr/lib64 etc... Debian is usr/x86_64-linux/lib ? and so on. etc. etc. What else is there? Did everyone chose a different system? That'd totally suck :( I know bugger all about this, but I assume that there is a libc in one of these directories on all linux flavours? Can we test for libc.so in various dirs and then work out the proper sys_lib_search_path_spec etc? Peter -- Peter O'Gorman - http://www.pogma.com ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Convenience libraries and applications.
On Thu, Aug 12, 2004 at 12:09:10PM +0900, Peter O'Gorman wrote: > -export-dynamic is to export symbols from an application so that they are > available to runtime loaded code. > > GNU libtool convenience libraries are, as far as I know, only designed to > use the whole archive when they are used in creating shared libraries. They > are built using position independent code for that purpose. While you can > use them when building applications, that is not their purpose. Then how should one build an executable that exists of source files spread over multiple directories? I thought I even saw examples that use convenience libs for that casse, though I could be wrong. Did I miss something in the documentation of libtool? > There is no way to do what you want, at the moment, using libtool (to my > knowledge). "convenience" libraries are just treated as ordinary libraries > when creating an executable. I suggest that you reference the symbols in > the executable so that your linker will keep them around. If you want to > add this feature to libtool (it sounds like it may be useful)... send > patches. I think it is clear by now (from this thread) that this is actually a needed but missing feature in libtool, so it should be added. However, I am a C++ coder - not a shell script coder; someone else with knowledge of the internals of libtool can do this job a lot more efficiently. Also take into account that that doesn't mean that I am sitting on the beach while that other person is fixing this; I work my ass off around the clock on Open Source, just different packages. Thanks, -- Carlo Wood <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
make prob
With cvs code from just now: make all-recursive Making all in . cd . && /bin/ksh /usr/src/local/libtool/config/missing --run automake-1.9a --gnits libltdl/Makefile.am: C objects with per-target flags but `AM_PROG_CC_C_O' not in `configure.ac' Cheers, Patrick ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Convenieve libraries and applications.
On Thu, Aug 12, 2004 at 12:09:10PM +0900, Peter O'Gorman wrote: > There is no way to do what you want, at the moment, using libtool (to my > knowledge). "convenience" libraries are just treated as ordinary libraries > when creating an executable. I suggest that you reference the symbols in > the executable so that your linker will keep them around. If you want to > add this feature to libtool (it sounds like it may be useful)... send > patches. I looked into this a while back: we need the same feature for Apache httpd, and currently solve it by creating long list of dummy references to symbols in convenience libraries to ensure they are all pulled in. (this bloats the executable significantly and it's really hacky to create the lists) A good solution I found seemed to be to use partial linking rather than convenience libraries, which libtool was happy to do if you use: libtool --mode=link gcc -o libpart.o some.lo random.lo objs.lo But I don't know how portable ld -r is. (I don't know if it's actually OK/portable to assume that objects with symbols not referenced from main MUST get pulled into an executable if that object is passed on the link line, but we rely on that already) joe ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
