failure to link most programs on Leopard

Riccardo Mottola riccardo.mottola at
Sun Nov 29 12:31:12 UTC 2020

Hi Ken!

On 2020-11-14 20:56:20 +0000 Ken Cunningham <ken.cunningham.webuse at> wrote:

> One last thing…
> this noise:
> <stdin>:485:11: warning: section "__textcoal_nt" is deprecated
>          .section __TEXT,__textcoal_nt,coalesced,pure_instructions
>                   ^      ~~~~~~~~~~~~~
> <stdin>:485:11: note: change section name to "__text"
>          .section __TEXT,__textcoal_nt,coalesced,pure_instructions
>                   ^      ~~~~~~~~~~~~~
> is coming because cctools now sends assembly to clang if clang >= 5.0 is 
> installed. It’s harmless.

Good to know it is harmless. As a software developer, when I have a fatal error, I go up to see if there were any warnings before since they could (or not) be related.

> I don’t think that clang being the assembler is bringing out the 
> compact_unwind or text_reloc errors, but I’d have to experiment with that 
> to be certain. To do that, deactivate clangs >= 5.0 before your gcc48 build, 
> for example.

That's what I ended doing. What is annoying is that gcc6 has exactly the same issue though!

> Back when gcc48 was being implemented, and even now when Iain tests the 
> builds of gcc on older systems, he does it “neat” on an unmodified i386 
> Leopard system, he does not do it in MacPorts.
> So our changes, like a newer linker, or sending assembly to clang instead of 
> “gas” , can have unexpected consequences sometimes.
> Iain always says that he’s prepared to fix gcc for older systems 
> (apparently he has gcc10 building on 10.4 PPC and 10.4 Intel and up), but 
> he’s not going to work inside MacPorts to undo our shenanigans.

eheh, wow, even gcc 10 sounds super cool, that would give us access at least to "minor" Objective-C upgrades that gcc got (although the full new stuff is unfortunately still only in clang).

> I have some personal patches that force our builds of gcc to use the older 
> “gas” assembler that fixes up the build gcc8+ on older systems, but as 
> things are working quite well at present. I haven’t started forcing those 
> changes into MacPorts as yet.

given the gcc problems, libxml2 problems, etc... a more convenient way to build a port with clang or gas is needed, the trick og "cctools uses clang always" is perhaps too invasive.

> And - you know that i have built most of this software and put it on the 
> ‘older systems’ binary site I sent you the link to, so if you get 
> frustrated, you can download the prebuilt binaries from there.

Right now I am still trying, since anyway I have 10.5-64bit to update later.


More information about the macports-users mailing list