Re: annoying build environment
Hi Tim, * Tim Rice wrote: > > CVS HEAD > > Is there any reason not to have ltmain.in in the source tree > at configure time and generate ltmain.sh (from ltmain.in) in > the build tree? Please try the patch from http://lists.gnu.org/archive/html/bug-libtool/2005-08/msg00039.html > I'd like to be able to make a change in the source tree, run bootstrap, > then cd /some/build/dir, configure, make and not have it try to generate > some file in the source tree. We can't do this now. But is this possible > with the current design of CVS HEAD? I'm sorry for the inconvenience. I'll apply that patch very soon if I don't find a way of not having to distribute another almost-identical copy of ltmain. Cheers, and thanks for reporting, Ralf -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: postdeps empty on OpenBSD
On 2005-09-23, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > [ By the way, I don't think everyone in this discussion has subscribed > this list; if in doubt, speak up, or even better, set Mail-Followup-To: > next time ] I'm following it on gmane, but an explicit Cc: isn't a problem. > * Jacob Meuser wrote on Fri, Sep 23, 2005 at 04:10:36AM CEST: >> just add -lstdc++ manually. trust me, that works fine. I really don't >> see why libtool should be adding this automatically. I did wonder about getting my project's configure to always specifying "-lstdc++" if the compiler if GCC (with: test "$GXX" = yes). But I worry that I could end up trying to link in two incompatible versions of libstdc++ on a machine with multiple GCC installations. I don't really want to risk breaking other platforms to get OpenBSD to work, especially as I can document a workaround for OpenBSD users: make LDFLAGS=-lstdc++ I could write configure code to detect OpenBSD and add -lstdc++ for OpenBSD. But such system specific tests are generally the wrong approach - what if an older or newer version of OpenBSD behaves differently? Writing a configure test which builds a C++ module and C client and tries to dlopen the former from the latter would at least fix this more generally, but wouldn't work when cross-compiling, and besides seems a bit ridiculous when libtool is meant to hide shared library portability issues. >> is it _always_ needed? what about -lsupc++? > > Ahh, very good question. Here we have an issue: it should be possible > to _override_ the decision of libtool to add -lstdc++ on OpenBSD in all > cases. But those cases, in my opinion, would be the exception rather > than the rule: they are usually the cause when your package makes use of > some system-specifics anyway. (Maybe there is even a way to detect > whether supc++ is preferable over stdc++; I don't know of one, though, > and in this case guessing is probably worse than allowing an override.) > > Can we agree on this somehow? What other issues, if any, are you > experiencing? The obvious override mechanism is probably to see if the user specifies "-lsupc++" explicitly and not to add -lstdc++ if they have. Cheers, Olly ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: postdeps empty on OpenBSD
On 2005-09-22, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * Olly Betts wrote on Wed, Sep 21, 2005 at 11:00:30PM CEST: >> The bottom line for me is that if I explicitly add "-lstdc++" when >> linking _xapian.so, it all works. If I don't, it doesn't. So I >> kind of feel that ideally libtool should be doing that for me... > > ACK. I hate to break libtool on systems I cannot test, when the > maintainers may have had good reasons to do something slightly > differently than the default way, though. I've kindly been given temporary access to on an OpenBSD machine by the user who reported this issue to me. If one of the libtool maintainers would find it useful to be able to test fixes, I can ask if he'd be willing to give them temporary access too. Alternatively I can test fixes. Or I can work on a fix myself, if there's consensus on what should be done (I suspect I'll need some help and advice though...) Cheers, Olly ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: postdeps empty on OpenBSD
On 2005-09-23, Peter O'Gorman <[EMAIL PROTECTED]> wrote: > I have no statistics for how many shared libraries are written in c++ but do > not take advantage of the standard c++ library, at a guess I'd say that the > majority use some libstdc++ features. It's perhaps worth noting that not linking libstdc++ to a library that requires it means it fails to dlopen() - a fatal error. Whereas linking libstdc++ to a library which only needs libsupc++ just means that it is linked to a shared library containing more than it needs (AIUI, libsupc++ is just a very cut down version of libstdc++). Linking to libstdc++ when you could get away with libsupc++ is essentially irrelevant if you're running any other dynamically linked C++ programs. In fact it's probably slightly better if everything uses libstdc++ than some use libsupc++! To me defaulting to C++ pulling in libstdc++ makes most sense, probably with an ability to override for the minority who don't require it and care. Cheers, Olly ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: annoying build environment
Sorry for the self-followup. * Ralf Wildenhues wrote on Mon, Sep 26, 2005 at 09:02:03AM CEST: > * Tim Rice wrote: > > > > CVS HEAD > > > > Is there any reason not to have ltmain.in in the source tree > > at configure time and generate ltmain.sh (from ltmain.in) in > > the build tree? > > Please try the patch from > http://lists.gnu.org/archive/html/bug-libtool/2005-08/msg00039.html > > > I'd like to be able to make a change in the source tree, run bootstrap, > > then cd /some/build/dir, configure, make and not have it try to generate > > some file in the source tree. We can't do this now. But is this possible > > with the current design of CVS HEAD? D'oh. Said patch is not sufficient, because of the `touch' at the end of bootstrap. I'll see if we can get rid of that, it's ugly anyway. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
static vs. dynamic linking
Hi folks, how does libtool decide whether to link against an .la library dynamically vs. statically ? I'm currently working on my own implementation, since libtool doesn't suit my needs (ie. sysroot'ed building), but I didn't find any clear specification for libtool's behaviour. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool generated for tests
branch-1-5 Could someone explain why the libtool generated in the test dirs are different than the one in the build dir? Or more importanbtly, why a software package using ltmain.sh from 1.5.21a would build a libtool that didn't work but copying libtool from my libtool build dir would work. The differences looked similar to the ones below. --- depdemo/libtool 2005-09-26 16:03:23.949817104 -0700 +++ libtool 2005-09-26 15:57:57.144777437 -0700 @@ -1,7 +1,7 @@ #! /bin/ksh # libtoolT - Provide generalized library-building support services. -# Generated automatically by (GNU depdemo 0.1) +# Generated automatically by (GNU libtool 1.5.21a (1.1220.2.300 2005/09/25 07:37:09)) # NOTE: Changes made to this file will be lost: look at ltmain.sh. # # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001 @@ -53,7 +53,7 @@ build_libtool_libs=yes # Whether or not to build static libraries. -build_old_libs=no +build_old_libs=yes # Whether or not to add -lc for building shared libraries. build_libtool_need_lc=no @@ -70,7 +70,7 @@ host_os=sysv5UnixWare7.1.4 # The build system. -build_alias=i686-unknown-sysv5UnixWare7.1.4 +build_alias= build=i686-unknown-sysv5UnixWare7.1.4 build_os=sysv5UnixWare7.1.4 @@ -159,10 +159,10 @@ need_version=no # Whether dlopen is supported. -dlopen_support=unknown +dlopen_support=yes # Whether dlopen of programs is supported. -dlopen_self=unknown +dlopen_self=no # Whether dlopen of statically linked programs is supported. dlopen_self_static=unknown @@ -6896,7 +6896,7 @@ build_libtool_libs=yes # Whether or not to build static libraries. -build_old_libs=no +build_old_libs=yes # Whether or not to add -lc for building shared libraries. build_libtool_need_lc=no @@ -6913,7 +6913,7 @@ host_os=sysv5UnixWare7.1.4 # The build system. -build_alias=i686-unknown-sysv5UnixWare7.1.4 +build_alias= build=i686-unknown-sysv5UnixWare7.1.4 build_os=sysv5UnixWare7.1.4 @@ -7002,10 +7002,10 @@ need_version=no # Whether dlopen is supported. -dlopen_support=unknown +dlopen_support=yes # Whether dlopen of programs is supported. -dlopen_self=unknown +dlopen_self=no # Whether dlopen of statically linked programs is supported. dlopen_self_static=unknown -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: postdeps empty on OpenBSD
On Mon, Sep 26, 2005 at 04:15:11PM +, Olly Betts wrote: > On 2005-09-23, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > [ By the way, I don't think everyone in this discussion has subscribed > > this list; if in doubt, speak up, or even better, set Mail-Followup-To: > > next time ] > > I'm following it on gmane, but an explicit Cc: isn't a problem. > > > * Jacob Meuser wrote on Fri, Sep 23, 2005 at 04:10:36AM CEST: > >> just add -lstdc++ manually. trust me, that works fine. I really don't > >> see why libtool should be adding this automatically. > > I did wonder about getting my project's configure to always specifying > "-lstdc++" if the compiler if GCC (with: test "$GXX" = yes). > > But I worry that I could end up trying to link in two incompatible > versions of libstdc++ on a machine with multiple GCC installations. are you saying that on some platforms, you actually get -L/path/to -lstdc++? I don't think I've seen that one yet. certainly don't see that in the `g++ -shared -v' output you posted before. so how is libtool going to help with this? > I don't really want to risk breaking other platforms to get OpenBSD to > work, especially as I can document a workaround for OpenBSD users: > > make LDFLAGS=-lstdc++ > > I could write configure code to detect OpenBSD and add -lstdc++ for > OpenBSD. But such system specific tests are generally the wrong > approach - what if an older or newer version of OpenBSD behaves > differently? Writing a configure test which builds a C++ module and C > client and tries to dlopen the former from the latter would at least fix > this more generally, but wouldn't work when cross-compiling, and besides > seems a bit ridiculous when libtool is meant to hide shared library > portability issues. > > >> is it _always_ needed? what about -lsupc++? > > > > Ahh, very good question. Here we have an issue: it should be possible > > to _override_ the decision of libtool to add -lstdc++ on OpenBSD in all > > cases. But those cases, in my opinion, would be the exception rather > > than the rule: they are usually the cause when your package makes use of > > some system-specifics anyway. (Maybe there is even a way to detect > > whether supc++ is preferable over stdc++; I don't know of one, though, > > and in this case guessing is probably worse than allowing an override.) > > > > Can we agree on this somehow? What other issues, if any, are you > > experiencing? > > The obvious override mechanism is probably to see if the user specifies > "-lsupc++" explicitly and not to add -lstdc++ if they have. what I don't get, is that at one point, libtool assumes the linker knows what it's doing, and copies it. but then maybe what it's doing is not right? I think perhaps you should ask [EMAIL PROTECTED] about this. he might be able to explain why -lstdc++ is not implicitly used in `g++ -shared', which could give you a good starting point on how to "fix" the "problem". -- <[EMAIL PROTECTED]> ___ http://lists.gnu.org/mailman/listinfo/libtool
