gcc10-bootstrap @10.3.0_5+universal: ld: file has external relocation entries in non-writable section (Tiger)

[Cebtenzzre]

Related to #67348, it seems that (when PATH is set correctly) gcc10-bootstrap is unable to link executables on OS X Tiger. I'm omitting the assembler warnings for brevity. This is foo.c:

#include <stdio.h>

int main(void) {
    puts("Hello, world!");
    return 0;
}

gcc10-bootstrap cannot link it:

$ export PATH=/bin:/sbin:/usr/bin:/usr/sbin
$ gcc10=/opt/local/libexec/gcc10-bootstrap/bin/gcc
$ $gcc10 foo.c -o foo
/usr/bin/ld: /var/tmp//ccrgah6s.o has external relocation entries in non-writable section (__TEXT,__text) for symbols:
_puts
collect2: error: ld returned 1 exit status

But it can link the assembly generated by gcc-apple-4.2, and vice-versa:

$ gcc4=/opt/local/bin/gcc-apple-4.2
$ $gcc4 -S foo.c -o foo-gcc4.S
$ $gcc10 -S foo.c -o foo-gcc10.S
$ $gcc4 foo-gcc10.S -o foo  # ok
$ $gcc10 foo-gcc4.S -o foo  # ok

It looks like the difference is that gcc 10 emits a direct call to _puts, whereas gcc-apple-4.2 emits a stub in a special section outside of .text. And gcc-apple-4.2 calls MacPorts ld64, while gcc10-boostrap calls the system's classic ld.

Why not configure gcc10-bootstrap to use the system ld64 on Tiger?

$ $gcc10 -c foo.c -o foo.o
$ /usr/bin/ld64 -lcrt1.o foo.o -lSystem -o foo  # ok

[Cebtenzzre]

assembly output of gcc-apple-4.2

[Cebtenzzre]

assembly output of gcc10-bootstrap

[catap (Kirill A. Korinsky)]

Well.. the only things which is puzzling me is how you might build it. It builds 3 stages compilers, and if it can't build such trivial things => you won't be able to get this port installed.

[catap (Kirill A. Korinsky)]

BTW may I ask you to test with -O0, -O1, -O2 and -O3?

[catap (Kirill A. Korinsky)]

and we're talking about ppc or i386?

[catap (Kirill A. Korinsky)]

Anyway, you may test it with ld64 here: ​https://github.com/catap/macports-ports/tree/gcc10-bootstrap-tiger

[Cebtenzzre]

This is on Tiger i386. I get the same error for all optimization levels. I'm building the patched version now.

[Cebtenzzre]

The build failed:

:info:build ld64-62.1 failed: unknown option: -reexport_library
:info:build collect2: error: ld returned 1 exit status
:info:build ld64-62.1 failed: unknown option: -reexport_library
:info:build collect2: error: ld returned 1 exit status

/usr/bin/ld doesn't recognize that option either. MacPorts /opt/local/bin/ld does.

[Cebtenzzre]

Main log from failed gcc10-bootstrap build using --with-ld=/usr/bin/ld64

[catap (Kirill A. Korinsky)]

Quite expected. Anyway, I still don’t understand how you able to build it, if it can’t use picked ld

[Cebtenzzre]

I'd assume that at that point in the build it's normally using the MacPorts linker, since it depends on apple-gcc42 and this line is in build-i386/config.log:

LD='/opt/local/libexec/apple-gcc42/gcc/i686-apple-darwin8/4.2.1/ld'

And that ld is just a symlink to /opt/local/bin/ld.

[catap (Kirill A. Korinsky)]

Replying to Cebtenzzre:

I'd assume that at that point in the build it's normally using the MacPorts linker, since it depends on apple-gcc42 and this line is in build-i386/config.log:

LD='/opt/local/libexec/apple-gcc42/gcc/i686-apple-darwin8/4.2.1/ld'

And that ld is just a symlink to /opt/local/bin/ld.

Nope, it makes so-called 3-stage build by calling bootstrap-lean as it described here: ​https://gcc.gnu.org/install/build.html

My point: I thought stage2 should use the complier which is installed and available for users. I expect that it may not work with mixing cctols from MacPorts, but in general it should work. Otherwise I don't understand how it can be bootstraped.

[kencu (Ken)]

I suspect it does use the MacPorts ld64 during the build.

gcc as of about gcc10 dropped support for the ancient /usr/bin/ld linker. Even /usr/bin/ld64 is not well supported, as it is so old. I think it only works reliably with ld64 >= about 85 now.

Nobody has done much kicking the tires on Tiger for gcc10-bootstrap to date -- I certainly haven't, and it would usually have been me who does this, but too busy of late. This all needs some straightening out, as the cctools issue erroring out with -mmacosx-version-min} prevents anything building if MacPorts cctools is installed.

[kencu (Ken)]

for fun and testing, gcc has a -B option.

you can symlink the exact linker and assembler you want to use into a folder (as "as" and "ld"), and use -B to spec it for use.

[catap (Kirill A. Korinsky)]

Ken, when I don't understand why gcc10-bootstrap picks some ld on build which works, and doesn't pick it after. Something quite wrong here.

[kencu (Ken)]

Yes, that is happening.

Tiger is very messy that way. It has always been a major PITA to support newer gccs on Tiger, which is why I have left it on gcc7 until now.

By the way, upstream gcc has stopped all Tiger testing, although will still respond to tickets about it, for now.

Tiger has no "@rpath" support, and lots of other headaches with the SDK.

From time to time I rip through a bunch of fixes, and Evan drops by every once in a while for giggles, but otherwise it's struggling.

Leopard is an order of magnitude more compatible with newer software and build systems, but will mean dropping all the "G3" era PPC machines. Pretty much all Intel machines, even the oldest ones, can run Leopard and Snow Leopard I believe. I upgraded the CPU in my oldest Intel machine to allow it to run SnowLeopard -- $12 for the CPU, 1 hour to install it.

[barracuda156]

Replying to kencu:

I suspect it does use the MacPorts ld64 during the build.

gcc as of about gcc10 dropped support for the ancient /usr/bin/ld linker. Even /usr/bin/ld64 is not well supported, as it is so old. I think it only works reliably with ld64 >= about 85 now.

Yeah, I think Iain mentioned that Tiger will require a newer tools to begin with, in order to build a modern GCC. 10.5 should still be good.

[catap (Kirill A. Korinsky)]

Replying to barracuda156:

Yeah, I think Iain mentioned that Tiger will require a newer tools to begin with, in order to build a modern GCC. 10.5 should still be good.

Here issue is much more interesting: gcc10-bootsrap is using multiple stage builds and in fact produces something that can be used to build itself.

But it seems that it can't be used outside of its build.

Why? I have no idea.

Can I fix it? Yes, but I need an access to such machine. Without it I really doubt that.

[kencu (Ken)]

a Tiger VM runs well on VirtualBox with some minor customizations.