[Bug libgcc/66809] stage 1 build failure in libgcc on sparc-sun-solaris2.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66809 --- Comment #9 from Eric Botcazou --- > Or build them in-tree, which automatically builds them that way. That avoids > the need to install them separately at all. You may need to control which version you build on specific platforms though so I wouldn't recommend in-tree build.
[Bug libgcc/66809] stage 1 build failure in libgcc on sparc-sun-solaris2.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66809 --- Comment #8 from Jonathan Wakely --- (In reply to Eric Botcazou from comment #4) > I personally build the GMP/MPFR/MPC libraries with --disable-shared. Or build them in-tree, which automatically builds them that way. That avoids the need to install them separately at all. https://gcc.gnu.org/wiki/InstallingGCC
[Bug libgcc/66809] stage 1 build failure in libgcc on sparc-sun-solaris2.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66809 --- Comment #7 from Michael Teske --- (In reply to Eric Botcazou from comment #6) > > Why not add the directory to the RPATH of the created binaries? ... > > Are there any reasons against > > doing it? > > Yes, I don't think that we want to hardcode run-time paths by default. Usually, RPATH does not hardcode the run time path library path, it is still overridable with LD_LIBRARY_PATH, it just provides a default if LD_LIBRARY_PATH is not set. IMHO it would be convenient to have the possibility (need not be the default, just an option to configure) to have gcc finding it's library in the locations where they were when gcc was built. If one needs to have different versions of some utilities (possibly pre-built from different sources) it can be difficult if not impossible to maintain a useful LD_LIBRARY_PATH. Anyway, luckily the rpath tool exists for solaris so I can "tune" the gcc binaries after the build.
[Bug libgcc/66809] stage 1 build failure in libgcc on sparc-sun-solaris2.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66809 --- Comment #6 from Eric Botcazou --- > Why not add the directory to the RPATH of the created binaries? I ended up > doing it manually afterwards by using the rpath utility from > https://blogs.oracle.com/solaris/changing-elf-runpaths-code-included-v2 , > but it could be easily done during linking. Are there any reasons against > doing it? Yes, I don't think that we want to hardcode run-time paths by default.
[Bug libgcc/66809] stage 1 build failure in libgcc on sparc-sun-solaris2.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66809 Michael Teske changed: What|Removed |Added CC||subscribe at teskor dot de --- Comment #5 from Michael Teske --- Why not add the directory to the RPATH of the created binaries? I ended up doing it manually afterwards by using the rpath utility from https://blogs.oracle.com/solaris/changing-elf-runpaths-code-included-v2 , but it could be easily done during linking. Are there any reasons against doing it?
[Bug libgcc/66809] stage 1 build failure in libgcc on sparc-sun-solaris2.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66809 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org --- I personally build the GMP/MPFR/MPC libraries with --disable-shared.
[Bug libgcc/66809] stage 1 build failure in libgcc on sparc-sun-solaris2.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66809 --- Comment #1 from Mikael Pettersson mikpelinux at gmail dot com --- ld.so.1: cc1: fatal: libmpc.so.3: open failed: No such file or directory xgcc: internal compiler error: Killed (program cc1) You need to 1. Tell the dynamic linker where to find the gmp etc shared libraries, or 2. Build gmp etc as non-shared libraries, or 3. Install the gmp etc shared libraries in a standard location. Not a gcc bug.
[Bug libgcc/66809] stage 1 build failure in libgcc on sparc-sun-solaris2.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66809 --- Comment #2 from James Ballantine j.ballantine at gmail dot com --- If you look at attachment, you will see that he options for --with-gmp=/usr/local/add-on/gmp --with-mpc=/usr/local/add-on/mpc --with-mpfr=/usr/local/add-on/mpfr were set
[Bug libgcc/66809] stage 1 build failure in libgcc on sparc-sun-solaris2.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66809 --- Comment #3 from Mikael Pettersson mikpelinux at gmail dot com --- The --with-gmp= etc options work for include files and static link libraries. but do nothing for shared libraries.