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 25 Feb 2002, Alexandre Oliva wrote:
> There are a lot of small details that, when
> added up, may turn into enough of a hassle that a lot of libtool's
> built-in intelligence ends up having to be duplicated, and poorly.

Isn't that happening already for libgcc_s?

> The only advantage I see for GCC in keep on using libtool is the
> abstraction.

But when we need a great deal of control over how the shared lib is built
we have to get past the abstraction layer anyway.

For any casual, naive attempts to build a shared lib I would
wholeheartedly recommend libtool.  For specific use like libgcj (and
probably libstdc++) it is more debateable.

Things I'd like to see (in no particular order):

- symbol versioning (libgcj doesn't currently do this, but it could, and
probably should).  This is platform and tool specific, and to my knowledge
libtool doesn't provide any assistance.

- real incremental linking (*not* convenience libraries, which are a lousy

- better performance (why couldn't some rules be baked into the makefile
rather than evaluated for each compilation?).

> Is it really worth to ditch
> it in favor of a more limited solution that will require effort to put
> in place and maintain?  I'm not sure.

For libgcj, we could always fall back to static-only on targets where we
don't know how to build shared libs.  I don't have much confidence that
such targets would work even with libtool anyhow.  For instance, libgcj
assumes public data symbols are exported by default, which certainly isn't
true on windows at least.  That sort of detail isn't hidden by libtool's


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