Re: rebuild a package without an update

[Ken Cunningham]

> It is a delicate siuation, with Ken we were supposing to make a static 
> version or link statically, so that an upgrade does not "turn down" 
> all MacPort compilers.
> 

Ideally the compiler should have as few fragile deps as possible. Static 
linking in the compiler deps might help us get to a compiler that wouldn’t be 
broken by it’s own dep updates.

You might think that it’s mantra to only use dylibs, but to be honest, the 
primary theoretical benefit of dylibs (updates in the library pass on to all 
users magically) seems to turn out to be fairly imaginary in the end, because 
as we have seen every significant dylib update requires everything that uses it 
to be revbumped and rebuilt anyway. There is the space/mem saving of dylibs — 
but static linking in the deps for a compiler would not be too onerous, as the 
deps are tiny indeed.

libxml2 brings in a whole mess of stuff, including the nefarious ICU 
extravaganza, more complicated now because ICU requires a fairly recent 
compiler to bulid. There is no good reason for libxml2 to be a dep for 
clang/llvm as the system libxml2 does just fine.

cmake brings in an amazing collection of deps, so cmake-bootstrap was invented, 
which has no external deps at all. cmake-bootstrap is new enough to build 
either llvm/clang-9.0 or possibly 10, I can’t remember just now if it could 
build 10.

So that leaves libffi, libedit, ncurses, xar, zlib, and libcxx, which is a 
nice, small list of things that mostly build with the system compilers,, I 
believe, and — I think — almost all of them (not libcxx) can be statically 
linked in….

So it’s improvable, probably.

Ken

Re: rebuild a package without an update

[Riccardo Mottola via macports-users]

Hi,


On 2020-11-08 08:18:22 +0100 Ryan Schmidt  
wrote:





On Nov 7, 2020, at 12:46, Riccardo Mottola wrote:

I need to rebuild a package which is not working due to a dependency 
upgrde. revdep "catches" it but revdep fails to build it because it 
uses 
the wrong compiler and I need to force it (also because the compiler 
itself 
is broken because it is broken because the library is broken)


I usually in these cases just run "port upgrade  
configure.compiler=xxx" but in this case there is nothing to 
upgrade, I 
need to rebuild in place.



How can I do?


This situation should not arise. But: you can force a rebuild of a 
port using:


Indeed, but we have an issue that ICU upgrades break libxml2 and that 
one breaks *all* clang compilers.

Since gcc now links using clang also al macports clangs are broken!

So I have to force the "gcc-4.2" of xcode... that one works (and, 
luckily, libxml2 still compiles with it)





sudo port -ns upgrade --force theportname

and add whatever extra variables you want to set after that.



Thanks! it worked for the purpose, but did resurrect my system only 
partially, very strange, but issues that are off-topic for this mail. 
I'll pinpoint exactly the remaining issues and report them separately. 
Original issue "solved".


It is a delicate siuation, with Ken we were supposing to make a static 
version or link statically, so that an upgrade does not "turn down" 
all MacPort compilers.


Riccardo

macOS version number reporting on Big Sur

[Richard L. Hamilton]

This looks interesting, esp. for those who need to do tests either in scripts 
or programs. Those who don't might still want to be aware that there might be 
RARE cases of something thinking it's on 10.0, and failing since that's way too 
old.

https://eclecticlight.co/2020/08/13/macos-version-numbering-isnt-so-simple/ 



I don't think I'm subscribed to macports-dev; so maybe someone that is might 
want to repost it there.

Re: Any reason not to update to Xcode 12.2 on Catalina?

[Ryan Schmidt]

On Nov 12, 2020, at 23:08, Richard L. Hamilton wrote:

> One or two times past, an Xcode version around the time of a new OS release 
> has been a problem on the older OS.
> 
> I don't see anything likely to be that way with Xcode 12.2 (and MacPorts) on 
> Catalina, but I'm looking for alternative opinions; reverting is a nuisance.
> 
> I'm in no hurry for Big Sur at this point; maybe I'll wait for the .1 or .2 
> of it, unless a compelling reason to update emerges.
> 

Xcode 12.0 contains only the macOS 10.15 SDK. As such, it is suitable for using 
with macOS 10.15. I believe Xcode 12.1 was the same.

Xcode 12.2 contains only the macOS 11 SDK. As such, it has the potential to 
cause problems when building some software on macOS 10.15 and you would be 
safer to stick with Xcode 12.1. For software that does not require Xcode to 
build, you can mitigate the problem by installing the Command Line Tools for 
Xcode 12.2, because it contains both the macOS 10.15 SDK and the macOS 11 SDK. 
For software that does require Xcode to build, with Xcode 12.2 on macOS 10.15, 
you would be at the mercy of the developers of that software having written it 
correctly to anticipate differences between the SDK version and the OS version, 
which not all developers do correctly.

(Xcode 12.0 betas contained the macOS 11 SDK, but it was changed back to the 
macOS 10.15 SDK when Xcode 12.0 final was released, presumably because macOS 11 
was not released yet.)

On macOS 10.15, you can avoid even more problems by limiting yourself to Xcode 
11.7 and the Xcode 11.5 version of the command line tools. Upgrading to Xcode 
12 or the Xcode 12 version of the command line tools will cause some ports to 
fail to build with implicit declaration of function errors or other errors that 
are a consequence of earlier implicit declaration of function errors. This 
problem is pervasive and although we have fixed many ports already, there are 
many many more that have yet to be identified and fixed.