On Sun, Jun 11, 2023 at 6:37 PM Randy Galbraith <randy.galbraith@xxxxxxxxx> wrote: > > > 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 > Hi Jonathan. Even though using GCC 13 may not work for us, I decided to test the build of gcc-13.1.0 (with gmp-6.2.1, mpfr-4.2.0 and mpc-1.3.1): ./configure --enable-languages=c,c++ make Alas it seems to run into the same issue wherein ./conftest runs forever (>1hr, 40min, with 32:22 of cpu time). I'm now going to try export CC=xlc and see if I can get gcc 5.4.0 to build. Cheers, -Randy
