error using gcc 48 on PPC

[Ken Cunningham]

> On Apr 19, 2018, at 11:17 PM, Riccardo via macports-users <macports-users at lists.macports.org> wrote:
> 
> Hi,
> 
> When using gcc48 from macports on 10.5 Leopart PPC (trying to reporduce exact TenFourFox build environment needed) it will fail this way during configure:
> 
> Ever seen something like this? I  *think* gcc was installed from binary, I don't remember if you provide them, I just left ports running overnight to get all the stuff.
> 
> Riccardo
> 
> 
> checking for -allow_heap_execute option to ld... no
> checking whether the C++ compiler (/opt/local/bin/g++-mp-4.8 -flax-vector-conversions -fpermissive -O3 -mcpu=7450 -mtune=7450 -falign-loops=16 -falign-functions=16 -falign-labels=16 -falign-jumps=16 -read_only_relocs suppress -mdynamic-no-pic  -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-exceptions -fno-strict-aliasing -fno-rtti ) actually is a C++ compiler... no
> configure: error: /opt/local/bin/g++-mp-4.8 -flax-vector-conversions -fpermissive -O3 -mcpu=7450 -mtune=7450 -falign-loops=16 -falign-functions=16 -falign-labels=16 -falign-jumps=16 -read_only_relocs suppress -mdynamic-no-pic  -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-exceptions -fno-strict-aliasing -fno-rtti  failed to compile and link a simple C++ source.
> ------ config.log ------
> return 0;
> ; return 0; }
> configure:9529: checking for -allow_heap_execute option to ld
> configure:9540: /opt/local/bin/gcc-mp-4.8 -flax-vector-conversions -O3 -mcpu=7450 -mtune=7450 -falign-loops=16 -falign-functions=16 -falign-labels=16 -falign-jumps=16 -read_only_relocs suppress -mdynamic-no-pic -o conftest  -isysroot /Developer/SDKs/MacOSX10.4u.sdk -std=gnu99 -fno-strict-aliasing -fno-exceptions   -Wl,-allow_heap_execute conftest.c  1>&5
> ld: -allow_heap_execute option can only be used when linking for i386
> collect2: error: ld returned 1 exit status
> configure: failed program was:
> #line 9533 "configure"
> #include "confdefs.h"
> 
> int main() {
> return 0;
> ; return 0; }
> configure:10503: checking whether the C++ compiler (/opt/local/bin/g++-mp-4.8 -flax-vector-conversions -fpermissive -O3 -mcpu=7450 -mtune=7450 -falign-loops=16 -falign-functions=16 -falign-labels=16 -falign-jumps=16 -read_only_relocs suppress -mdynamic-no-pic  -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-exceptions -fno-strict-aliasing -fno-rtti ) actually is a C++ compiler
> configure:10522: /opt/local/bin/g++-mp-4.8 -flax-vector-conversions -fpermissive -O3 -mcpu=7450 -mtune=7450 -falign-loops=16 -falign-functions=16 -falign-labels=16 -falign-jumps=16 -read_only_relocs suppress -mdynamic-no-pic -o conftest  -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-exceptions -fno-strict-aliasing -fno-rtti   conftest.C  1>&5
> ld: in /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/crt1.o, in section __TEXT,__text reloc 1: sectionForNum(4) section number not for any section for architecture ppc7450
> collect2: error: ld returned 1 exit status
> configure: failed program was:
> #line 10515 "configure"
> #include "confdefs.h"
> #include <new>
> int main() {
> int *foo = new int;
> ; return 0; }
> configure: error: /opt/local/bin/g++-mp-4.8 -flax-vector-conversions -fpermissive -O3 -mcpu=7450 -mtune=7450 -falign-loops=16 -falign-functions=16 -falign-labels=16 -falign-jumps=16 -read_only_relocs suppress -mdynamic-no-pic  -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-exceptions -fno-strict-aliasing -fno-rtti  failed to compile and link a simple C++ source.
> *** Fix above errors and then restart with\
>               "gmake -f client.mk build"
> gmake[2]: *** [/Users/multix/Documents/code/tenfourfox/client.mk:361: configure] Error 1
> gmake[2]: Leaving directory '/Users/multix/Documents/code/tenfourfox'
> 
> 


I tried for a couple of hours to see a way around this, but so far, I’ve had no success. It may not be possible with recent gcc versions, or perhaps I haven’t yet figured out the right trick.

I tried all the combinations of setting the -mmacosx version, deployment target, and linker flags I could think of, but none worked. 
I tried linking crt1.o to 10.5’s, but that failed. 
I tried using ld-97, or the system’s ld, or ld-127, and although it’s not terribly easy to tell if it was using the linker I wanted to use, that didn’t work either. 
I tried building against the 10.5 SDK with the deployment target set to 10.4, but that wouldn’t work either.

There was a suggestion to start symlinking a specific “as” version into gcc/4.2.1 — didn’t try that. Might have to symlink an “ld” version as well, if it can be figured out which version and to where it should be symlinked.

There was a suggestion to rebuild crt1.o from source from Apple’s site - didn’t try that, as I couldn’t figure out which version corresponded to Tiger’s.

I have a feeling there probably is a way to do it — just doesn’t leap forward to me what it is.

SO - you’re not alone, there’s nothing wrong with your setup. It just doesn’t work, at least at this minute.

It’s not a MacPorts issue, that much I’m fairly certain of.

Ken