On Sun, Jun 11, 2023, 5:05 PM Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: > > > On Sun, 11 Jun 2023, 22:05 Randy Galbraith via Gcc-help, < > gcc-help@xxxxxxxxxxx> wrote: > >> On Sun, Jun 11, 2023 at 12:27 PM Tom Kacvinsky via Gcc-help < >> gcc-help@xxxxxxxxxxx> wrote: >> >> > HI, >> > >> > For some reason my follow-up hasn't made it through. >> > >> > On Sun, Jun 11, 2023 at 11:27 AM Tom Kacvinsky <tkacvins@xxxxxxxxx> >> wrote: >> > >> > <snip> >> > >> > >> > > Those aren't binutils linker warnings. Those are coming from the >> system >> > > linker. Which probably means you are using the system assembler, too. >> > Or >> > > maybe even the odd case where you're using binutils for the assembler >> but >> > > the system linker. >> > > >> > > Can you try with using binutils for the assembler and linker? I am >> > > assuming you either have an older version of GCC for building the >> newer >> > > version of it, or perhaps you have the Sun Pro compilers. In any >> case, >> > you >> > > could use whichever bootstrap compiler you have to build binutils, and >> > then >> > > put they binutils in PATH. The GCC configure script should then chose >> > > those for building. >> > >> > >> > I missed that you're on AIX. So either you're using an older version of >> > GCC to bootstrap, or IBM's xlc/xlC compilers to bootstrap. >> > >> > Here is a thought I had up re-thinking this. This might be an >> > architecture problem. Which version of the POWER chips are you using? >> > YOu might have to force the GCC configuration process to use -march to >> > specify the right processor. But as far as I know, the configure script >> > should be smart enough to figure that out. >> > >> > It's been about ten years since I used the xlc/xlC compilers, so I am >> > not sure how one would select the architecture they want. >> > >> >> Hi Tom. >> >> Our sys-admin team is upgrading AIX 7.1 to 7.2. This broke gcc (an issue >> with IBM delivering non-ansi-standard header files). So my first step is >> an >> attempt to bootstrap gcc 4.9.2 (or later) on a non-upgraded (7.1) system. >> This would be using our existing install of gcc. >> >> $ gcc --version >> gcc (GCC) 4.9.2 >> >> Here are the CPU details: >> >> $ prtconf >> System Model: IBM,9040-MR9 >> Machine Serial Number: XXXXXXX >> Processor Type: PowerPC_POWER9 >> Processor Implementation Mode: POWER 8 >> Processor Version: PV_8_Compat >> Number Of Processors: 4 >> Processor Clock Speed: 2850 MHz >> CPU Type: 64-bit >> Kernel Type: 64-bit >> LPAR Info: 12 XXXXXXXX >> Memory Size: 31744 MB >> Good Memory Size: 31744 MB >> Platform Firmware level: VM930_145 >> Firmware Version: IBM,FW930.50 (VM930_145) >> Console Login: enable >> Auto Restart: true >> Full Core: false >> NX Crypto Acceleration: Capable and Enabled >> <snip> >> >> Details on "ld" and "as" as per configure: >> >> $ ./configure >> checking build system type... powerpc-ibm-aix7.1.0.0 >> <snip> >> checking for gcc... gcc >> checking for C compiler default output file name... a.out >> checking whether the C compiler works... yes >> <snip> >> checking whether we are using the GNU C compiler... yes >> checking whether gcc accepts -g... yes >> checking for gcc option to accept ISO C89... none needed >> checking for g++... g++ >> checking whether we are using the GNU C++ compiler... yes >> <snip> >> checking for as... as >> checking for dlltool... no >> checking for ld... ld >> <snip> >> checking for cc... cc >> checking for c++... c++ >> checking for gcc... gcc >> <snip> >> checking for as... no >> checking for as... as >> <snip> >> checking for ld... no >> checking for ld... ld >> <snip> >> checking where to find the target ar... host tool >> checking where to find the target as... host tool >> checking where to find the target cc... just compiled >> checking where to find the target c++... just compiled >> checking where to find the target c++ for libstdc++... just compiled >> checking where to find the target dlltool... host tool >> checking where to find the target gcc... just compiled >> checking where to find the target gcj... just compiled >> <snip> >> checking where to find the target ld... host tool >> <snip> >> >> And "ld" and "as" I see at the command line: >> >> $ which ld >> /usr/bin/ld >> >> $ file /usr/bin/ld >> /usr/bin/ld: symbolic link to /usr/ccs/bin/ld >> >> $ file /usr/ccs/bin/ld >> /usr/ccs/bin/ld: executable (RISC System/6000 V3.1) or obj module >> >> $ which as >> /usr/bin/as >> >> $ file /usr/bin/as >> /usr/bin/as: symbolic link to /usr/ccs/bin/as >> >> $ file /usr/ccs/bin/as >> /usr/ccs/bin/as: executable (RISC System/6000 V3.1) or obj module >> >> Because gcc 4.9.2 is broken on our AIX 7.2 I am interested (though not as >> a >> first step) in how to boostrap gcc using native C (xlc) compiler. Alas, I >> am still in the process of learning what options can be sent to configure >> to direct it to use xlc. >> > > Bootstrapping gcc 13 works on AIX, is there a reason you have to use an > ancient gcc? > > > >> I just saw Kai's -v suggestion. I'll try that and reply with the details. >> >> Cheers, -Randy >> > We have a need to match gcc version on Red Hat GNU/Linux 7. I am looking forward to newer GCC once Red Hat is upgraded. However, that will likely break our build. We elevate every warning in gcc to error status that stops the building. Thus we need to plan for that. At the moment I just need to support the AIX 7.2 upgrade. Ironically had our port to GNU/Linux been completed this would not be an issue. Cheers, -Randy >
