bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Missing LDFLAGS in libtool


From: Ralf Wildenhues
Subject: Re: Missing LDFLAGS in libtool
Date: Mon, 10 Oct 2005 17:43:17 +0200
User-agent: Mutt/1.5.11

Hi Neil,

I have added bug-libtool in Cc: again -- this might be interesting to
other users experiencing similar issues.  I've also added you to the
list of allowed posters there; unless someone forgets inadvertantly,
we do this for all posters so that you get moderated only once.  Sorry
for the inconvenience.

Now to your reply:

* Neil Kirr wrote on Sun, Oct 09, 2005 at 03:35:34PM CEST:
> * Ralf Wildenhues wrote:
> > * Neil Kirr wrote on Sat, Oct 08, 2005 at 07:40:58PM CEST:
> > > 
> > > I was trying to build libtool with a STATIC lib_gcc instead of the 
> > > evil shared libgcc_s.so.  To my surprise I found that I had to edit 
> > > this file in order for it to build the shared libraries with the 
> > > --static-libgcc:
*snip*
> > > This correctly compiles using the --static-libgcc flag (assuming the 
> > > user set their LDFLAGS environment variable).  This was on Solaris 9.
> > 
> > Thank you for the bug report.  This change is not correct, however. Linker
> > flags are supposed to be interpreted by `libtool', because it may have to
> > adjust (both itself and them).  Having LDFLAGS directly in $archive_cmds is
> > just wrong, as it bypasses this.
*snip*
> > Can you try configuring libtool like this as a workaround 
> >   configure CXX='g++ -static-libgcc'
>
> I will try it and let you know.

Thanks.

> > By the way, GCC documentation has reasons to suggest using shared libgcc
> > over static for shared C++ libraries (but I guess you knew that).
> 
> I am no coding expert, I just know that I want my stuff to compile with
> --static-libgcc.  Why?  Because then I don't have to push the shared libgcc
> library to EVERY host on the network!  And this also has the benefit of
> creating independence among compiled applications on each host.  If someone
> modified the shared libgcc object (say with a new version of GCC) them I'm
> NOT hosed or affected in any way.  And with a shared library, I might be...

Fair enough.  You give two good reasons that in your specific example,
-static-libgcc is more appropriate than the default.  Other possible
reasons would be slighly improved efficiency though less relocations.

Your second argument might also be an argument against using it: if the
admin installs a package update of GCC with, say, some bug in libgcc
fixed, you won't need to recompile your library.  Also, you do not seem
to need working exception handling.  The latter is the main reason that
the shared version should be used by default, I believe.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]