This is the mail archive of the 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]
Other format: [Raw text]

Re: Get rid of libtool? [was Re: Makefile problems]

On Feb 26, 2002, Jeff Sturm <> wrote:

> On 25 Feb 2002, Alexandre Oliva wrote:
>> > - real incremental linking (*not* convenience libraries, which are a lousy
>> > substitute).
>> Which of the definitions of incremental linking are you talking about?

> ld -r

Libtool already uses this for some features; it would be nice if it
could use it for convenience libraries, as I have already suggested
before.  I didn't know it would cause problems on alpha, though.  More
complexity :-(

>> > For instance, libgcj assumes public data symbols are exported by
>> > default, which certainly isn't true on windows at least.
>> Are you talking of -export-dynamic or something entirely different?

> I'm talking about the dllimport/dllexport mess.  Actually the dllexport is
> solved, I think... it's the dllimport that can't be automated by libtool.

Right.  That's why libtool requires the library/application to declare
it's DLL-compliant with an autoconf macro before it gets into the
business of creating DLLs for that library.  I heard some people have
recently got around this ugly detail of Windows DLLs, though, but I've
been too much out of the loop to tell for sur

> Point is, there are characteristics of shared lib implementations that
> cannot be abstracted away... so is it worth trying?

Nope, it has to be left up to the user.  Which is what libtool does.

Alexandre Oliva   Enjoy Guarana', see
Red Hat GCC Developer                  aoliva@{,}
CS PhD student at IC-Unicamp        oliva@{,}
Free Software Evangelist                Professional serial bug killer

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