At 20:19 Uhr +0900 16.01.2003, Peter O'Gorman wrote:
On Thursday, January 16, 2003, at 01:47  AM, Max Horn wrote:

So what do you think? Is this still your stance:

At 23:28 Uhr +0900 15.01.2003, Peter O'Gorman wrote:
You are, of course correct with the compatibility versions, and I think it is worth getting this upstream even if it breaks binary compatibility on some of our installed packages.

Okay, reasons for sending the patch upstream:
1) This is the way that libtool is documented to behave on all platforms, that it currently doesn't make binary compatible libraries due to the -compatible_version being incorrect is a bug, and a bad one.
2) If we don't report this bug to libtool, it seems likely that at some point in the future, somebody else will find it and propose a fix anyway.

Reason against:
It will break binary compatibility for x number of packages. This is okay with me, as long as x is reasonably small.
Yes that was my thought, too. Well, not for reporting it, but as to whether to suggest fixing it or not.


So, I just did a quick ls of my /sw/lib, looking for libfoo.a.b.c.dylib with a non-zero b.

Even if I assume that only half of those were built with libtool, x is unreasonably large, so your patch should not be sent to libtool.
Hrm, bad :-/


I wonder if they would accept a conditional in that code? If an env_var was set (LIBTOOL_PROPER_DARWIN_VERSION ?) :) then it could evaluate as your patch, otherwise, it would stay with the old behavior...

Perhaps the bug should be reported, asking them to never fix it?

I really don't know, it would be nice if some others would pipe up...
I believe that we definitly should bring it up on the libtool mailing list, and discuss it a bit with them, too. Maybe they have a good idea on how to fix this, for example. Though right now I have no single clue how that could be one. Damn, at moments like this I wish I had a time machine to warp back and correct the mistake before it was ever made <sigh>

On the long run, though, this bug is going to cause quite some trouble and irritation, though. It would be great if we could determine a reasonable way to fix it step by step.


Max
--
-----------------------------------------------
Max Horn
Software Developer


-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to