Darwin Version

[Jeremy Huddleston Sequoia]

> On Oct 2, 2015, at 08:01, Clemens Lang <cal at macports.org> wrote:
> 
> Hi,
> 
> ----- 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
> options.
> 
> -- 
> Clemens Lang
> _______________________________________________
> macports-users mailing list
> macports-users at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4109 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20151003/1b77b2f5/attachment.p7s>