Re: Notes on OSX 10.5.5
Re: Notes on OSX 10.5.5
- Subject: Re: Notes on OSX 10.5.5
- From: Jeremy Huddleston <email@hidden>
- Date: Wed, 17 Sep 2008 12:19:33 -0700
On Sep 17, 2008, at 10:53, Martin Costabel wrote:
Benjamin Reed wrote:
On Tue, Sep 16, 2008 at 2:24 PM, Jeremy Huddleston <email@hidden
> wrote:
I assume you actually mean the text references in the .la files
and NOT
sumlinks themselves (ala 'ln -s'). If somehow symlinks are wrong,
then
there is a bigger problem than I realized.
Yes, sorry, I meant the .la files.
Both are to blame for the mismatch. Since the arrival of Leopard,
there have been several updates for the OS and for the xcode tools
that touched either the symlinks or the *.la files. None of these
updates on either side cared about compatibility with the other side.
The latest examples (and this is what made me angry) were the OSX
10.5.5 and the xcode 3.1.1 updates. Both were made after the
situation with the incompatible library version names was clearly
explained several times here and elsewhere, and was heard by Apple
employees.
It was too late for us to push any changes into 3.1.1 by the time we
figured out that removing the .las was the best option. 3.1.1 has no
change to X11SDK over 3.1.
Yet nothing was done about the situation, although the effort would
have been completely negligible.
What *effort* do you think is required? So far, no plan to tackle
this has actually been proposed.
In fact, removing the files that go into the DevSDK.pkg from the OSX
update must have taken much more time than would have been needed
for fixing the 4 or 5 wrong symlinks.
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.
I am talking about the symlinks in the Apple special form minor-
>major, which goes in the opposite direction of the usual major-
>minor symlinks that do make sense.
Oh, well as far as I know, the symlinks aren't broken (ie, the target
doesn't exist or is incorrect), they're just not in the direction you
expect. I agree that this is not great, but blame glibtool.
Hopefully this will get fixed (and it is a pet peeve of mine), but
it's not exactly a big concern in the grand scheme of things.
Sorry. All I can really say is that this has been an educating
experience
for all of us and will allow us to avoid these mistakes the next
time around
(meaning 10.6). If you can offer a suggestion as to how we can
actually
address this before then, I would most welcome it.
I still don't get it. Why wait for 10.6?
Because there's no way to fix this in Leopard that I can see. Well,
technically "Leopard" doesn't have .la files. XCode 3.0, 3.1, and
3.1.1 have the .la files. The solution we're exploring is to not ship
the .la files with XCode 3.1.2, so new users won't have this problem.
"Old" users should continue to use the xquartz.macosforge.org package
as it will have consistent .la files.
The next minor OS or xcode update would be the right moment.
And what do you propose? If they update to 10.5.6 and we install .la
files, then when they install XCode 3.1.1, the "bad" .la files will
overwrite the ones from the OS update. If we include it in XCode
3.1.2, then we have the *EXACT* same problem we do now. The .la files
are being updated independently of the binaries. They can install
XCode 3.1.2 on OSX 10.5.2 if they want or 10.5.10 (if we ever get that
high). If the binaries change, the .la files need to change with
them, and having them in XCode is clearly wrong.
The users don't ask Apple to invent some grand new scheme or to
solve big philosophical problems, only to release software where one
part is not incompatible with another one, and fix bugs that are
trivial to fix.
Again, this is not trivial to fix. If it were, it would be by now,
but not a single viable solution has been proposed that can actually
leave existing systems with fink/macports .la files referencing
X11 .la files in a working state. The only solution we have is that
*new* systems will be working.
Removing or editing to use major-library-version-number would fix it,
but in the end, if they're not "supported" it is proper that they be
removed.
You are aware of the fact that if the *.la files disappear in a new
version of X11, Fink (and I guess macports, too) has no simple
upgrade path, because *all* packages that link to X11 will need to
be rebuilt from scratch at the same time.
Yes, and *THIS* is exactly what makes this problem non-trivial
(contrary to your insistence that this is a trivial problem). It
looks like our solution will be:
XCode no longer ships .la files
OSX continues to not ship .la files
xquartz.macosforge.org ships self-consistent .la files
This gives macports/fink users a way to have a consistent system.
Of course, my advice to you is to just nuke all the .la files from
your fink/macports dirs.
This a change almost of the size of the C++ ABI changes we had in
the past.
--
Martin
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden