Re: [Xquartz-dev] Notes on OSX 10.5.5
I don't like this solution because we're essentially adding in extra symlinks for no "real" reason except to support other libtool-archive files. I'm sorry, but the "broken" .la files being shipped with Xcode will be removed as was mentioned about 2 months ago. Xquartz.pkg will continue to ship the .la files to allow macports and fink users an alternative. You've seen how long it's taken to get substantial X11 updates into an OS update, so it seems like a battle not worth waging to try getting this kind of change into an OS update. On Sep 17, 2008, at 16:33, Martin Costabel wrote:
Jeremy Huddleston wrote: []
Again, do you really mean symlinks? I don't think there are any broken symlinks. If you mean the .la files, then those files are not IN the OS. They are in the SDK, so they can't be updated by the OS Update.
Plus, those symlinks are completely uselesss anyway. They are only used through the reference in the *.la files. Ok, please don't call them symlinks. They're not symlinks, and saying that makes me scared that we have a more serious problem with symlinks rather than libtool archives.
Let me give an example that comes up every couple of days, because it makes builds break:
On 10.5.4 and on 10.5.5, you have the following libXdamage*dylib files:
/usr/X11/lib/libXdamage.1.0.0.dylib -> libXdamage.1.dylib /usr/X11/lib/libXdamage.1.dylib /usr/X11/lib/libXdamage.dylib -> libXdamage.1.dylib
The second and third of these are perfectly meaningful, the second being the real file and also the install_name, the third one being used in linker flags -lXdamage.
The first symlink is not used by anything else than by glibtool through a reference in a libXdamage.la file. But the libXdamage.la file in xcode-3.1 and 3.1.1 does not reference libXdamage. 1.0.0.dylib, it references libXdamage.1.1.0.dylib. Hence the breakage.
How hard would it have been to include in the 10.5.5 softwareupdate an additional symlink /usr/X11/lib/libXdamage.1.1.0.dylib -> libXdamage.1.dylib ?
Plus the 3 or 4 others in the same class? Honestly?
-- Martin
_______________________________________________ Do not post admin requests to the list. They will be ignored. X11-users mailing list (X11-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/x11-users/jeremyhu%40freedesktop.org
This email sent to jeremyhu@freedesktop.org
Jeremy Huddleston wrote:
I don't like this solution because we're essentially adding in extra symlinks for no "real" reason except to support other libtool-archive files.
This is an extremely lame argument. *All* of these symlinks (the minor->major ones) are there for exactly the same "not real" reason, and *only* for that reason, namely to support Apple's very own *la files from the X11SDK.pkg. And if you ship two different sets of *la files in xcode-3.0 vs. xcode-3.1/3.1.1, then the basics of politeness would require that you include the two sets of symlinks that make this compatible, and do not continue for a whole year to ship incompatible pieces. Or make at least the *latest released* versions of both camps compatible with each other. Right now, the symlinks shipped with 10.5.2 to 10.5.5 are incompatible with *both* xcode-3.0 (libXrandr) and xcode-3.1/3.1.1 (libXdamage and some others). What you will do in the future is a different story. The thing is broken *now* and has been broken for a long time.
I'm sorry, but the "broken" .la files being shipped with Xcode will be removed as was mentioned about 2 months ago. Xquartz.pkg will continue to ship the .la files to allow macports and fink users an alternative. You've seen how long it's taken to get substantial X11 updates into an OS update, so it seems like a battle not worth waging to try getting this kind of change into an OS update.
OK, I think everybody has understood by now that there are internal wars going on at Apple between people doing the OS releases and people doing the dev tools releases. But please don't continue to fight this out on the back of your users. (By "you", I don't mean you, Jeremy, of course. You continue to be the champion of the users). -- Martin
On Sep 18, 2008, at 1:02 AM, Martin Costabel wrote:
OK, I think everybody has understood by now that there are internal wars going on at Apple between people doing the OS releases and people doing the dev tools releases. But please don't continue to fight this out on the back of your users.
There is no such thing. The two products are simply on different release schedules and media. Let's try to keep the rampant assumption-making to a minimum and focus on the technical issues themselves, OK? It will keep the Heat-to-Light ratio of this discussion within tolerable limits. - Jordan
On Sep 18, 2008, at 01:02, Martin Costabel wrote:
Jeremy Huddleston wrote:
I don't like this solution because we're essentially adding in extra symlinks for no "real" reason except to support other libtool-archive files.
This is an extremely lame argument. *All* of these symlinks (the minor->major ones) are there for exactly the same "not real" reason, and *only* for that reason, namely to support Apple's very own *la files from the X11SDK.pkg. And if you ship two different sets of *la files in xcode-3.0 vs. xcode-3.1/3.1.1, then the basics of politeness would require that you include the two sets of symlinks that make this compatible, and do not continue for a whole year to ship incompatible pieces.
Or make at least the *latest released* versions of both camps compatible with each other. Right now, the symlinks shipped with 10.5.2 to 10.5.5 are incompatible with *both* xcode-3.0 (libXrandr) and xcode-3.1/3.1.1 (libXdamage and some others).
As I've mentioned before, the release schedule for 3.1.1 was too far along by the time we were made aware of this issue. Furthemore, I've continued to assert that this is being addressed in Xcode 3.1.2 in the manner we discussed on this list about 2 months ago.
What you will do in the future is a different story. The thing is broken *now* and has been broken for a long time.
Well, TBH, you were the one who lashed out at the idea of simply punting the .la files in any manner. That is the most viable fix, and what we are heading towards. I've asserted that XQuartz,macosforge.org will continue to ship with .la files to give those of you with macports/fink references to the .la files an alternative option. Buyt the more this conversation continues, the more convinced I've become that I should nuke the .la files in xquartz.macosforge.org as well. The *fix* is then just 'rm /sw/lib/ *.la'... maybe fink and macports should consider not shipping these .la files. Heck, I manually nuke them on my Gentoo boxes because they annoy the crap out of me when switching compilers... there's even less reason to have them on OSX.
Jeremy Huddleston wrote:
On Sep 18, 2008, at 01:02, Martin Costabel wrote:
[]
Or make at least the *latest released* versions of both camps compatible with each other. Right now, the symlinks shipped with 10.5.2 to 10.5.5 are incompatible with *both* xcode-3.0 (libXrandr) and xcode-3.1/3.1.1 (libXdamage and some others).
As I've mentioned before, the release schedule for 3.1.1 was too far along by the time we were made aware of this issue. Furthemore, I've continued to assert that this is being addressed in Xcode 3.1.2 in the manner we discussed on this list about 2 months ago.
OK, so when 3.1 came out, 3.1.1 was already too advanced and, of course, 10.5.3 and 10.5.4 and 10.5.5 were not to be bothered by compatibility issues with an SDK.pkg. I see.
What you will do in the future is a different story. The thing is broken *now* and has been broken for a long time.
Well, TBH, you were the one who lashed out at the idea of simply punting the .la files in any manner.
I was not "lashing out". I was simply warning and asking to think about what will happen if you do it. This is not a judgment, it is a statement of fact. I showed a real-life example, too, that came up immediately when you shipped one of the xquartz updates without the *.la files. The fact is that once X11 dumps its *.la files, one will have to rebuild every package that has been built against the old X11 with *.la files, and all of them from scratch, because if only one dependency has an *.la file that was built against the old X11, the whole rebuild procedure will crash. What I *was* "lashing out" against is the continuing de facto refusal to apply trivial and inoffensive bug fixes and the wasted opportunities for doing so in a timely manner. -- Martin
On Sep 19, 2008, at 02:59, Martin Costabel wrote:
Jeremy Huddleston wrote:
On Sep 18, 2008, at 01:02, Martin Costabel wrote:
[]
Or make at least the *latest released* versions of both camps compatible with each other. Right now, the symlinks shipped with 10.5.2 to 10.5.5 are incompatible with *both* xcode-3.0 (libXrandr) and xcode-3.1/3.1.1 (libXdamage and some others).
As I've mentioned before, the release schedule for 3.1.1 was too far along by the time we were made aware of this issue. Furthemore, I've continued to assert that this is being addressed in Xcode 3.1.2 in the manner we discussed on this list about 2 months ago.
OK, so when 3.1 came out, 3.1.1 was already too advanced
More correctly, by the time we came up with a solution, it was too advanced. Remember, you were the one who was vehemently opposed to us no-longer shipping the .la files, so I spent some time trying to find an alternative. After coming to the conclusion that there is no alternative, it was too late for 3.1.1
and, of course, 10.5.3 and 10.5.4 and 10.5.5 were not to be bothered by compatibility issues with an SDK.pkg. I see.
Right, there's nothing wrong that an OS update can fix. The broken files are in X11SDK which ships independent of the OS.
The fact is that once X11 dumps its *.la files, one will have to rebuild every package that has been built against the old X11 with *.la files, and all of them from scratch, because if only one dependency has an *.la file that was built against the old X11, the whole rebuild procedure will crash.
or you could just do 'rm /sw/lib/*.la' and be done with it.
What I *was* "lashing out" against is the continuing de facto refusal to apply trivial and inoffensive bug fixes and the wasted opportunities for doing so in a timely manner.
Well, that certainly is an opinion. However, the discussion here certainly supports arguments to the contrary regarding the triviality of said changes, and said changes are being integrated into the first available update that can take them.
Jeremy Huddleston wrote: []
Right, there's nothing wrong that an OS update can fix. The broken files are in X11SDK which ships independent of the OS.
The weird symlinks are shipped with the OS, though. Remember that the first breakage of the kind we have been discussing here (keyword libXrandr) hit those people who got a machine that came with Mac OS X 10.5.2 preinstalled. The X11SDK had not changed, only the OS. But this discussion has long since crossed the line to the absurd, and I am stopping now. -- Martin
participants (3)
-
Jeremy Huddleston
-
Jordan K. Hubbard
-
Martin Costabel