Re: Building gcc 4.9.2 on AIX 7.1

[Randy Galbraith <randy.galbraith@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6412 bytes --]

On Sun, Jun 11, 2023 at 6:37 PM Randy Galbraith <randy.galbraith@gmail.com>
wrote:

>
>
> On Sun, Jun 11, 2023, 5:05 PM Jonathan Wakely <jwakely.gcc@gmail.com>
> wrote:
>
>>
>>
>> On Sun, 11 Jun 2023, 22:05 Randy Galbraith via Gcc-help, <
>> gcc-help@gcc.gnu.org> wrote:
>>
>>> On Sun, Jun 11, 2023 at 12:27 PM Tom Kacvinsky via Gcc-help <
>>> gcc-help@gcc.gnu.org> 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@gmail.com>
>>> 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