https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #131 from Peter Bisroev <peter.bisroev at groundlabs dot com> --- (In reply to dave.anglin from comment #130) > > In the meantime, I wanted to ask you. Is it OK for me to add to the PATH > > directory containing binutils-2.32 compiled with aCC prior to bootstrapping > > GCC > > 4.7.4? For bootstrapping I have provided actual utilities to configure > > script > > directly with a flag such as `--with-as`. Currently this directory contains: > > addr2line > > ar > > as > > c++filt > > elfedit > > gprof > > nm > > objcopy > > objdump > > ranlib > > readelf > > size > > strings > > strip > > As expected ld is missing from the above as on HPUX we need to use HP's > > linker. > > But what about the rest of the binaries? Will using them over comparable HP > > ones cause any issues? I am asking as I have had issues with using binutils > > provided binaries over system based ones when bootstrapping gcc on AIX. > Yes. I do it all the time. I also configure with "--with-gnu-as > --with-as=/opt/gnu/bin/as". Yes, I always use --with-as and --with-gnu-as on this platform. However after putting binutils as the first entry in the PATH, the build failed as soon as ar from binutils got invoked. After a bit of digging around looks like my ar and ranlib binaries from binutils are not working properly. For example: -------------------- $ ./ar --help /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylsp' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyolsp' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyfnd' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextuc' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylenguc' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextarr' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylstate' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyprevious' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyextra' in load module '/usr/lib/hpux32/libl.so.1'. Killed -------------------- But those symbols are present in libl.so from what I can see. For now I am still using HP's ar and ranlib, will take a look into what is going on with binutils ar and ranlib a bit later. > There is more info in the "testsuite" directory. For example, for the c > tests, look in > <builddir>/gcc/testsuite/gcc/gcc.log. There similar log files for every > language and > library. Yep, I saw those the other day but thank you for the confirmation that I am looking at the right files. Anyway, today I have rerun the "gmake -j8 check-c check-c++" so that tests can find objdump, etc... Now a lot more tests have passed. The new results have been sent to gcc-testresults mailing list and you can find them here: https://gcc.gnu.org/ml/gcc-testresults/2020-02/msg00150.html For the reference, the previous test result is here: https://gcc.gnu.org/ml/gcc-testresults/2020-01/msg01318.html As you can see from the last test run, with objdump and other binutils in the PATH, the weak and hidden test failures that were seen in the original test run are not present anymore. So is there anything that we want to take a look at at the moment from the remaining failed tests? Thanks! --peter
