[Bug other/79322] New: gcc-6.3.0 inconsistent libstdc++ and libgcc_s link for libcc1 and libgcj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79322 Bug ID: 79322 Summary: gcc-6.3.0 inconsistent libstdc++ and libgcc_s link for libcc1 and libgcj Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: edeveaud at pasteur dot fr Target Milestone: --- building and installing gcc-6.3.0 on non std directory lead to some libstdc++ link mismatch. most of the libraries are linked to gcc-6.3.0 installed libraries while some other are linked to system libraries libcc1.so is linked to -> /usr/lib64/libstdc++.so.6 instead of $PREFIX/lib64/libstdc++.so.6 /lib64/libgcc_s.so.1 instead of $PREFIX/lib64/libgcc_s.so.1 libgcj.so libgcj_bc.so libitm.so libstdc++.so are linked to -> /lib64/libgcc_s.so. instead of $PREFIX/lib64/libgcc_s.so.1 see: ldd /exe/gcc/6.3.0/lib64/*.so | grep -e '^/' -e 'libstdc++' -e libgcc_s 2> /err /exe/gcc/6.3.0/lib64/libasan.so: libstdc++.so.6 => /exe/gcc/6.3.0/lib/../lib64/libstdc++.so.6 (0x7f4208a53000) libgcc_s.so.1 => /exe/gcc/6.3.0/lib/../lib64/libgcc_s.so.1 (0x7f4208224000) /exe/gcc/6.3.0/lib64/libatomic.so: /exe/gcc/6.3.0/lib64/libcc1.so: libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x7f22cfe7b000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f22cf64c000) /exe/gcc/6.3.0/lib64/libcilkrts.so: libstdc++.so.6 => /exe/gcc/6.3.0/lib/../lib64/libstdc++.so.6 (0x7f3d0e35a000) libgcc_s.so.1 => /exe/gcc/6.3.0/lib/../lib64/libgcc_s.so.1 (0x7f3d0db2b000) /exe/gcc/6.3.0/lib64/libgcc_s.so: /exe/gcc/6.3.0/lib64/libgcj-tools.so: libgcc_s.so.1 => /exe/gcc/6.3.0/lib/../lib64/libgcc_s.so.1 (0x7ffa5b4a4000) /exe/gcc/6.3.0/lib64/libgcj.so: libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f10eba62000) /exe/gcc/6.3.0/lib64/libgcj_bc.so: libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7ff71e81c000) /exe/gcc/6.3.0/lib64/libgfortran.so: libgcc_s.so.1 => /exe/gcc/6.3.0/lib/../lib64/libgcc_s.so.1 (0x7ffb0610d000) /exe/gcc/6.3.0/lib64/libgij.so: libgcc_s.so.1 => /exe/gcc/6.3.0/lib/../lib64/libgcc_s.so.1 (0x7f7b15d19000) /exe/gcc/6.3.0/lib64/libgomp.so: /exe/gcc/6.3.0/lib64/libitm.so: libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7fbd7ef6c000) /exe/gcc/6.3.0/lib64/liblsan.so: libstdc++.so.6 => /exe/gcc/6.3.0/lib/../lib64/libstdc++.so.6 (0x7fdcd24c) libgcc_s.so.1 => /exe/gcc/6.3.0/lib/../lib64/libgcc_s.so.1 (0x7fdcd1c91000) /exe/gcc/6.3.0/lib64/libmpx.so: /exe/gcc/6.3.0/lib64/libquadmath.so: /exe/gcc/6.3.0/lib64/libssp.so: /exe/gcc/6.3.0/lib64/libstdc++.so: libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7fc460eef000) /exe/gcc/6.3.0/lib64/libtsan.so: libstdc++.so.6 => /exe/gcc/6.3.0/lib/../lib64/libstdc++.so.6 (0x7f963f239000) libgcc_s.so.1 => /exe/gcc/6.3.0/lib/../lib64/libgcc_s.so.1 (0x7f963ea0a000) /exe/gcc/6.3.0/lib64/libubsan.so: libstdc++.so.6 => /exe/gcc/6.3.0/lib/../lib64/libstdc++.so.6 (0x7fe3d5dfb000) libgcc_s.so.1 => /exe/gcc/6.3.0/lib/../lib64/libgcc_s.so.1 (0x7fe3d55cc000) similar to bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78097 best regards Eric additional infos: cat /etc/centos-release CentOS release 6.8 (Final) gcc-6.3.3 was compiled with head -n 8 /tmp/gcc-6.3.0/config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.64. Invocation command line was $ /src/gcc/gcc-6.3.0/configure --prefix=/exe/gcc/6.3.0 --enable-threads=posix --enable-__cxa_atexit --disable-multilib --enable-java-home --with-jvm-root-dir=/exe/gcc/6.3.0/libexec/gcj --enable-languages=c,c++,fortran,java
[Bug other/78711] gcc-6.2.0:: libjavamath.so inconsistent gmp link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78711 --- Comment #5 from Eric --- (In reply to Andreas Schwab from comment #4) > The target libraries must always be built against the libraries of the > target system. You have to populate the sysroot accordingly. as during gcc build gmp is built vs the target system I'm compiling on I still don't understand.
[Bug other/78711] gcc-6.2.0:: libjavamath.so inconsistent gmp link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78711 --- Comment #3 from Eric --- (In reply to Andreas Schwab from comment #1) > The included gmp is host-only, only for use with the compiler, not the > target libraries. sorry if I don't understand correctly. what do you mean by "only for use with the compiler, not the target libraries." download_prerequisite grab gmp and compile gcc suite using this one, so why produced libraries are linked to external gmp ? IMHO produced gcc should linkk to "embeded" gmp downloaded by contrib/download_prerequisites this way one can compile on a build machine with a complete toolchain, tar the installed tree and deploy it on an other machine (same arch and so on) that does not have system gcc, gmp installed. currently this is not possible. please correct me if I am completely wrong Eric
[Bug other/78712] New: gcc-4.9.4:: libjavamath.so inconsistent gmp link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78712 Bug ID: 78712 Summary: gcc-4.9.4:: libjavamath.so inconsistent gmp link Product: gcc Version: 4.9.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: edeveaud at pasteur dot fr Target Milestone: --- hello, whar I've done 1) extracted fresh gcc-4.9.4 archive 2) run contrib/download_prerequisites => gmp, mpfr and mpc are ok 3) run ./configure 4) make && make install 5) then check for linking and then found the following. ''' bigmess:gcc/4.9.4 > find . -type f -name \*.so | xargs ldd ./lib64/libgcj_bc.so: linux-vdso.so.1 => (0x7fffe31f3000) libc.so.6 => /lib64/libc.so.6 (0x7f58383d7000) libgcc_s.so.1 => /local/gensoft2/exe/gcc/4.9.0/lib64/libgcc_s.so.1 (0x7f58381c) /lib64/ld-linux-x86-64.so.2 (0x003cb760) ./lib64/gcj-4.9.4-15/libjvm.so: linux-vdso.so.1 => (0x7fffd6396000) libgcj.so.15 => /local/gensoft2/exe/gcc/4.9.4/lib/../lib64/libgcj.so.15 (0x7f4be93b6000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7f4be918a000) libdl.so.2 => /lib64/libdl.so.2 (0x7f4be8f86000) librt.so.1 => /lib64/librt.so.1 (0x7f4be8d7e000) libc.so.6 => /lib64/libc.so.6 (0x7f4be89e9000) libgcc_s.so.1 => /local/gensoft2/exe/gcc/4.9.4/lib/../lib64/libgcc_s.so.1 (0x7f4be87d3000) /lib64/ld-linux-x86-64.so.2 (0x003cb760) ./lib64/gcj-4.9.4-15/libjavamath.so: linux-vdso.so.1 => (0x7ffebcd91000) libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x7f16cff73000) librt.so.1 => /lib64/librt.so.1 (0x7f16cfd6a000) libc.so.6 => /lib64/libc.so.6 (0x7f16cf9d6000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7f16cf7b9000) /lib64/ld-linux-x86-64.so.2 (0x003cb760) ''' one can note that lib64/gcj-4.9.4-15/libjavamath.so is linked to system gmp not gcc "embeded" one. configure was run with the following arguments ''' configure --prefix=/local/gensoft2/exe/gcc/4.9.4 \ --enable-threads=posix \ --enable-__cxa_atexit \ --disable-multilib \ --disable-bootstrap \ --enable-java-home \ --with-jvm-root-dir=/local/gensoft2/exe/gcc/4.9.4/libexec/gcj \ --enable-languages=c,c++,fortran,java ''' FYI same problem with gcc-6.2.0 see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78711 did I missed something ? best regards Eric
[Bug other/78711] New: gcc-6.2.0:: libjavamath.so inconsistent gmp link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78711 Bug ID: 78711 Summary: gcc-6.2.0:: libjavamath.so inconsistent gmp link Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: edeveaud at pasteur dot fr Target Milestone: --- hello, whar I've done 1) extracted fresh gcc-4.9.4 archive 2) run contrib/download_prerequisites => gmp, mpfr and mpc are ok 3) run ./configure 4) make && make install 5) then check for linking and then found the following. ''' bigmess:/tmp/gcc-6.2.0 > find /tmp/6.2.0 -type f -name \*.so | xargs ldd /tmp/6.2.0/lib64/libgcj_bc.so: linux-vdso.so.1 => (0x7ffeec3eb000) libc.so.6 => /lib64/libc.so.6 (0x7fb99c49d000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7fb99c287000) /lib64/ld-linux-x86-64.so.2 (0x003cb760) /tmp/6.2.0/lib64/gcj-6.2.0-17/libjvm.so: linux-vdso.so.1 => (0x7ffc26147000) libgcj.so.17 => /tmp/6.2.0/lib/../lib64/libgcj.so.17 (0x7f8ce17b3000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7f8ce1587000) libdl.so.2 => /lib64/libdl.so.2 (0x7f8ce1383000) librt.so.1 => /lib64/librt.so.1 (0x7f8ce117b000) libc.so.6 => /lib64/libc.so.6 (0x7f8ce0de6000) libgcc_s.so.1 => /tmp/6.2.0/lib/../lib64/libgcc_s.so.1 (0x7f8ce0bd) /lib64/ld-linux-x86-64.so.2 (0x003cb760) /tmp/6.2.0/lib64/gcj-6.2.0-17/libjavamath.so: linux-vdso.so.1 => (0x7ffcded7b000) libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x7f7af0c29000) librt.so.1 => /lib64/librt.so.1 (0x7f7af0a21000) libc.so.6 => /lib64/libc.so.6 (0x7f7af068c000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7f7af046f000) /lib64/ld-linux-x86-64.so.2 (0x003cb760) ''' one can note that lib64/gcj-6.2.0-17/libjavamath.so is linked to system gmp not gcc "embeded" one. configure was run with the following arguments ''' configure --prefix=/local/gensoft2/exe/gcc/6.2.0 \ --enable-threads=posix \ --enable-__cxa_atexit \ --disable-multilib \ --disable-bootstrap \ --enable-java-home \ --with-jvm-root-dir=/local/gensoft2/exe/gcc/6.2.0/libexec/gcj \ --enable-languages=c,c++,fortran,java ''' FYI same problem with gcc-6.2.0 did I missed something ? best regards Eric
[Bug other/78097] gcc-6.2.0 inconsistent libgcc_s.so link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78097 --- Comment #1 from Eric --- oops of course find /exe/gcc/4.9.4 -type l -name \*.so | xargs ldd | grep libgcc_s.so should be read find /exe/gcc/6.0.2 -type l -name \*.so | xargs ldd | grep libgcc_s.so
[Bug other/78097] New: gcc-6.2.0 inconsistent libgcc_s.so link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78097 Bug ID: 78097 Summary: gcc-6.2.0 inconsistent libgcc_s.so link Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: edeveaud at pasteur dot fr Target Milestone: --- Hello, building gcc-6.2.0 on centos6 lead on inconsistent link to libgcc_s.so some libraries are linked to the installed libraries, while other are linked to libgcc_s.so system libraries here is a Dockerfile that reproduce the problem. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- FROM centos:6 MAINTAINER Eric Deveaud RUN yum install -y gcc gcc-c++ wget WORKDIR /src # install internal gcc RUN mkdir -p gcc/6.2.0 && \ cd gcc/6.2.0 && \ wget -qO- ftp://ftp.lip6.fr/pub/gcc/releases/gcc-6.2.0/gcc-6.2.0.tar.gz | tar xz --strip-components 1 && \ sh contrib/download_prerequisites RUN mkdir -p /tmp/build && \ cd /tmp/build && \ /src/gcc/6.2.0/configure --disable-multilib --enable-threads=posix --enable-__cxa_atexit -enable-languages=c,c++ --prefix=/exe/gcc/6.2.0 && \ MAKEFLAGS="-j $(grep -c ^processor /proc/cpuinfo)" make bootstrap && \ make install # run produced docker using # docker run -i -t gcc /bin/bash # then # find /exe/gcc/4.9.4 -type l -name \*.so | xargs ldd | grep libgcc_s.so -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- container was built using docker build -f Dockerfile-gcc -t gcc . | tee log (I can provide buil log) and then container run using docker run -i -t gcc /bin/bash following command emphasis the linking problem. [root@5ec47cdc07e6 src]# find /exe/gcc/6.2.0/ -type l -name \*.so | xargs ldd | grep libgcc_s.so libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7ff1dde2e000) libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1 (0x7f1be06c7000) libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1 (0x7f6490629000) libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1 (0x7f7afcaf3000) libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1 (0x7febfaf18000) libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1 (0x7fbe2165c000) libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1 (0x7f18d26f8000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f2390256000) libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1 (0x7f9755e8a000) /exe/gcc/6.2.0/lib64/libstdc++.so /exe/gcc/6.2.0/lib64/libitm.so links to /lib64/libgcc_s.so.1 /exe/gcc/6.2.0/lib64/libasan.so /exe/gcc/6.2.0/lib64/liblsan.so /exe/gcc/6.2.0/lib64/libcilkrts.so /exe/gcc/6.2.0/lib64/libtsan.so /exe/gcc/6.2.0/lib64/libubsan.so /exe/gcc/6.2.0/lib64/libcc1.so /exe/gcc/6.2.0/lib/gcc/x86_64-pc-linux-gnu/6.2.0/plugin/libcc1plugin.so links to /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1 NB see also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78096 @Markus I hope that gcc-6.0.2 is still maintained ;-) best regards Eric
[Bug other/78096] gcc-4.9.4 make bootstrap libgcc_s.so link problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78096 --- Comment #6 from Eric --- same problem with gcc/6.2.0 /exe/gcc/6.2.0/lib64/libstdc++.so /exe/gcc/6.2.0/lib64/libitm.so links to /lib64/libgcc_s.so.1 /exe/gcc/6.2.0/lib64/libasan.so /exe/gcc/6.2.0/lib64/liblsan.so /exe/gcc/6.2.0/lib64/libcilkrts.so /exe/gcc/6.2.0/lib64/libtsan.so /exe/gcc/6.2.0/lib64/libubsan.so /exe/gcc/6.2.0/lib64/libcc1.so /exe/gcc/6.2.0/lib/gcc/x86_64-pc-linux-gnu/6.2.0/plugin/libcc1plugin.so links to /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1 I'll open a new bug report for gcc/6.2.0 docker run -i -t gcc /bin/bash [root@5ec47cdc07e6 src]# find /exe/gcc/6.2.0/ -type l -name \*.so | xargs ldd | grep libgcc_s.so libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7ff1dde2e000) libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1 (0x7f1be06c7000) libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1 (0x7f6490629000) libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1 (0x7f7afcaf3000) libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1 (0x7febfaf18000) libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1 (0x7fbe2165c000) libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1 (0x7f18d26f8000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f2390256000) libgcc_s.so.1 => /exe/gcc/6.2.0/lib/../lib64/libgcc_s.so.1 (0x7f9755e8a000)
[Bug other/78096] gcc-4.9.4 make bootstrap libgcc_s.so link problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78096 --- Comment #4 from Eric --- anyway the link is not consistent what can I do in order to remove any system gcc + libs to provide ONLY the gcc we compiled to our cluster users ?
[Bug other/78096] gcc-4.9.4 make bootstrap libgcc_s.so link problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78096 --- Comment #2 from Eric --- so I have to switch on gcc version 5 or 6 with incompatible ABI change in the C++ library ? nice ;-)
[Bug other/78096] New: gcc-4.9.4 make bootstrap libgcc_s.so link problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78096 Bug ID: 78096 Summary: gcc-4.9.4 make bootstrap libgcc_s.so link problem Product: gcc Version: 4.9.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: edeveaud at pasteur dot fr Target Milestone: --- Hello, while building gcc-4.9.4 on centos6 I have a strange link problem some libraries are linked to the installed libgcc_s.so libraries, while other are linked to libgcc_s.so system libraries eg: link to system libgcc_s.so libstdc++.so libvtv.so libitm.so link to installed libgcc_s.so libasan.so liblsan.so libcilkrts.so libtsan.so libubsan.so here is a Dockerfile that reproduce the problem. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- FROM centos:6 MAINTAINER Eric Deveaud RUN yum install -y gcc gcc-c++ wget WORKDIR /src # install internal gcc RUN mkdir -p gcc/4.9.4 && \ cd gcc/4.9.4 && \ wget -qO- ftp://ftp.lip6.fr/pub/gcc/releases/gcc-4.9.4/gcc-4.9.4.tar.gz | tar xz --strip-components 1 && \ sh contrib/download_prerequisites RUN mkdir -p /tmp/build && \ cd /tmp/build && \ /src/gcc/4.9.4/configure --disable-multilib --enable-threads=posix --enable-__cxa_atexit -enable-languages=c,c++ --prefix=/exe/gcc/4.9.4 && \ make bootstrap && \ make install -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- container was built using docker build -f Dockerfile-gcc -t gcc . | tee log (I can provide buil log and then container run using docker run -i -t gcc /bin/bash following command emphasis the linking problem. find /exe/gcc/4.9.4 -type l -name \*.so | xargs ldd | grep libgcc_s.so libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f043971c000) libgcc_s.so.1 => /exe/gcc/4.9.4/lib/../lib64/libgcc_s.so.1 (0x7f7ae4b97000) libgcc_s.so.1 => /exe/gcc/4.9.4/lib/../lib64/libgcc_s.so.1 (0x7f4321ef7000) libgcc_s.so.1 => /exe/gcc/4.9.4/lib/../lib64/libgcc_s.so.1 (0x7fd9918fe000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f5ea3ba4000) libgcc_s.so.1 => /exe/gcc/4.9.4/lib/../lib64/libgcc_s.so.1 (0x7fbaf49bc000) libgcc_s.so.1 => /exe/gcc/4.9.4/lib/../lib64/libgcc_s.so.1 (0x7fd7f5423000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f57bcfeb000) did I missed something ? best regards Eric
