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 15:34:05 -0700
On Sep 17, 2008, at 14:38, Peter O'Gorman wrote:
The best solution, in my opinion, is to have Xcode ship SDKs for
/Developer/SDKs, but not headers/manpages/static archives etc in /.
The
Xcode SDKs are static, they should not change for minor OS versions or
Xcode releases, so shipping them with Xcode is not a problem.
The headers, libraries, manpages in / should be included in the
package
that they belong to. This means that when SU puts a new openssl, for
example, on my machine to fix a security issue, the headers will match
the new library version.
Hmm... I like this... so the "live" system doesn't necessarily match
the SDK for that target (ie 10.5.6's live headers might not be the
same as the 10.5 SDK). Of course things built against the live system
wouldn't necessarily be ABI compatible with older versions of that
release series (ie something built against 10.5.6 live might not
distribute to 10.5.2 systems)... but things built against the 10.5 SDK
would be guaranteed to be ABI compatible.
So then we get into the question of whether people building against
the live 10.5.6 system would expect that to distribute to a 10.5.2
system, and I think the answer is yes, and I think that is why we have
the current scenario.
As for keeping/removing .la files, I remain of the opinion that they
are
more trouble than they are worth in /usr/lib. Fink and MacPorts will
have a one-time issue to workaround and can then assume that future
software updates will not break things.
On to the incorrect symlinks to dylibs caused by glibtool, long ago
there was a problem, I believe that redo_prebinding, or some similar
tool, would write its output to the install_name of the input file,
not
following the symlink, so when run as part of Apple's build system,
you
would end up with something like:
libfoo.dylib -> libfoo.1.dylib
libfoo.1.dylib (the real file)
libfoo.1.0.0.dylib (another copy of the real file)
In order to avoid that issue, Apple patched their copy of GNU
libtool to
make it like this:
libfoo.dylib -> libfoo.1.dylib
libfoo.1.dylib (real file)
libfoo.1.0.0.dylib -> libfoo.1.dylib
The reason to keep the extra symlink is that some people may have
scripts or build systems that expect two symlinks and one file. In
libtool-2.2.x (current FSF release is 2.2.6) there is only:
libfoo.dylib -> libfoo.1.dylib
libfoo.1.dylib (real file).
Do you happen to know why this was the solution over:
libfoo.1.0.0.dylib (real file)
libfoo-1.dylib -> libfoo.1.0.0.dylib
libfoo.dylib -> libfoo-1.0.0.dylib
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