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.
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.
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...
Peter
-------------------------------------------------------
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
