This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin 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: [avail for test] libtool-devel-20030121-1


Charles Wilson wrote:
> Max Bowsher wrote:
>> This seems like a good time to mention that I ran into this problem
>> building gtk+ (or glib), I forget. It wanted -luuid, but -luuid is a
>> static archive, which libtool doesn't currently like. I had to hack
>> libtool as Ralf mentions above to get it to work.
>
> ARGH.  That defeats the whole purpose of the *POLICY* change in
>   libtool. I do NOT want to be in the business of supporting a forked
> version of
> libtool that disagrees with mainline on a *fundamental* policy issue.
>
> ** you can't build shared libraries that depend on static libraries,
> when using a "modern" libtool (e.g. HEAD CVS, pre-1.5) **

Nor would I expect you to. However, I might try to change the mainline's
mind on this at some point, once I've studied the issue more thoughroughly.

> If you have a problem with the policy, the place to fix it is NOT to
> hack up libtool.  Instead, get shared versions of your dependencies.

Even when making a library shared is 10 parts overhead for 1 part
usefulness? It's not libtool's place to force platforms to change. However,
neither is it the libtool mainline maintainer's place to go out and write
code to deal with every little foible of every platform.

I will research the policy descision in the libtool ML archives, and see if
I can come up with a good solution.



Max.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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