Re: ILD too long
On 14-Feb-2000 Stephan Kulow wrote: > Yes. I cleaned up KDE's situation a bit by now in removing LDFLAGS > that weren't strictly necessary but it's still a pain. I think, the > ILD should > 1) remove doubled -L calls (this should be quite simple as done with > the usual config.cache way) OK > 2) remove doubled base libraries to libraries. As this has to be done > from the end to the begining, it has to be quite clever and may add > some not so nice overhead. I'm working on a fix. My first experimental patch (an ugly hack :( is attached. It's doesn't support the -la -lb -la case yet. Thomas Tanner - email: tanner@(ffii.org|gnu.org|gmx.de) web: http://home.pages.de/~tanner/ UMI: http://umi.ffii.org/ diff -ruNd -X exclude libtool/ltmain.in new/ltmain.in --- libtool/ltmain.in Tue Feb 1 17:44:51 2000 +++ new/ltmain.in Fri Feb 18 00:44:19 2000 @@ -1305,6 +1305,8 @@ done ;; prog) + compile_deplibs= + finalize_deplibs= alldeplibs=no newdlfiles= newdlprefiles= @@ -1342,11 +1344,11 @@ done if test "$found" != yes; then if test "$linkmode,$pass" = "prog,link"; then - compile_command="$compile_command $deplib" - finalize_command="$finalize_command $deplib" + compile_deplibs="$deplib $compile_deplibs" + finalize_deplibs="$deplib $finalize_deplibs" else - deplibs="$deplibs $deplib" - test $linkmode = lib && newdependency_libs="$newdependency_libs $deplib" + deplibs="$deplib $deplibs" + test $linkmode = lib && newdependency_libs="$deplib $newdependency_libs" fi continue fi @@ -1354,22 +1356,17 @@ -L*) case $linkmode in lib) - case "$deplibs " in - *" $deplib "*) ;; - *) - deplibs="$deplibs $deplib" - newdependency_libs="$newdependency_libs $deplib" - new_lib_search_path="$new_lib_search_path "`$echo "X$deplib" | $Xsed -e 's/^-L//'` - ;; - esac + deplibs="$deplib $deplibs" + newdependency_libs="$deplib $newdependency_libs" + new_lib_search_path="$new_lib_search_path "`$echo "X$deplib" | $Xsed -e 's /^-L//'` ;; prog) if test $pass = scan; then - deplibs="$deplibs $deplib" + deplibs="$deplib $deplibs" new_lib_search_path="$new_lib_search_path "`$echo "X$deplib" | $Xsed -e 's/^-L//'` else - compile_command="$compile_command $deplib" - finalize_command="$finalize_command $deplib" + compile_deplibs="$deplib $compile_deplibs" + finalize_deplibs="$deplib $finalize_deplibs" fi ;; *) @@ -1403,16 +1400,16 @@ echo echo "*** Warning: Linking the shared library $output against the" echo "*** static library $deplib is not portable!" - deplibs="$deplibs $deplib" + deplibs="$deplib $deplibs" fi continue ;; prog) if test $pass = scan; then - deplibs="$deplibs $deplib" + deplibs="$deplib $deplibs" else - compile_command="$compile_command $deplib" - finalize_command="$finalize_command $deplib" + compile_deplibs="$deplib $compile_deplibs" + finalize_deplibs="$deplib $finalize_deplibs" fi continue ;; @@ -1545,7 +1542,7 @@ if test $linkmode = prog && test $pass != link; then new_lib_search_path="$new_lib_search_path $ladir" - deplibs="$deplibs $lib" + deplibs="$lib $deplibs" linkalldeplibs=no if test "$link_all_deplibs" != no || test "$fast_install" != no || \ @@ -1554,7 +1551,7 @@ else # Need to hardcode shared library paths # or/and link against static libraries - newdependency_libs="$newdependency_libs $dependeny_libs" + newdependency_libs="$dependeny_libs $newdependency_libs" fi for deplib in $dependency_libs; do @@ -1562,7 +1559,7 @@ -L*) new_lib_search_path="$new_lib_search_p
RE: shared libs on linux/powerpc
On 21-Feb-2000 Dirk A. Mueller wrote: > I suggest adding "powerpc*" to the host_cpu check: Thanks. Done. Thomas Tanner - email: tanner@(ffii.org|gnu.org|gmx.de) web: http://home.pages.de/~tanner/ UMI: http://umi.ffii.org/
RE: Test case for the problem in Kaffe
Hi Pavel, > When an executable is linked both against "normal" libraries and modules > to be dlopened the modules always appear first in the compiler command > line, regardless of their order in the libtool command line Thanks. Fixed. Thomas Tanner - email: tanner@(ffii.org|gnu.org|gmx.de) web: http://home.pages.de/~tanner/ UMI: http://umi.ffii.org/
Re: ILD too long
On 19-Feb-2000 Stephan Kulow wrote: >> I'm working on a fix. >> My first experimental patch (an ugly hack :( is attached. >> It's doesn't support the -la -lb -la case yet. > It doesn't work with static linking. > actually libkdecore.la links to libDCOP.la and some other libs. > libtool --mode=link g++ -o test test.o libkdecore.la results in > g++ -o test test.o libDCOP.a kdecore.a > (basicly - I removed 90% of the output :) OK. I've just commited my latest patch to CVS. It does now also support interdependent libraries. Please test it. Thomas Tanner - email: tanner@(ffii.org|gnu.org|gmx.de) web: http://home.pages.de/~tanner/ UMI: http://umi.ffii.org/
RE: Getting the platforms DLL name ending ?
On 14-Mar-2000 Petter Reinholdtsen wrote: > > What is the easiest way to get the current platforms DLL name ending? > I want a string containing .so on Linux .sl on HP/UX and .dll on OS/2. > > I tried reading ltmain.sh, ltconfig and libtool without discovering > any method to get this information. Try this: ./libtool --config > conftest . ./conftest rm -f conftest last= for spec in $library_names_spec; do last="$spec" done shlibext=`echo "$last" | sed 's/\[.*\]//;s/^[^.]*//;s/\$.*$//;s/\.$//'` Thomas Tanner - email: tanner@(ffii.org|gnu.org|gmx.de) web: http://home.pages.de/~tanner/ UMI: http://umi.ffii.org/
towards libtool 1.4 (was: Preserve environment variables for rel
On 13-Mar-2000 Gary V. Vaughan wrote: >> This might be worth back-porting to 1.3.*, in case we decide to >> release 1.3.5. What do you think? > Nah. I think we should make a 1.4 branch and make a release from that > so that we can merge Ossama's branch back into the trunk. I think it doesn't make sense to start a 1.4 branch as long as the main development is focused on the current HEAD branch. Let's wait until HEAD is stable enough to release 1.3d, then make a 1.4 branch and merge the multi-language branch into the trunk. > How about > setting a date for a feature freeze? Or at least we should try to say > exactly what needs to be done before 1.4 can be set loose... * install all outstandig bugfixes/patches from the list (of course :) * fix convenience library support (currently broken, I'll fix it this weekend) * finish the ltconfig->libtool.m4 merge (I'll post a new patch soon) * fix lt_dlopen error reporting (still broken: if a module does exist but can't be loaded (e.g. due to missing dependency libraries) lt_dlopen should report the result of dlerror() while in case of a not existing file it should report file_not_found_error) * enable loading of dependency libs in libltdl for platforms that need it (dl_dependency_libs can be renamed to dependency_libs; the code is there, we just need to add a check) Thomas Tanner - email: tanner@(ffii.org|gnu.org|gmx.de) web: http://home.pages.de/~tanner/ UMI: http://umi.ffii.org/
RE: Extra library dependencies?
On 27-Feb-2000 Bob Friesenhahn wrote: > I am encountering a very strange problem when using CVS libtool > (multi-lingual) in that several libraries are repeated (as reported by > ldd) as dependencies, and these libraries are not found at run-time. > This is under Solaris 2.6, using gcc 2.9.5. >... > libdpstk.so.5 => (file not found) > libdps.so.5 => (file not found) > libdpstk.so.5 => /usr/openwin/lib/libdpstk.so.5 > libdps.so.5 => /usr/openwin/lib/libdps.so.5 >... > Even though LDFLAGS includes -R/usr/local/lib:/usr/openwin/lib, ^ This syntax is not supported Try using -R/usr/local/lib -R/usr/openwin/lib > libtool seems to be removing /usr/openwin/lib, where the problem > libraries reside. However, notice that one of the two references to > the library is discovered anyway. Maybe -R/usr/openwin/lib is hardcoded into another library that uses libdps[tk]? Thomas Tanner - email: tanner@(ffii.org|gnu.org|gmx.de) web: http://home.pages.de/~tanner/ UMI: http://umi.ffii.org/
Re: ILD too long
Hi, On 26-Feb-2000 Ossama Othman wrote: > I did just realize that the compiler options passed to libtool during > the link phase are being stripped from the link command. For example: > >bin/sh ../libtool --tag=CXX --mode=link c++ -W -Wall -Wpointer-arith >-fno-implicit-templates -g -O2 -pthread -pipe -O3 -o libACE.la > -rpath /usr/local/lib-version-info 5:14:0 Basic_Types.lo OS.lo ... -lrt -ldl > > becomes: > >c++ -shared -nostdlib /usr/lib/crti.o >/usr/lib/gcc-lib/i386-linux/2.95.2/crtbeginS.o .libs/Basic_Types.o .libs/OS.o ... > -L/usr/lib/gcc-lib/i386-linux/2.95.2 -lrt -ldl -lstdc++ -lm -lc -lgcc -lc >/usr/lib/gcc-lib/i386-linux/2.95.2/crtendS.o /usr/l ib/crtn.o > -Wl,-soname -Wl,libACE.so.5 -o .libs/libACE.so.5.0.14 > > This is clearly busted. I'm working on this problem. Bob, I wonder > if this is the cause of your C++ exception problems. Are you passing > some sort of exception flag at link time? I wonder why automake passes CFLAGS and AM_CFLAGS to libtool in link mode? This makes it impossible to differentiate between compiler and linker (LDFLAGS) flags. I think automake should only pass LDFLAGS to libtool and libtool should then add all not libtool-specific flags to the link command. Thomas Tanner - email: tanner@(ffii.org|gnu.org|gmx.de) web: http://home.pages.de/~tanner/ UMI: http://umi.ffii.org/
RE: libtool submits .la files to the linker line
Hi, On 15-Apr-2000 Michael Matz wrote: > It happens with libtool timestamp 1.700, but not with 1.695. > the error message is something like that: > > gcc -shared l4.lo -Wl,--whole-archive ./.libs/libl3.al > -Wl,--no-whole-archive /usr/lib/libl2.la /usr/lib/libl1.la > ./.libs/libl3.al -lm -lc -Wl,-soname -Wl,l > /usr/lib/libl2.la: file not recognized: File format not recognized > > Libtool has failed to substitute the .la names, which it picks up from > dependency_libs, into the correct .so names. [...] Thanks for this very helpful bug report! This bug is fixed in the latest CVS tree. Thomas Tanner - email: tanner@(ffii.org|gnu.org|gmx.de) web: http://home.pages.de/~tanner/ UMI: http://umi.ffii.org/
RE: Link static library into libtool library
On 19-Jul-2000 Paul Berrevoets wrote: >> /bin/sh ../libtool --mode=link gcc -g -O2 -o libfoo.la -rpath > /usr/local/lib foo.lo /usr/local/lib/libbar.a > libtool: link: cannot build libtool library `libfoo.la' from non-libtool > objects: /usr/local/lib/libbar.a > > and yet the Solaris linker allows this: > >> /usr/ccs/bin/ld -G -h libfoo.so.0 -o .libs/libfoo.so.0.0.0 foo.lo > -lc /usr/local/lib/libbar.a > > Is there a special flag/option that I need to add to get this > functionality? Try CVS libtool. Thomas Tanner - email: tanner@(ffii.org|gnu.org|gmx.de) web: http://home.pages.de/~tanner UMI: http://umi.ffii.org
Re: Link static library into libtool library
On 19-Jul-2000 Chris wrote:
>> > On Solaris, libtool does not allow me to do the following:
>> >> /bin/sh ../libtool --mode=link gcc -g -O2 -o libfoo.la -rpath
>> > /usr/local/lib foo.lo /usr/local/lib/libbar.a
>> > libtool: link: cannot build libtool library `libfoo.la' from non-libtool
>> > objects: /usr/local/lib/libbar.a
>> Libtool is right. It can't be done portably, so libtool won't do it
>> for you.
> I asked the same question a while back, and got pretty much the same
> answer. The question that I have is, "where" is this not done
> portable? I have worked around the libtool to force static libraries
> into shared libraries, and I drop those static stuffed shared libraries
> onto our other machines (Solaris), and they work just fine. So I'd say,
> Libtool is only partly right. Libtool really should provide a warning,
> and not remove those static libraries.
Yep. That's already implemented in CVS libtool:
2000-01-19 Thomas Tanner <[EMAIL PROTECTED]>
* ltmain.in: rewrite of the ILD code, merge linking code for
programs, libraries and objects, allow linking of shared libraries
against static libraries/objects on platforms that support it
but print a warning, fix some typos
Thomas Tanner -
email: tanner@(ffii.org|gnu.org|gmx.de)
web: http://home.pages.de/~tanner
UMI: http://umi.ffii.org
RE: Downtime... musings... libtool-1.4
Hi Gary, Alexandre and the rest of the team! On 11-Apr-2001 Gary V. Vaughan wrote: > I plan to clear any patches left in the queue, test on the hosts I have > access to and release libtool-1.4 from HEAD upon my return. I would be > extremely appreciative of feedback from libtool users about their experiences > with the daily snapshots between now and then... After almost one year of inactivity I can finally spend some time working on libtool. I certainly won't be able to catch up with the mailinglist but AFAICS you all have done a great job maintaining libtool! Gary, would you please delay the release of libtool 1.4 and give me two weeks to fix all the old bugs in the ILD code and libltdl (or at least to verify that they've already been fixed)? PS: can anybody please add me to the libtool group on savannah? my login name is tanner Thomas Tanner - email: tanner@(ffii.org|gnu.org|gmx.de) web: http://home.pages.de/~tanner UMI: http://umi.ffii.org ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Downtime... musings... libtool-1.4
Hi Gary, On 18-Apr-2001 Gary V. Vaughan wrote: > I'd rather not, since there is a difficult merge on the other side of the > release and I won't have the time to help Alexandre with that in 2 weeks if > we wait that long =(O| I really need to finalise 1.4 so that I can > concentrate on my book for the Summer. > > How about this: I'll release 1.4 this weekend and make a maintenance branch > so that Alexandre can make the first MLB merge. If you find any bugs after > that, we can fix them in the maintenance branch and release 1.4.1. I'm sure > we'll get a much bigger response to my call for testing on a 1.4 release than > we did with 1.3d, so I expect that a 1.4.1 release will be needed inside a > month anyhow. Well, OK. Do what you think is right. I really don't know how stable libtool-HEAD is right now. Maybe I can find and fix some bugs till this weekend. > In the mean while, I'd be happy to commit patches on your behalf if you mail > them to the patches list. Thanks. Thomas Tanner - email: tanner@(ffii.org|gnu.org|gmx.de) web: http://home.pages.de/~tanner UMI: http://umi.ffii.org ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
RE: Installing convenience libraries
On 26-Apr-2001 Nick Hudson wrote: > Is there any reason why I shouldn't be able to install a convience > library. For example > What I'd like is a archive of -fPIC compiled code. build it as static library and use the --with-pic configure option or libtool's -prefer-pic flag keep in mind that building static libraries out of PIC objects is not portable Thomas Tanner - email: tanner@(ffii.org|gnu.org|gmx.de) web: http://home.pages.de/~tanner UMI: http://umi.ffii.org ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
RE: lots of -lresolv added to command line?
Hi On 17-May-2001 Ossama Othman wrote: > /bin/sh ../../libtool --mode=link gcc -Wall -Wmissing-prototypes > -Wpointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs > -g -O2 -o ipropd-slave ipropd_slave.o libkadm5srv.la > ../../lib/hdb/libhdb.la ../../lib/krb5/libkrb5.la ../../lib/asn1/libasn1.la > -lcrypto ../../lib/vers/libvers.la ../../lib/roken/libroken.la -ldb -lgdbm > -ldl -lresolv -lresolv ^^^ simply remove the second -lresolv Thomas Tanner - email: tanner@(ffii.org|gnu.org|gmx.de) web: http://home.pages.de/~tanner UMI: http://umi.ffii.org ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
