Re: [Fwd: ltmain.in]

[Alexandre Oliva]

On Mar 26, 2002, address@hidden wrote:

> address@hidden wrote:
>> 
>> I found that freebsd is hacking all the ltmain.sh-es to get
>> roughly the same behavior that netbsd is already getting.
>> Any objections to putting something along these lines into
>> ltmain.in?  (Obviously changing /usr/bin/false to something
>> conditional on not being freebsd.)

> Looks good to me.  Please apply the same change to all live branches though!

I object! :-)

Hmm...  I'm a bit out of context here (I just read this earlier
because the e-mail, coming from postmaster, was filed in my e-mail
errors folder :-), but why would someone want to change libtool so as
to not install the .la files that are absolutely necessary for
inter-library dependencies and dlopening to work properly?

If they want to break libtool libraries in their distribution, they'd
better delete them the files, and perhaps even hack their own copy of
libtool, but not hack the master libtool such that it is broken for
all packages under the sun.  We should have a test in the testsuite
that demonstrates what breaks.

The test should go as follows:

build package foo that creates libfoodep.la and libfoo.la, libfoo.la
depending on libfoodep.la, and installs them

build package bar that links a program with the pre-installed
libfoo.la

after this change of freebsd, this test will fail to link bar using
-static, or if foo is configured with --disable-shared

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  address@hidden, redhat.com}
CS PhD student at IC-Unicamp        address@hidden, gnu.org}
Free Software Evangelist                Professional serial bug killer