Jeremy Huddleston Sequoia
jeremyhu at apple.com
Sat Oct 3 01:56:27 PDT 2015
> On Oct 2, 2015, at 08:01, Clemens Lang <cal at macports.org> wrote:
> ----- On 2 Oct, 2015, at 15:33, Bachsau web at bachsau.name wrote:
>> Maybe. Seems like I'm just not getting what is technically causing these
>> problems. When libraries change, and it breaks a particular application, why
>> can't I recompile just that? And why would the build of a newly installed port
>> fail, just because there are other ports installed that were compiled against
>> older system libraries?
> There are changes that can be done by Apple with OS upgrades that will render
> your currently installed libraries useless. Examples for changes that are of
> this nature are:
> - Apple changing CPU architecture
> - Apple changing the ABI of a library you link against (e.g. when moving
> to C++11 using libc++)
We haven't changed the ABI.
We've added a new C++ runtime (libc++), but still continue to ship the older libstdc++ runtime for binary compatibility.
> - Apple no longer shipping a certain library
This usually happens very rarely, and I can't even think of an example where this has happened other than X11, for which I wrote a transitionary system to capture that usage and direct users to XQuartz. Usually when it happens is for new platforms or architectures (eg: some things were dropped in the transition to 64bit or in the transition to Intel).
> This can leave you with binaries or libraries that no longer work. If a build
> system now picks up one of these broken binaries or libraries (that does happen,
> especially with missing architectures from universal binaries or missing
> libraries), your binary will crash during the build or the build will fail to
> link against a library. This will make your rebuild fail.
> Of course, anything that is needed for a build should be in the list of
> dependencies of a port, and should thus get rebuilt before the port in question,
> avoiding the problem. Reality is different, however: build systems like cmake
> and autotools look for optional dependencies all over the place and try to use
> them if found, even if they are not in the list of dependencies, which leads to
> these problems.
> In theory, we have a solution for this problem: trace mode hides anything from
> a port's build system that doesn't come with the system and is not in the list
> of dependencies, so *in theory* we could replace migration with
> sudo port -t upgrade outdated,
> and in fact, I successfully tested this during the last OS upgrade. With the
> upgrade to El Capitan, though, Apple's System Integrity Protection actually
> breaks trace mode (Yay!), so this not an option, leading us to recommend the
> migration procedure.
How does SIP break it? Do you have a radar or MP ticket? I'm curious to followup on that.
> So yes, careful thought has been given to the problem at hand, I agree it's
> annoying, but given the way Apple handles things, there are currently no other
> Clemens Lang
> macports-users mailing list
> macports-users at lists.macosforge.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4109 bytes
Desc: not available
More information about the macports-users