[Bug target/89096] [7/8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 Richard Biener changed: What|Removed |Added Target Milestone|7.5 |8.4 --- Comment #22 from Richard Biener --- The GCC 7 branch is being closed, re-targeting to GCC 8.4.
[Bug target/89096] [7/8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #21 from David Edelsohn --- This error message does not make any sense. The patch fixed the earlier error.
[Bug target/89096] [7/8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 Andrew Paprocki changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED |--- --- Comment #20 from Andrew Paprocki --- I applied the patch and attempted to rebuild pcre and it still fails in the same manner: ld: 0711-308 SEVERE ERROR: Object pcrecpp_unittest-pcrecpp_unittest.o, csect <_pcrecppunittest.ro_> The csect is part of the .text section. Dumping the assembler (same as last attachment) shows only use of .ro_ as RO: $ grep _pcrecppunittest.ro_ pcrecpp_unittest.s .csect _pcrecppunittest.ro_[RO],4 .csect _pcrecppunittest.ro_[RO],4 .csect _pcrecppunittest.ro_[RO],4 .csect _pcrecppunittest.ro_[RO],4 .csect _pcrecppunittest.ro_[RO],4 .csect _pcrecppunittest.ro_[RO],4 .csect _pcrecppunittest.ro_[RO],4 .csect _pcrecppunittest.ro_[RO],4 .csect _pcrecppunittest.ro_[RO],4 .csect _pcrecppunittest.ro_[RO],4 .csect _pcrecppunittest.ro_[RO],4 There are a few places where this csect immediately follows a reference to .text, but I don't know if that is related at all. Those cases look like this: .csect .text[PR] .ref Lframe..1 .csect _pcrecppunittest.ro_[RO],4
[Bug target/89096] [7/8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #19 from Andrew Paprocki --- Thanks, I’ll give it a try. From memory, the .s file I attached did not contain any RW csect by the same name like you mention in the description, but perhaps the patch still addresses the issue.
[Bug target/89096] [7/8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #18 from David Edelsohn --- https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00219.html
[Bug target/89096] [7/8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #17 from Andrew Paprocki --- Thanks, I’m just interested in the URL / bug / commit for the patch(es) you created so that I can apply them to our in-house GCC and test everything out. If you could point me to them I’d appreciate it.
[Bug target/89096] [7/8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #16 from David Edelsohn --- I applied the patch to GCC to fix this. ATOS and IBM also are trying to work with CMake to fix the broken patches, but Kitware isn't being helpful and accommodating.
[Bug target/89096] [7/8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #15 from Andrew Paprocki --- Created attachment 46597 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46597=edit g++-6 -S output of pcrecpp_unittest.cc Generated with the command line: g++-6 -DHAVE_CONFIG_H -I. -I.. -maix32 -O -MT pcrecpp_unittest-pcrecpp_unittest.o -MD -MP -MF .deps/pcrecpp_unittest-pcrecpp_unittest.Tpo -S ../pcrecpp_unittest.cc
[Bug target/89096] [7/8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #14 from Andrew Paprocki --- I can reproduce this error with a much simpler project, pcre, that uses autotools and libtool. Using pcre 8.42 from https://ftp.pcre.org/pub/pcre/pcre-8.42.tar.gz $ mkdir build $ cd build $ CC=gcc-6 CXX=g++-6 OBJECT_MODE=32 CFLAGS="-maix32 -O" CXXFLAGS="-maix32 -O" ../configure --enable-unicode-properties --enable-pcre16 --enable-pcre32 --enable-jit $ OBJECT_MODE=32 make V=1 ... g++-6 -DHAVE_CONFIG_H -I. -I.. -maix32 -O -MT pcrecpp_unittest-pcrecpp_unittest.o -MD -MP -MF .deps/pcrecpp_unittest-pcrecpp_unittest.Tpo -c -o pcrecpp_unittest-pcrecpp_unittest.o `test -f 'pcrecpp_unittest.cc' || echo '../'`pcrecpp_unittest.cc mv -f .deps/pcrecpp_unittest-pcrecpp_unittest.Tpo .deps/pcrecpp_unittest-pcrecpp_unittest.Po /bin/sh ./libtool --tag=CXX --mode=link g++-6 -maix32 -O -o pcrecpp_unittest pcrecpp_unittest-pcrecpp_unittest.o libpcrecpp.la -lpthreads libtool: link: g++-6 -maix32 -O -o .libs/pcrecpp_unittest pcrecpp_unittest-pcrecpp_unittest.o -L/tmp/pcre/build/.libs -L./.libs -lpcrecpp -lpcre -L/path/to/gcc/lib -lstdc++ -lm -lpthreads -Wl,-blibpath:/usr/local/lib:/path/to/gcc/lib:/path/to/gcc/lib/.:/usr/lib:/lib ld: 0711-308 SEVERE ERROR: Object pcrecpp_unittest-pcrecpp_unittest.o, csect <_pcrecppunittest.ro_> The csect is part of the .text section. collect2: error: ld returned 12 exit status Makefile:1518: recipe for target 'pcrecpp_unittest' failed make[1]: *** [pcrecpp_unittest] Error 1 I've narrowed this down to the usage of the -bsvr4 linker flag, which we use because we depend on passing multiple -R parameters and the linker behavior described in the man page: -R Path ... Multiple instances of this option are concatenated together with each Path separated by a colon. If -bsvr4 is placed on the collect2 command line (obtained from -v output of the link), the link fails with the output above. I know in the past flag ordering has mattered, and in this case it fails in the same manner when it is both the first flag and last flag on the command line. This fails without any usage of -bexpall and -brtl.
[Bug target/89096] [7/8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #13 from Andrew Paprocki --- What is the other bug number w/ patch that you're referring to?
