Re: static vs. dynamic linking
Hi Enrico,
* Enrico Weigelt wrote on Mon, Sep 26, 2005 at 09:56:27PM CEST:
>
> how does libtool decide whether to link against an .la library
> dynamically vs. statically ?
For a program or a library? Uninstalled or installed library
(see recent bug report of Howard Chu)? On a system with both
static and shared libraries, or just one of them? When the user
has configured --{enable,disable}-{static,shared} or added
-static or -all-static? For a normal dependency library or a
module dependency, or maybe a convenience archive?
> 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.
We have better support for sysroot and/or DESTDIR on our TODO list.
Why don't you help us improve and fix libtool? That is bound to be
a lot less work.
Please note that we have received and rejected patches concerning
this at times, but only when the patches did not fix the real issue
but only lessened the experienced problems (for the specific problem
the patch-submitter encountered). We have discussed this issue a
number of times, some threads give valuable data points what to look
out for. If you are interested, I can post some links.
*time passes*
http://lists.gnu.org/archive/html/libtool-patches/2005-06/msg00161.html
Oh, you asked before. Why not rather fix your patch than rewrite from
scratch?
Let me give you a hint, and it's not meant to discourage you: I've
not been involved with Libtool for very long by any means, I know it
has lots of shortcomings and bugs, but I do know that it's the
result of a lot of work gone into it by a lot of people; repeating
that is far from trivial. I've decided for myself it's easier to
fix Libtool. And you get all fixed packages for free.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
SYSROOT/DESTDIR (was Re: static vs. dynamic linking)
Ralf Wildenhues wrote: We have better support for sysroot and/or DESTDIR on our TODO list. Why don't you help us improve and fix libtool? That is bound to be a lot less work. *time passes* http://lists.gnu.org/archive/html/libtool-patches/2005-06/msg00161.html Oh, you asked before. Why not rather fix your patch than rewrite from scratch? Have we got an exhaustive list of problems related to this particular issue? This is definitely a pain my side; I've been maintaining custom hacks for our own builds for a couple of years now and it's getting mighty old. First of all, my objective - other folks may have their own objectives different than this: Build a suite of software that uses shared libraries, such that any embedded runpaths only reflect the ultimate install path (e.g. /opt/foo/lib) and not any of the build paths (e.g. ~/src/project1/blah). So far this issue is relevant to us on AIX, HPUX, Linux, and Solaris. In all cases, it's possible to set an environment variable (LIBPATH, SHLIB_PATH, or LD_LIBRARY_PATH, respectively) to tell the runtime linker where to really look, regardless of any embedded paths. So my preferred behavior would be for build paths to never be embedded in the object files (this also eliminates any need for relinking). Since libtool will generate wrapper scripts that setup the proper environment for executables anyway, I don't see any problem with achieving this. Currently libtool tries to be "clever" and always prepends build paths to any explicitly provided -R/-rpath options, and I usually comment that bit out of libtool in our builds. It seems like a pretty simple thing to get working, without any negative side effects. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: postdeps empty on OpenBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jacob Meuser wrote: | 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". | I already asked him. He replied "It won't change, we do not link shared libraries together when we can avoid it." Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQzlD8biDAg3OZTLPAQLLZwP+MiXSyXqWIjAUHJoT9ogofXlAs7irG7LL ZLOAtAlry+4IifCREMXaatFZ73qWGPsU2RZ4v/l0WTE6tb+Il/z+9VS33tOsQ5F4 hDUqdOnrgVoLXVf5hXePHP8qD1cd0JcjrnnTb3/WuERKYaerE3/ubOgjuM6pkeWX JMrqWWyZyos= =caV9 -END PGP SIGNATURE- ___ http://lists.gnu.org/mailman/listinfo/libtool
sh portability questions
Now that there are no doubts about the portability of shell functions
(in the sense that there's always a shell on the machine that supports
function ---and maybe the documentation should reflect this), I'm
curious about the support of "return" and "local". Is there anything
known about them? ISTR there were spies about return in the Autoconf
test suite, but there seems to be nothing about it today
(hum... wrong, there is now something in m4sh.m4 that looks for
"return" support, see below).
Thanks!
# _AS_SHELL_FN_WORK
# -
# This is a spy to detect "in the wild" shells that do not support shell
# functions correctly. It is based on the m4sh.at Autotest testcases.
m4_define([_AS_SHELL_FN_WORK],
[as_func_return () {
(exit [$]1)
}
as_func_success () {
as_func_return 0
}
as_func_failure () {
as_func_return 1
}
as_func_ret_success () {
return 0
}
as_func_ret_failure () {
return 1
}
exitcode=0
AS_IF([as_func_success], [],
[exitcode=1
echo as_func_success failed.])
AS_IF([as_func_failure],
[exitcode=1
echo as_func_failure succeeded.])
AS_IF([as_func_ret_success], [],
[exitcode=1
echo as_func_ret_success failed.])
AS_IF([as_func_ret_failure],
[exitcode=1
echo as_func_ret_failure succeeded.])
AS_IF([( set x; as_func_ret_success y && test x = "[$]1" )], [],
[exitcode=1
echo positional parameters were not saved.])
test $exitcode = 0])
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: static vs. dynamic linking
* Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
Hi,
> > how does libtool decide whether to link against an .la library
> > dynamically vs. statically ?
>
> For a program or a library? Uninstalled or installed library
> (see recent bug report of Howard Chu)?
Each of these cases ...
I've now figured out, that libs without rpath are linked statically.
It seems the chain starts at the Makefile.am file where some libs
are defined not to be installed. These libs don't get an --rpath
option, so the resulting .la file has no (or empty) libdir.
In the end these libs are linked statically.
Very mustic.
> On a system with both static and shared libraries, or just one of
> them? When the user has configured --{enable,disable}-{static,shared}
> or added -static or -all-static?
GNU/Linux, i686, GCC.
> For a normal dependency library or a
> module dependency, or maybe a convenience archive?
Your dozens of questions show an lack of clear definitions ...
Isn't there any document which describes what is done in these
situations (not the actual command line, but at least the actions) ?!
> > 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.
>
> We have better support for sysroot and/or DESTDIR on our TODO list.
Yes, its been there for quite a while. Todo-Lists dont help me,
I have to get things working right now.
> Why don't you help us improve and fix libtool? That is bound to be
> a lot less work.
I've tried. But I had to find out that it's not repairable in a
considerable time.
BTW: I dislike the concept of libtool at all (not the fact that
we have an tool for building libs, but the way it works, ie. the
unclean command line options, the quite unspecified behaviour, etc).
This applies to the whole autotools stuff.
That's why I started my own toolchain abstraction, with an libtool
compatible frontend.
You may have a look at it:
cvs://anonymous:[EMAIL PROTECTED]/unitool/
The idea bind is: you have a very minimalistic command set with
an very simple syntax. No platform dependent stuff is visible here,
neither what compiler you use. Evrythings hidden behind unitool.
No more annying and unreliable autodetection on every package.
For each toolchain an unitool instance is configured *once*,
maybe with the help of some autoconfiguration, and then it's just
passed to the individual package.
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
Re: postdeps empty on OpenBSD
[Cc:-ed to Mark Espie at Jacob's suggestion: > 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' If you need context, this is the whole thread: http://thread.gmane.org/gmane.comp.gnu.libtool.general/6671 ] On 2005-09-27, Jacob Meuser <[EMAIL PROTECTED]> wrote: > On Mon, Sep 26, 2005 at 04:15:11PM +, Olly Betts wrote: >> 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++? You certainly do in some cases. The one I've seen is with a private build of GCC installed in a non-standard path (on Linux). Then I get the following in dependency_libs in the .la file (amongst other things I've pruned for clarity): -L/u1/olly/install/lib /u1/olly/install/lib/./libstdc++.la /u1/olly/install/lib/./libstdc++.la I'm not sure why libstdc++.la is there twice... If I explicitly specify LDFLAGS=-lstdc++, then the explicit libstdc++ appears before the -L above. So (for example) it would pull libstdc++ from /usr/lib if there's one there... I don't have access to the openbsd box right now to test, but I'd imagine I'd get the exact same effect if I installed a private build of GCC in my home directory on openbsd and used it. > 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? My point here is that I'm not happy with the suggested approach of always explicitly linking with libstdc++. In some situations I believe that will break builds which currently work by picking up the wrong libstdc++ (or trying to link in two different copies of libstdc++). Even always explicitly linking with libstdc++ conditional on $host_os matching openbsd* seems like it'll risk getting this wrong in some cases (although at least only on a platform which doesn't work at present anyway). So libtool could help by encapsulating the knowledge of when libstdc++ needs to be explicitly specified. >> 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? Well, "not right" is perhaps a bit of a loaded phrase. But the current openbsd linker's approach is problematic in the case here where I'm linking a C++ module to be loaded via dlopen from a C program. The linker doesn't add a dependency on libstdc++, and the C program doesn't have a dependency on libstdc++ either, so the dlopen fails with unresolved symbols. While this may seem like something of a corner case, many programs are written in C and support loading of modules - python was the particular case here, but most scripting languages support it (perl, php, etc). So does apache, as another example. Cheers, Olly ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: postdeps empty on OpenBSD
On 2005-09-22, Peter O'Gorman <[EMAIL PROTECTED]> wrote: > Do we know what the versions of the OS/gcc are where -lstdc++ is missing? We > can enplicitly add it (as we did recently for, I think, sunpro c++). Is this > a gcc bug, or is it by design? I've only been able to test OpenBSD 3.7 with g++ 3.3.5. It appears to be an OpenBSD linker design decision from what various people have been saying. Cheers, Olly ___ http://lists.gnu.org/mailman/listinfo/libtool
A versionized variation on `lt_dlopen ()'
Hi, After reading a recent thread on `guile-user', it occurred to me that `lt_dlopenext ()' doesn't allow to pass information about the version of a module that is requested. This is quite unfortunate, especially for Guile, since Guile modules load C libraries using `dynamic-link' which is roughly the Scheme version of `lt_dlopenext ()'. This precludes having several versions of a given extension installed at once since each of these versions need to load a particular version of its companion C library. So, I think it would be very nice to have something like: /* Open a module with the file name FILENAME which is compatible with revision REVISION of interface INTERFACE. The module should have been linked with `-version-info'. */ lt_dlhandle lt_dlopen_version (const char *filename, unsigned interface, unsigned revision); And similarly for `lt_dlopenext ()'. And I believe this may also be useful for other kinds of programs, like programs that use plug-ins (for instance, plug-ins could be compiled with a `-version-info' that reflects the version of the plug-in API exposed by the program). What do you think? Thanks, Ludovic. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: SYSROOT/DESTDIR
Hi Howard, * Howard Chu wrote on Tue, Sep 27, 2005 at 12:01:22PM CEST: > Ralf Wildenhues wrote: > >We have better support for sysroot and/or DESTDIR on our TODO list. > >Why don't you help us improve and fix libtool? That is bound to be > >a lot less work. > >http://lists.gnu.org/archive/html/libtool-patches/2005-06/msg00161.html > > Have we got an exhaustive list of problems related to this particular > issue? Well, probably not exhaustive, but I've made notes here and there. I'll try to collect things together, and hope to post more in a couple of days. Above link lists some issues. Incidentally, the TODO list already cites an email by you :) http://lists.gnu.org/archive/html/libtool/2004-11/msg00307.html and Daniel reed once described what people might want when they use DESTDIR (although we might not allow all of that): http://lists.gnu.org/archive/html/libtool-patches/2005-01/msg00203.html Under linux, accessing hardwired /etc/ld.so.conf needs adapting: http://lists.gnu.org/archive/html/libtool/2004-11/msg00366.html The issue of normalizing paths is unfortunately hard/impossible, and: http://lists.gnu.org/archive/html/libtool/2005-01/msg00210.html is broken ($A/foo/../$B is not equal to $A/$B if foo is a symlink going not exactly one level down). > First of all, my objective - other folks may have their own objectives > different than this: Build a suite of software that uses shared > libraries, such that any embedded runpaths only reflect the ultimate > install path (e.g. /opt/foo/lib) and not any of the build paths (e.g. > ~/src/project1/blah). Hmm, yes, the idea is good. But at the time you configure and build a package which relies on an already-installed library (with its correct final embedded runpath, but found under a different location _now_), you'll have to start dancing anyway. > So far this issue is relevant to us on AIX, HPUX, Linux, and Solaris. In > all cases, it's possible to set an environment variable (LIBPATH, > SHLIB_PATH, or LD_LIBRARY_PATH, respectively) to tell the runtime linker > where to really look, regardless of any embedded paths. So my preferred > behavior would be for build paths to never be embedded in the object > files (this also eliminates any need for relinking). That'll work for the runtime linker, but not for the link editor (in all cases). OTOH: which of these systems have linkers with sysroot support? I believe proper support on capable systems is still worth a lot even if we can't realize this on all systems. > Since libtool will > generate wrapper scripts that setup the proper environment for > executables anyway, I don't see any problem with achieving this. > Currently libtool tries to be "clever" and always prepends build paths > to any explicitly provided -R/-rpath options, and I usually comment that > bit out of libtool in our builds. Hmm. It might be reasonable to add this as a link-time option or so. Disabling this for uninstalled libraries/programs sounds much safer than doing so for installed ones. > It seems like a pretty simple thing to get working, without any negative > side effects. I don't overlook this completely yet, but having this as an option (not the default) is bound to be rather safe. One of my ideas was to support basically two modes of operation: 1) You have a package you install somewhere; that is not the final destination (thus you use DESTDIR), but it will basically operate on the build system. But other components (deplibs, config files) you access may be found outside of the $DESTDIR (or inside?). 2) Your host system has nothing in common with / and all lives under some subtree, let's call it SYSROOT. Cross compilation is an example of this. Following this, and maybe for safety calling the necessary variables $LT_DESTDIR and $LT_SYSROOT, and presuming we have this information available already at configure time we can go about changing libtool incrementally. Making these two match with the non-prefixed ones is then trivial, but if it works against ones habits, possible to keep them separated. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: SYSROOT/DESTDIR (was Re: static vs. dynamic linking)
On Tue, 27 Sep 2005, Howard Chu wrote: > First of all, my objective - other folks may have their own objectives > different than this: Build a suite of software that uses shared libraries, > such that any embedded runpaths only reflect the ultimate install path (e.g. > /opt/foo/lib) and not any of the build paths (e.g. ~/src/project1/blah). > I'd like to be able have the embedded runpath be /opt/lib even if I install in /opt/foo/lib. (the package posinstall script would put symbolic links in /opt/lib) -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: static vs. dynamic linking
Hi Enrico,
* Enrico Weigelt wrote on Tue, Sep 27, 2005 at 03:27:21PM CEST:
> * Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
>
> > > how does libtool decide whether to link against an .la library
> > > dynamically vs. statically ?
> >
> > For a program or a library? Uninstalled or installed library
> Each of these cases ...
>
> I've now figured out, that libs without rpath are linked statically.
> It seems the chain starts at the Makefile.am file where some libs
> are defined not to be installed. These libs don't get an --rpath
> option, so the resulting .la file has no (or empty) libdir.
> In the end these libs are linked statically.
>
> Very mustic.
Not at all. It is all documented quite extensively in the Automake and
the Libtool documentation. This specific answer is given in
info libtool "Linking executables"
and
info libtool "Linking libraries",
and, by the way, has little to do with your question. You asked about
when linking some output _against_ a library statically or dynamically,
not when _creating_ a static or dynamic library.
> > On a system with both static and shared libraries, or just one of
> > them? When the user has configured --{enable,disable}-{static,shared}
> > or added -static or -all-static?
>
> GNU/Linux, i686, GCC.
>
> > For a normal dependency library or a
> > module dependency, or maybe a convenience archive?
>
> Your dozens of questions show an lack of clear definitions ...
Not at all either. Your guessing shows you did not read documentation.
> Isn't there any document which describes what is done in these
> situations (not the actual command line, but at least the actions) ?!
Yes, there is. See above. No, the manual is not short.
> > We have better support for sysroot and/or DESTDIR on our TODO list.
>
> Yes, its been there for quite a while. Todo-Lists dont help me,
> I have to get things working right now.
Oh, sure. You can probably find someone that implements it for you
in a given time frame, if you pay for it.
> > Why don't you help us improve and fix libtool? That is bound to be
> > a lot less work.
>
> I've tried. But I had to find out that it's not repairable in a
> considerable time.
Well, for one you did not even bother to answer any questions I asked
back when you reported this first. Neither asked whatever else you
needed to know, or showed what you've tried (except the first patch).
> BTW: I dislike the concept of libtool at all (not the fact that
> we have an tool for building libs, but the way it works, ie. the
> unclean command line options, the quite unspecified behaviour, etc).
> This applies to the whole autotools stuff.
Sorry, I love to discuss technical matters even if people disagree with
me or do not use the tools I use. I don't mind at all.
(We even go to lengths to make libltdl usable in projects without
Autoconf/Automake)
But I _do_ dislike unqualified bashing. Get your facts straight, read
documentation of whatever tools you use, and _then_ complain about
whatever doesn't work or what should be done differently. I told you
that last time as well.
> That's why I started my own toolchain abstraction, with an libtool
> compatible frontend.
How can it be libtool compatible if you don't know how libtool works?
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: SYSROOT/DESTDIR
Hi Tim, * Tim Rice wrote on Tue, Sep 27, 2005 at 07:56:31PM CEST: > On Tue, 27 Sep 2005, Howard Chu wrote: > > > First of all, my objective - other folks may have their own objectives > > different than this: Build a suite of software that uses shared libraries, > > such that any embedded runpaths only reflect the ultimate install path (e.g. > > /opt/foo/lib) and not any of the build paths (e.g. ~/src/project1/blah). > > I'd like to be able have the embedded runpath be /opt/lib even > if I install in /opt/foo/lib. (the package posinstall script would put > symbolic links in /opt/lib) I believe that should be possible now, although in a bit weird way: configure --prefix=/opt --enable-fast-install [OPTIONS] make make install DESTDIR=/tmp $mkdir_p /opt/foo mv /tmp/opt/* /opt/foo # create symlinks .. ./libtool --mode=finish /opt/lib (surely you can also use some other path below /opt as DESTDIR to avoid another copy if /tmp is on another mount point). Did I miss anything? Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: sh portability questions
Akim Demaille <[EMAIL PROTECTED]> writes: > Now that there are no doubts about the portability of shell functions > (in the sense that there's always a shell on the machine that supports > function ---and maybe the documentation should reflect this), Yes, it should. > I'm curious about the support of "return" and "local". "return" is specified in POSIX 1003.2-1992 and later, so I wouldn't have any qualms about assuming that there is a shell on the machine that supports it. "local" isn't in POSIX so I'd avoid it in portable scripts. Admittedly it is in Bash and ksh, so it's pretty portable to the larger Unix hosts, but I'm not so sure about other environments. For what it's worth, I briefly searched for this issue and found these bug reports dated this year where someone used "local" in a shell script and someone else complained and fixed it. http://www.networksecurityarchive.org/html/Secure-Shell/2005-02/msg00067.html http://packages.debian.org/changelogs/pool/main/x/xfree86/xfree86_4.3.0.dfsg.1-14/changelog Is "local" that crucial? Admittedly it's very annoying to lack local variables, but you can always solve it by renaming. (Unless you want to use recursion. Is that a goal here?) Assuming you don't need recursion, here's a thought. Use "local", but stick to the convention that all variable names are unique. On systems that don't support "local", define a function named "local" that warns if any of its arguments is a variable whose value is set; the "local" function is otherwise a no-op. That would catch most errors on these hosts, where we inadvertently use a local variable name that collides with a global one. It's just a runtime test (and not a complete one at that), but it'd be better than nothing. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: sh portability questions
Andreas Schwab <[EMAIL PROTECTED]> writes: > Paul Eggert <[EMAIL PROTECTED]> writes: > >> Assuming you don't need recursion, here's a thought. Use "local", but >> stick to the convention that all variable names are unique. On >> systems that don't support "local", define a function named "local" >> that warns if any of its arguments is a variable whose value is set; > > That would also (spuriously) warn if you call a function with local > variables a second time, unless you explicitly unset the local variables > before returning. Ouch. You're right. I guess the best we can do is define a function "local" that does nothing. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: sh portability questions
Paul Eggert <[EMAIL PROTECTED]> writes: > Assuming you don't need recursion, here's a thought. Use "local", but > stick to the convention that all variable names are unique. On > systems that don't support "local", define a function named "local" > that warns if any of its arguments is a variable whose value is set; That would also (spuriously) warn if you call a function with local variables a second time, unless you explicitly unset the local variables before returning. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: SYSROOT/DESTDIR
On Tue, 27 Sep 2005, Ralf Wildenhues wrote: > Hi Tim, > > * Tim Rice wrote on Tue, Sep 27, 2005 at 07:56:31PM CEST: > > I'd like to be able have the embedded runpath be /opt/lib even > > if I install in /opt/foo/lib. (the package posinstall script would put > > symbolic links in /opt/lib) > > I believe that should be possible now, although in a bit weird way: > configure --prefix=/opt --enable-fast-install [OPTIONS] > make > make install DESTDIR=/tmp > $mkdir_p /opt/foo > mv /tmp/opt/* /opt/foo > # create symlinks .. > ./libtool --mode=finish /opt/lib > (surely you can also use some other path below /opt as DESTDIR to avoid > another copy if /tmp is on another mount point). Hmm, that may work. I'll have to try it sometime. It'll require some serious changes to my package build scripts. :-( Thanks. > > Did I miss anything? > > Cheers, > Ralf > -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: postdeps empty on OpenBSD
On Tue, Sep 27, 2005 at 01:31:37PM +, Olly Betts wrote: > [Cc:-ed to Mark Espie at Jacob's suggestion: > > 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' > > If you need context, this is the whole thread: > http://thread.gmane.org/gmane.comp.gnu.libtool.general/6671 > ] > > On 2005-09-27, Jacob Meuser <[EMAIL PROTECTED]> wrote: > > On Mon, Sep 26, 2005 at 04:15:11PM +, Olly Betts wrote: > >> 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++? > > You certainly do in some cases. The one I've seen is with a private > build of GCC installed in a non-standard path (on Linux). Then I get > the following in dependency_libs in the .la file (amongst other things > I've pruned for clarity): > > -L/u1/olly/install/lib /u1/olly/install/lib/./libstdc++.la > /u1/olly/install/lib/./libstdc++.la OK > I'm not sure why libstdc++.la is there twice... > > If I explicitly specify LDFLAGS=-lstdc++, then the explicit libstdc++ > appears before the -L above. So (for example) it would pull libstdc++ > from /usr/lib if there's one there... yes > I don't have access to the openbsd box right now to test, but I'd > imagine I'd get the exact same effect if I installed a private build of > GCC in my home directory on openbsd and used it. probably so > > 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? > > My point here is that I'm not happy with the suggested approach of > always explicitly linking with libstdc++. In some situations I believe > that will break builds which currently work by picking up the wrong > libstdc++ (or trying to link in two different copies of libstdc++). > > Even always explicitly linking with libstdc++ conditional on $host_os > matching openbsd* seems like it'll risk getting this wrong in some > cases (although at least only on a platform which doesn't work at > present anyway). > > So libtool could help by encapsulating the knowledge of when libstdc++ > needs to be explicitly specified. but how does libtool know that? > >> 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? > > Well, "not right" is perhaps a bit of a loaded phrase. But the current > openbsd linker's approach is problematic in the case here where I'm > linking a C++ module to be loaded via dlopen from a C program. The > linker doesn't add a dependency on libstdc++, and the C program doesn't > have a dependency on libstdc++ either, so the dlopen fails with > unresolved symbols. right. the module should be linked to libstdc++, not the program. and yes, on OpenBSD, you will not het this automatically, you must add it explicitly. > While this may seem like something of a corner case, many programs are > written in C and support loading of modules - python was the particular > case here, but most scripting languages support it (perl, php, etc). > So does apache, as another example. yes. I work with transcode (transcoding.org), which is a C program that loads modules. some modules are written in C++. it works on OpenBSD with the C++ modules linked to libstdc++. this is done unconditionally in the Makefile.ams with 'modfoo_la_LIBADD = -lstdc++'. I have not had a complaint about this method, but maybe no one's actually built such a module for transcode while using a non-system g++? -- <[EMAIL PROTECTED]> ___ http://lists.gnu.org/mailman/listinfo/libtool
