• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Notes on OSX 10.5.5
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Notes on OSX 10.5.5


  • Subject: Re: Notes on OSX 10.5.5
  • From: Peter O'Gorman <email@hidden>
  • Date: Wed, 17 Sep 2008 16:38:25 -0500

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.

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

Should apple ever adopt this newer version of libtool they will be able
to remove the hack. (note 2.2.6 is still GPL2/LGPL2 + exceptions...:-p).

Peter
--
Peter O'Gorman
http://pogma.com
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list      (email@hidden)

This email sent to email@hidden

  • Follow-Ups:
    • Re: Notes on OSX 10.5.5
      • From: Jeremy Huddleston <email@hidden>
References: 
 >Notes on OSX 10.5.5 (From: Jeremy Huddleston <email@hidden>)
 >Re: Notes on OSX 10.5.5 (From: Martin Costabel <email@hidden>)
 >Re: Notes on OSX 10.5.5 (From: "Jordan K. Hubbard" <email@hidden>)
 >Re: Notes on OSX 10.5.5 (From: "Benjamin Reed" <email@hidden>)
 >Re: Notes on OSX 10.5.5 (From: Jeremy Huddleston <email@hidden>)
 >Re: Notes on OSX 10.5.5 (From: "Benjamin Reed" <email@hidden>)
 >Re: Notes on OSX 10.5.5 (From: Martin Costabel <email@hidden>)
 >Re: Notes on OSX 10.5.5 (From: Jeremy Huddleston <email@hidden>)

  • Prev by Date: Re: 10.5.5 broke X11
  • Next by Date: Re: Notes on OSX 10.5.5
  • Previous by thread: Re: Notes on OSX 10.5.5
  • Next by thread: Re: Notes on OSX 10.5.5
  • Index(es):
    • Date
    • Thread