Re: EDE: make project shared objects

[Sascha Wilde]

Miles Bader <address@hidden> wrote:
> Stefan Monnier <address@hidden> writes:
>>> It would be best to use libtool for linking programs, too -- at least
>>> when they are linked against shared libraries which are part of the
>>> project.  But this also makes only sense with an install target.
>>
>> I do not have a strong opinion on this, but IIUC while autoconf seems to
>> be usually appreciated, and mostly so as well for automake (tho to
>> a lesser extent), libtool has many more detractors because it is a lot
>> more invasive.

While statements like this are not uncommon, I miss in many cases a
clear explanation what the actual downsides of libtool are.[0]

>> So it might be good to support projects using libtool, but I think it
>> is important not to impose it.

The current situation is that the EDE make projects don't work for
libraries at all and getting them to work is easiest achieved by using
libtool.

In a next step we could try to get it work even without libtool (EDE's
concept of selectable compiler and linker templates makes it easy to
support different strategies), BUT getting this right (including library
versioning, rpath, in place testing of dynamically linked binaries)
isn't trivial.  And getting it sufficiently portable would mean to
duplicate the affords of libtool in great lengths.  It might be
worthwhile if we could do better than libtool with respect to being less
"invasive" (for what ever that means) but I doubt its worth the trouble.

> The last time I attempted to use libtool, it was a huge mess; it seemed
> to be trying so hard to be portable that it ended up being barely
> usable.

I think portability is an important goal and IMO libtool does a
remarkable job simplifying the tedious task of building libraries on
different platforms.  If you can give a short summary why using it was a
"huge mess" in your project I would be very interested.  I'd really like
to understand what the common problems with libtool are.

cheers
sascha

[0] The most famous discussion on this topic is the "debian against libtool"
    case, which was about the unconditional use of rpath by libtool.  In
    the end it turned out, that the whole fuzz was really caused neither
    by libtool nor by rpath in general but by an insufficient
    compatibility hack in the run time linker on the transition from
    libc5 to libc6:
    http://lists.debian.org/debian-devel/1999/01/msg02570.html
-- 
Sascha Wilde
We're Germans and we use Unix. That's a combination of two 
demographic groups known to have no sense of humour whatsoever.
  -- Hanno Mueller in de.comp.os.unix.programming