At 20:19 Uhr +0900 16.01.2003, Peter O'Gorman wrote:
Yes that was my thought, too. Well, not for reporting it, but as to whether to suggest fixing it or not.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.
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...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>
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...
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