- Previous message: Jeff Blaine: "Re: libtool not acting proper in plugins dir"
- Maybe in reply to: Jeff Blaine: "libtool not acting proper in plugins dir"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
|
|
|
From: Ken Hornstein (no email)
Date: Mon Dec 22 2008 - 13:42:10 EST
>> The libtool shipped by the Cyrus folks is broken. I always have to hack
>> ltmain.sh to get it to not strip out my -R flags. I reported this
>> eternities ago, but nobody else seemed to care, so I gave up and just
>> kept hacking it into each release myself.
>
>Thanks at least for the reply, Carson.
>
>I'm actually getting a little concerned about the state of
>Cyrus-* and the lack of flow on the lists.
Here is my $0.02 on this subject. Take from it what you will (note that
I mentioned some of this in the gssapi document which ships with SASL).
IMHO, libtool is not broken ... Cyrus-SASL's use of it is.
libtool is being used to produce a module. Fine. But what libtool
produces is something that is then supposed to be linked by libtool.
The idea here being that when you produce a module, you then use
libtool to link it against the .la file ... and at that point, libtool
will then add the appropriate -rpath flag.
But note that Cyrus-SASL doesn't do this. They create the shared
library using libtool, but then use the binary objects directly out of
the .libs directory. You're not really supposed to use it that way.
So now we have some classic finger pointing - libtool people say,
"You're using it wrong", where Cyrus people say, "libtool is broken".
Well, the Cyrus developers really don't say much about this problem,
I'm just guessing what they would say. But I don't think it's fair to
bash libtool here ... it's doing exactly what the libtool documentation
says it's supposed to do. Cyrus-SASL is just mis-using it.
--Ken
|
|
|