[Bug libgcc/66809] stage 1 build failure in libgcc on sparc-sun-solaris2.10

2018-04-09 Thread ebotcazou at gcc dot gnu.org
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

2018-04-09 Thread redi at gcc dot gnu.org
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

2018-04-09 Thread subscribe at teskor dot de
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

2018-04-09 Thread ebotcazou at gcc dot gnu.org
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

2018-04-09 Thread subscribe at teskor dot de
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

2015-07-13 Thread ebotcazou at gcc dot gnu.org
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

2015-07-08 Thread mikpelinux at gmail dot com
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

2015-07-08 Thread j.ballantine at gmail dot com
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

2015-07-08 Thread mikpelinux at gmail dot com
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.