failure to link most programs on Leopard
Riccardo Mottola
riccardo.mottola at libero.it
Sun Nov 29 12:31:12 UTC 2020
Hi Ken!
On 2020-11-14 20:56:20 +0000 Ken Cunningham <ken.cunningham.webuse at gmail.com> 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.
Riccardo
More information about the macports-users
mailing list