> On Oct 2, 2015, at 08:01, Clemens Lang <c...@macports.org> wrote: > > Hi, > > ----- On 2 Oct, 2015, at 15:33, Bachsau w...@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@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-users
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
