https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #132 from dave.anglin at bell dot net --- On 2020-02-02 6:01 p.m., peter.bisroev at groundlabs dot com wrote: > h > 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. This has been reported before on net. Maybe you should try using flex library. It provides the above symbols in its library.. You could try rebuilding binutils with your gcc-4.7.4 build and see how it works out. Run the testsuite. > >> 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 To me, the g++ test results are reasonable. So, I would suggest you try building gcc-8 or trunk with gcc-4.7.4.
