Re: libltdl should not always use LT_GLOBAL

[Alexandre Oliva]

On Mar 27, 2004, Bob Friesenhahn <address@hidden> wrote:

> On 27 Mar 2004, Alexandre Oliva wrote:
>> On Mar 13, 2004, Scott James Remnant <address@hidden> wrote:
>> 
>> > This flag causes the external symbols defined in the library to be made
>> > available for symbol resolution of subsequently loaded libraries.  This
>> > isn't the default behaviour of dlopen().
>> 
>> But it is the default behavior of static linking.  Remember that
>> libtool is not about creating shared libraries, it's about giving a
>> unified abstraction of libraries.  This implies that the least common

> I disagree.  Libtool is all about creating shared libraries.

in a portable way, if possible.

The problem is that there are so many people that have no idea about
the portability issues related with shared libraries that they get
surprised whenever they attempt to create a shared library on AMD64
and it fails because they tried to link non-PIC into the library.

IMHO, the earlier libtool lets them know that they're using
non-portable constructs, the better.

> Modern systems that don't support dynamic loading are very rare.

But users choosing to disable shared libraries is not, and most
packages that use libtool-created -modules will be just as broken when
you do that.

> It would be a very odd package indeed which was only developed on
> one of these rare systems and then encountered problems on a normal
> system.

It's the other way round that's the problem.  GNU/Linux/x86 systems,
where most people develop nowadays, are far too permissive, so people
end up assuming that's the way works and are surprised when they
application fails to work properly on other platforms.  And then they
come back to me and complain that libtool didn't offer the portable
interface.  At such times, I wish libtool just wasn't as permissive by
default, and forced developers to think about the portability
mis-assumptions they're making.  But then, nobody cares about the
several warnings we print ATM, so why would anyone care about any
other warnings we might print? :-(

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   address@hidden, gcc.gnu.org}
Free Software Evangelist  address@hidden, gnu.org}