This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [patch] releases.html


On Feb 14, 2001, "Zack Weinberg" <zackw@stanford.edu> wrote:

> Yabbut, thing is, I can do that in twenty lines of Makefile on any
> platform that doesn't care what the extension of object files is.

Unfortunately, there are a number of platforms that do.  And we
learned that the hard way.

> Or I can do it shorter and without weird extensions on any platform
> where it's okay to put -fPIC code in a static library.

I agree creating shared libraries is relatively easy.  Except on
platforms that require the creation of export lists, of course.  And
on those that require special flags in case you want to be able to
dlopen the library.

It's using them correctly that is more difficult.  Think of one
library depending on another (which not all systems support, so you
have to manage dependencies externally), and of programs linked with
multiple libraries, making them use the correct libraries when run on
both the build tree and the install tree.  That's the reason for the
complexity of libtool.

> Random thought: what if we made

> 	gcc -staticlib -o libfoo.a a.o b.o c.o ...

> run ar and possibly ranlib as appropriate to the target?

Good idea.  We should probably aim at adding support for -R on all
platforms GCC supports, as Joe Buck suggested.  It would certainly
make it much easier to port libtool to a certain platform, using GCC
:-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]