[Bug c/36481] New: gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[Bug c/36481] New: gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[david dot kirkby at onetel dot net]

I'm trying to compile gcc 4.3.1 on a Laptop running Solaris Express Community
Edition Build 89.


drkirkby@kingfisher:[~/build] $ cat /etc/release
                   Solaris Express Community Edition snv_89 X86
           Copyright 2008 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                              Assembled 06 May 2008


After configuring with these options (plenty of others tried)

 $ ../gcc-4.3.1/configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld
--enable-shared --enable-languages=c,c++,fortran LD_LIBRARY_PATH=/usr/local/lib
--with-gmp=/usr/local --with-mpfr=/usr/local --with-mpfr-lib=/usr/local/lib
--with-mpfr-include=/usr/local/include --with-gmp-include=/usr/local/include
--with-gmp-lib=/usr/local/lib


gcc spends 15 minutes or so compiling, then bombs out with:

checking for i386-pc-solaris2.11-lipo... lipo
checking for i386-pc-solaris2.11-nm... /export/home/drkirkby/build/./gcc/nm
checking for i386-pc-solaris2.11-ranlib... ranlib
checking for i386-pc-solaris2.11-strip... strip
checking whether ln -s works... yes
checking for i386-pc-solaris2.11-gcc... /export/home/drkirkby/build/./gcc/xgcc
-B/export/home/drkirkby/build/./gcc/ -B/usr/local/i386-pc-solaris2.11/bin/
-B/usr/local/i386-pc-solaris2.11/lib/ -isystem
/usr/local/i386-pc-solaris2.11/include -isystem
/usr/local/i386-pc-solaris2.11/sys-include
checking for suffix of object files... configure: error: cannot compute suffix
of object files: cannot compile
See `config.log' for more details.
gmake[2]: *** [configure-stage1-target-libgcc] Error 1
gmake[2]: Leaving directory `/export/home/drkirkby/build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/ex


A search on the web for the "configure: error: cannot compute suffix of object
files: cannot compile" suggests setting LD_LIBRARY_PATH, as above. That does
not work. I've also tried

set LD_LIBRARY_PATH=/usr/local/lib
export LD_LIBRARY_PATH

but that does not work either.

The log file:

./i386-pc-solaris2.11/libgcc/config.log
(see end of message)

shows the linker can't seem to find the library libmpfr.so.1. But that does
exists. I've tried every option to configure that might tell the linker where
to find this library:

--with-mpfr=/usr/local
--with-mpfr-lib=/usr/local/lib
--with-mpfr-include=/usr/local/include

but it does not work.

In contrast, I can easily use that library if I compile with cc or gcc.

Neither of these present any error message.
drkirkby@kingfisher:[~] $ cc  -L/usr/local/lib -lmpfr  f.c
drkirkby@kingfisher:[~] $ gcc  -L/usr/local/lib -lmpfr  f.c

so the library is ok.

Here's the log file. Any idea why the building of gcc 4.3.1 is failing?


Target: i386-pc-solaris2.11
Configured with: ../gcc-4.3.1/configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,fortran
LD_LIBRARY_PATH=/usr/local/lib --with-gmp=/usr/local --with-mpfr=/usr/local
--with-mpfr-lib=/usr/local/lib --with-mpfr-include=/usr/local/include
--with-gmp-include=/usr/local/include --with-gmp-lib=/usr/local/lib
Thread model: posix
gcc version 4.3.1 (GCC)
configure:2374: $? = 0
configure:2376: /export/home/drkirkby/build/./gcc/xgcc
-B/export/home/drkirkby/build/./gcc/ -B/usr/local/i386-pc-solaris2.11/bin/
-B/usr/local/i386-pc-solaris2.11/lib/ -isystem
/usr/local/i386-pc-solaris2.11/include -isystem
/usr/local/i386-pc-solaris2.11/sys-include -V </dev/null >&5
xgcc: '-V' must come at the start of the command line
configure:2379: $? = 1
configure:2398: /export/home/drkirkby/build/./gcc/xgcc
-B/export/home/drkirkby/build/./gcc/ -B/usr/local/i386-pc-solaris2.11/bin/
-B/usr/local/i386-pc-solaris2.11/lib/ -isystem
/usr/local/i386-pc-solaris2.11/include -isystem
/usr/local/i386-pc-solaris2.11/sys-include -o conftest -g
-fkeep-inline-functions   conftest.c  >&5
ld.so.1: cc1: fatal: libmpfr.so.1: open failed: No such file or directory
xgcc: Internal error: Killed (program cc1)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
configure:2401: $? = 1
configure:2567: checking for suffix of object files
configure:2588: /export/home/drkirkby/build/./gcc/xgcc
-B/export/home/drkirkby/build/./gcc/ -B/usr/local/i386-pc-solaris2.11/bin/
-B/usr/local/i386-pc-solaris2.11/lib/ -isystem
/usr/local/i386-pc-solaris2.11/include -isystem
/usr/local/i386-pc-solaris2.11/sys-include -c -g -fkeep-inline-functions 
conftest.c >&5
ld.so.1: cc1: fatal: libmpfr.so.1: open failed: No such file or directory
xgcc: Internal error: Killed (program cc1)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
configure:2591: $? = 1
configure: failed program was:


Someone suggested I set CONFIG_SHELL to /bin/bash. That did not help. 
Also tried LDFLAGS='-L/usr/local/lib -R/usr/local/lib'
but again did not help.


-- 
           Summary: gcc fails to build on Solaris x86 - it forgets the
                    locations of libmpfr
           Product: gcc
           Version: 4.3.1
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: david dot kirkby at onetel dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2008-06-10 08:52 -------
Your configure line should not have LD_LIBRARY_PATH set.

Also this works for me ...


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|blocker                     |normal
          Component|c                           |bootstrap


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[david dot kirkby at onetel dot net]

------- Comment #2 from david dot kirkby at onetel dot net  2008-06-10 22:37 -------
Subject: Re:  gcc fails to build on Solaris x86 - it
 forgets the locations of libmpfr

pinskia at gcc dot gnu dot org wrote:
> ------- Comment #1 from pinskia at gcc dot gnu dot org  2008-06-10 08:52 -------
> Your configure line should not have LD_LIBRARY_PATH set.
>
> Also this works for me ...
>
>
>   


Can you tell me what I should set? Previous versions have worked with 
far less messing around with flags to configure. If you can suggest a 
set of flags which will work, I will try that.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[BlanchardJ at ieee dot org]

------- Comment #3 from BlanchardJ at ieee dot org  2008-07-02 00:59 -------
(In reply to comment #2)
> Subject: Re:  gcc fails to build on Solaris x86 - it
>  forgets the locations of libmpfr
> 
> pinskia at gcc dot gnu dot org wrote:
> > ------- Comment #1 from pinskia at gcc dot gnu dot org  2008-06-10 08:52 -------
> > Your configure line should not have LD_LIBRARY_PATH set.
> >
> > Also this works for me ...
> >
> >
> >   
> 
> 
> Can you tell me what I should set? Previous versions have worked with 
> far less messing around with flags to configure. If you can suggest a 
> set of flags which will work, I will try that.
> 

The error you get mean that the dynamic linker cannot find the required dynamic
library in this case libmpfr.so.1. You must add the installation path of mpfr
and gmp to the dynamic linker search path using the crle command.

Assuming that gmp and mpfr are installed in usr/local/lib/ then the following
command should take care of the problem.

**CAREFUL changes made with crle are immediate and if done incorrectly the
dynamic linker will stop working and Solaris won't boot anymore**

crle -u -l /usr/local/lib


-- 

BlanchardJ at ieee dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |BlanchardJ at ieee dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[gbarnt at student dot dtu dot dk]

------- Comment #5 from gbarnt at student dot dtu dot dk  2009-03-23 17:23 -------
Sadly my skills with bugzilla's haven't improved. I meant to have the following
accompany the patch above:

This issue is also present on an x86_64 red hat linux in gcc-4.3.3. 

Usage of --with-gmp and --with-mpfr does not add the path to the run-time
dependencies (see ld's -rpath flag). 

Configured with --with-gmp=$HOME/softInstall_blades/
--with-mpfr=$HOME/softInstall_blades

my x86_64-unknown-linux-gnu/libgcc/config.log (home folder replaced by ~):
~/software/gcc_2build/./gcc/cc1: error while loading shared libraries:
libmpfr.so.1: cannot open shared object file: No such file or direc
tory

ldd gcc/cc1 yields:
        libmpfr.so.1 => not found
        libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x0000003296200000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003365a00000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003365600000)

Notice that it wrongly located the libgmp in /usr/lib64, when I explicitly
asked for it to use the gmp in subdir of my home folder.

I do not have root access to this machine (university) so most (read: all) our
software is installed in non-standard paths - else I would just have
upgraded/installed gmp/mpfr via yum (red hat's package manager) and called it a
day.

Manually adding LDFLAGS="-Wl,-rpath,[dir]" does not work (it still found the
wrong dirs). The "crle" approach is not possible (it is not a sun/solaris
machine).

Looking at configure.ac (gcc-root folder - line: 1191) the variables set by
--with-gmp only adds "-L". Manually appending "-Wl,-rpath,[dir variable]" to
the lib-part worked for me, though "-Wl,-R,[dir variable]" is probably more
portable (since gnu ld translates -R [dir] into -rpath [dir] and solaris uses
-R [dir]). I have not tested if this solution allows [dir variable] to contain
spaces.

For other users suffering this: modification of configure.ac requires autoconf
to update the "configure" script.

~Niels


-- 

gbarnt at student dot dtu dot dk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gbarnt at student dot dtu
                   |                            |dot dk


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[gbarnt at student dot dtu dot dk]

------- Comment #4 from gbarnt at student dot dtu dot dk  2009-03-23 17:22 -------
Created an attachment (id=17522)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17522&action=view)
Patch adding -Wl,-R,[dir] to --with-gmp/mpfr(-lib)?

Patch that adds linker flags "-Wl,-R,[dir]" to the linker flags generated by
the --with-gmp-lib, --with-gmp, --with-mpfr and --with-mpfr-lib options.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[gbarnt at student dot dtu dot dk]

------- Comment #6 from gbarnt at student dot dtu dot dk  2009-03-23 18:38 -------
(From update of attachment 17522)
Sorry, too much copy-paste in the patch... re-uploading a new patch that does
not break --with-(gmp|mpfr)-lib. 


-- 

gbarnt at student dot dtu dot dk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #17522|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[gbarnt at student dot dtu dot dk]

------- Comment #7 from gbarnt at student dot dtu dot dk  2009-03-23 18:42 -------
Created an attachment (id=17524)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17524&action=view)
Same as previous - except for the -lib error.

This patch replaces my old patch and does not break the --with-gmp-lib and
--with-mpfr-lib (I had used the wrong variable - too much copy/paste). Aside
from that, it is exactly like the old patch.

This patch (also) requires autoconf to be run afterwards.

Patch was created with:
user@host$ diff -Naur gcc-old/configure.ac gcc-new/configure.ac >
gcc-4.3.3_runtime_link.patch

~Niels


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[rwild at gcc dot gnu dot org]

------- Comment #8 from rwild at gcc dot gnu dot org  2009-03-24 17:47 -------
Hello David,

(In reply to comment #0)
> I'm trying to compile gcc 4.3.1 on a Laptop running Solaris Express Community
> Edition Build 89.
[...]
> A search on the web for the "configure: error: cannot compute suffix of object
> files: cannot compile" suggests setting LD_LIBRARY_PATH, as above. That does
> not work. I've also tried
> 
> set LD_LIBRARY_PATH=/usr/local/lib
> export LD_LIBRARY_PATH
> 
> but that does not work either.

Is that exactly what you tried?  Because that doesn't do the right thing.
Instead, use
  LD_LIBRARY_PATH=/usr/local/lib
  export LD_LIBRARY_PATH

with a Bourne-like shell, or
  setenv LD_LIBRARY_PATH /usr/local/lib

with a csh-like shell.

> Also tried LDFLAGS='-L/usr/local/lib -R/usr/local/lib'
> but again did not help.

This might work in the SVN trunk version of GCC (haven't checked though).


-- 

rwild at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rwild at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[sebastian dot wenzler at hp dot com]

------- Comment #9 from sebastian dot wenzler at hp dot com  2009-04-16 06:40 -------
I had the same problem with Solaris 10 on sparcv9 with gcc-4.3.3.

Environment:
 1) binutils/2.15     2) bison/1.875       3) automake/1.4-p5 4) gcc/4.2.4

LD_RUN_PATH=/local/scratch/xhpsewe/424-64bit/lib/sparcv9:/local/scratch/xhpsewe/424-64bit/lib
PATH=/app/automake/1.4-p5/bin:/app/bison/1.875/bin:/app/binutils/2.15/bin:/local/scratch/xhpsewe/424-64bit/bin

~/gcc-4.3.3/configure --prefix /local/scratch/xhpsewe/gcc433-64bit
--enable-languages=c,c++ --with-gmp=/app/gmp/4.2.4 --with-mpfr=/app/mpfr/2.4.0
sparcv9-sun-solaris2.10

After applying the patch (2009-03-23 18:42) I get 

make: Fatal error in reader: Makefile, line 51: Unexpected end of line seen
Current working directory
/local/scratch/builddir/build-sparcv9-sun-solaris2.10/fixincludes
*** Error code 1
The following command caused the error:
r=`${PWDCMD-pwd}`; export r; \
s=`cd /home/xhpsewe/gcc-4.3.3; ${PWDCMD-pwd}`; export s; \
FLEX="/home/xhpsewe/gcc-4.3.3/missing flex"; export FLEX;  LEX="lex"; export
LEX; BISON="bison"; export BISON;  YACC="bison -y"; export YACC;  M4="m4";
export M4;  MAKEINFO="/home/xhpsewe/gcc-4.3.3/missing makeinfo
--split-size=5000000 --split-size=5000000"; export MAKEINFO;  AR="ar"; export
AR;  AS="as"; export AS;  CC="sparcv9-sun-solaris2.10-gcc"; export CC; 
CFLAGS="-g -O2"; export CFLAGS;  CONFIG_SHELL="/bin/bash"; export CONFIG_SHELL;
 CXX="sparcv9-sun-solaris2.10-g++"; export CXX;  CXXFLAGS="-g -O2"; export
CXXFLAGS;  GCJ=""; export GCJ;  GFORTRAN=""; export GFORTRAN; 
DLLTOOL="dlltool"; export DLLTOOL;  LD="/usr/ccs/bin/ld"; export LD; 
LDFLAGS=""; export LDFLAGS;  NM="nm"; export NM;  RANLIB="ranlib"; export
RANLIB;  WINDRES="windres"; export WINDRES;  WINDMC="windmc"; export WINDMC; \
(cd build-sparcv9-sun-solaris2.10/fixincludes && \
  make   all)
make: Fatal error: Command failed for target `all-build-fixincludes'
Current working directory /local/scratch/builddir
*** Error code 1
The following command caused the error:
r=`${PWDCMD-pwd}`; export r; \
s=`cd /home/xhpsewe/gcc-4.3.3; ${PWDCMD-pwd}`; export s; \
if test -f stage1-lean  ; then \
  echo Skipping rebuild of stage1 ; \
else \
  make stage1-start; \


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[gbarnt at student dot dtu dot dk]

------- Comment #10 from gbarnt at student dot dtu dot dk  2009-05-01 09:01 -------
In reply to #9:

I have tried to build gcc with and without my own patch on our solaris
machines. While both of them fails they fail at the same place (namely
configuration of [arch]/libgcc trying to figure out the object suffix). They do
however die of different reasons (the patched dies due to xgcc seg. faulting
and the unpatched dies because cc1 is unable to locate libmpfr), but that is a
different matter and probably also another bug-thread.

I checked the "build-[arch]/fixincludes" and I cannot see a different between
the patched and the unpatched prior to line 51. Of course these files are
auto-generated, so ... I did however notice that line 50 is the first line in
the make file to use ":=" rather than "=" (both in patched and unpatched
version).

  target = sparc-sun-solaris2.10
  target_noncanonical:=sparc-sun-solaris2.10

Then I realized that we have a GNU Make installed, which I have been using. If
I use a non-GNU make it also fails with that error in that directory. 

  make: Fatal error in reader: Makefile, line 51: Unexpected end of line seen

Nevertheless it also dies in the unpatched version - same place, same error.
(NB: For this test I did not rebuild, I just ran the other make in that dir.)

Opening the Makefile and replacing the ":=" with "=" seems remove the
"Unexpected end of line seen". The other issue you met does not go away though.
But I get this issue with two out of the 4 different "make"s we have installed.
The two succeeding are different version of the GNU make and the failing onces
are (probably) not GNU make (they do not understand --version and -v is
interpreted as something else ... probably verbose).

Nevertheless, from what I can see your issue is likely to originate from a
syntax issue with the Makefile. Since my patch requires running autoconf, the
issue might be that the version of autoconf you used was designed to work with
a newer version of make than the ones failing. My suggestion is to try using an
older autoconf or a newer make or/and a GNU make.

Sorry for the late reply by the way. Hope it helps.

~Niels


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[schwab at linux-m68k dot org]

------- Comment #11 from schwab at linux-m68k dot org  2009-05-01 09:51 -------
GNU make is required for building gcc.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[abhishekfishy2000 at gmail dot com]

------- Comment #12 from abhishekfishy2000 at gmail dot com  2010-01-14 10:03 -------
lfs:~/SOURCES/gcc-build$ cat /proc/version 
Linux version 2.6.18-164.el5 (mockbuild@x86-002.build.bos.redhat.com) (gcc
version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Tue Aug 18 15:51:54 EDT 2009
lfs:~/SOURCES/gcc-build$ 

following is my configure

lfs:~/SOURCES/gcc-build$ ../gcc-4.4.1/configure --target=$LFS_TGT
--prefix=/tools --disable-nls --disable-shared --disable-multilib 
--disable-decimal-float --disable-threads --disable-libmudflap --disable-libssp
--disable-libgomp --enable-languages=c --with-gmp=/tools --with-mpfr=/tools


looks like gcc-build/./gcc/cc1 is not looking for libs in right places

lfs:~/SOURCES/gcc-build$ 
lfs:~/SOURCES/gcc-build$ strace -e trace=open
/home/lfs/SOURCES/gcc-build/./gcc/cc1
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib/tls/i686/sse2/libmpfr.so.1", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/lib/tls/i686/libmpfr.so.1", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/lib/tls/sse2/libmpfr.so.1", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/lib/tls/libmpfr.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/i686/sse2/libmpfr.so.1", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/lib/i686/libmpfr.so.1", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/lib/sse2/libmpfr.so.1", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/lib/libmpfr.so.1", O_RDONLY)     = -1 ENOENT (No such file or directory)
open("/usr/lib/tls/i686/sse2/libmpfr.so.1", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("/usr/lib/tls/i686/libmpfr.so.1", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib/tls/sse2/libmpfr.so.1", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib/tls/libmpfr.so.1", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib/i686/sse2/libmpfr.so.1", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib/i686/libmpfr.so.1", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib/sse2/libmpfr.so.1", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib/libmpfr.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
/home/lfs/SOURCES/gcc-build/./gcc/cc1: error while loading shared libraries:
libmpfr.so.1: cannot open shared object file: No such file or directory
lfs:~/SOURCES/gcc-build$ 
lfs:~/SOURCES/gcc-build$                  


-- 

abhishekfishy2000 at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |abhishekfishy2000 at gmail
                   |                            |dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[abhishekfishy2000 at gmail dot com]

------- Comment #13 from abhishekfishy2000 at gmail dot com  2010-01-14 10:06 -------
(In reply to comment #11)
> GNU make is required for building gcc.
> 

I'm using lfs:~/SOURCES/gcc-build$ make --version
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for i686-redhat-linux-gnu
lfs:~/SOURCES/gcc-build$ 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[david dot kirkby at onetel dot net]

------- Comment #14 from david dot kirkby at onetel dot net  2010-01-15 04:44 -------
(In reply to comment #10)
> In reply to #9:
> 
> I have tried to build gcc with and without my own patch on our solaris
> machines. While both of them fails they fail at the same place (namely
> configuration of [arch]/libgcc trying to figure out the object suffix). They 

It would be good if a patch similar to yours will work, so alloing gcc to be
installed in an arbitrary location and used without setting LD_LIBRARY_PATH. 

The fact is, a lot of people using Solaris do not have root access, so using
crle is not an option. 

It should be noted, gcc binaries from Blastwave install in a non standard
location (/opt/csw) and do run without the user having to set LD_LIBRARY_PATH.
Of course, you need root acces to install them, but they do *not* modify the
linker search path with crle, but work without doing that. 

Despite asking a couple of times, I've never managed to get an answer how the
Blastwave binaries achieve this. 

I'd like a pound (I'm English) for every time I have seen this issue raised on
Solaris forums. It is something wanted by many, but I believe the gcc
developers do not feel is necessary. 

Some have told be /usr/local is "a standard" though it's not a "standard"
reconised by any official body, like ISO, IEEE etc. But normal users cant write
there either.

PS, you could always ask your uni system admins if they would set you up in a
Solaris 10 zone. The memory overhead of a zone is quite small (well under 100
MB) and if in a zone, they could give you root access. 

Dave 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[BlanchardJ at ieee dot org]

------- Comment #15 from BlanchardJ at ieee dot org  2010-01-15 05:12 -------
(In reply to comment #14)
> (In reply to comment #10)
> > In reply to #9:
> > 
> > I have tried to build gcc with and without my own patch on our solaris
> > machines. While both of them fails they fail at the same place (namely
> > configuration of [arch]/libgcc trying to figure out the object suffix). They 
> 
> It would be good if a patch similar to yours will work, so alloing gcc to be
> installed in an arbitrary location and used without setting LD_LIBRARY_PATH. 
> 
> The fact is, a lot of people using Solaris do not have root access, so using
> crle is not an option. 
> 
> It should be noted, gcc binaries from Blastwave install in a non standard
> location (/opt/csw) and do run without the user having to set LD_LIBRARY_PATH.
> Of course, you need root acces to install them, but they do *not* modify the
> linker search path with crle, but work without doing that. 
> 
> Despite asking a couple of times, I've never managed to get an answer how the
> Blastwave binaries achieve this. 
> 
> I'd like a pound (I'm English) for every time I have seen this issue raised on
> Solaris forums. It is something wanted by many, but I believe the gcc
> developers do not feel is necessary. 
> 
> Some have told be /usr/local is "a standard" though it's not a "standard"
> reconised by any official body, like ISO, IEEE etc. But normal users cant write
> there either.
> 
> PS, you could always ask your uni system admins if they would set you up in a
> Solaris 10 zone. The memory overhead of a zone is quite small (well under 100
> MB) and if in a zone, they could give you root access. 
> 
> Dave 
> 

We modify the runpaths of the final binaries to achieve this results. It is
done the same way with nearly all of our packages.

There is a few way of doing this but the most reliable one is as follow :

Define the LD_OPTIONS env variable before building gcc and use it to add the
correct runtime path.

for example a typical blastwave build would have at a minimum :

export LD_OPTIONS='-R/opt/csw/lib'

In this case the final shared libraries will contain runtime search paths to
find stuff in /opt/csw/lib. Now there is a catch though if you want to build a
multilib gcc for the gcc build you should use :

export LD_OPTIONS='-R/opt/csw/lib/$ISALIST'

In this case the libraries will be able to search for 64 or 32 bit libs
accordingly.

Hope this help,

Jonathan Blanchard


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[david dot kirkby at onetel dot net]

------- Comment #16 from david dot kirkby at onetel dot net  2010-01-15 09:59 -------
Subject: Re:  gcc fails to build on Solaris x86 - it
 forgets the locations of libmpfr

BlanchardJ at ieee dot org wrote:
> ------- Comment #15 from BlanchardJ at ieee dot org  2010-01-15 05:12 -------
> (In reply to comment #14)
>> (In reply to comment #10)
>>> In reply to #9:
>>>
>>> I have tried to build gcc with and without my own patch on our solaris
>>> machines. While both of them fails they fail at the same place (namely
>>> configuration of [arch]/libgcc trying to figure out the object suffix). They 
>> It would be good if a patch similar to yours will work, so alloing gcc to be
>> installed in an arbitrary location and used without setting LD_LIBRARY_PATH. 
>>
>> The fact is, a lot of people using Solaris do not have root access, so using
>> crle is not an option. 
>>
>> It should be noted, gcc binaries from Blastwave install in a non standard
>> location (/opt/csw) and do run without the user having to set LD_LIBRARY_PATH.
>> Of course, you need root acces to install them, but they do *not* modify the
>> linker search path with crle, but work without doing that. 
>>
>> Despite asking a couple of times, I've never managed to get an answer how the
>> Blastwave binaries achieve this. 
>>
>> I'd like a pound (I'm English) for every time I have seen this issue raised on
>> Solaris forums. It is something wanted by many, but I believe the gcc
>> developers do not feel is necessary. 
>>
>> Some have told be /usr/local is "a standard" though it's not a "standard"
>> reconised by any official body, like ISO, IEEE etc. But normal users cant write
>> there either.
>>
>> PS, you could always ask your uni system admins if they would set you up in a
>> Solaris 10 zone. The memory overhead of a zone is quite small (well under 100
>> MB) and if in a zone, they could give you root access. 
>>
>> Dave 
>>
> 
> We modify the runpaths of the final binaries to achieve this results. It is
> done the same way with nearly all of our packages.
> 
> There is a few way of doing this but the most reliable one is as follow :
> 
> Define the LD_OPTIONS env variable before building gcc and use it to add the
> correct runtime path.
> 
> for example a typical blastwave build would have at a minimum :
> 
> export LD_OPTIONS='-R/opt/csw/lib'
> 
> In this case the final shared libraries will contain runtime search paths to
> find stuff in /opt/csw/lib. Now there is a catch though if you want to build a
> multilib gcc for the gcc build you should use :
> 
> export LD_OPTIONS='-R/opt/csw/lib/$ISALIST'
> 
> In this case the libraries will be able to search for 64 or 32 bit libs
> accordingly.
> 
> Hope this help,
> 
> Jonathan Blanchard
> 
> 
Yes, thank you. That is helpful. How do you produce the $ISALIST? Is that
simply 
sparcv9 on a modern SPARC and amd64 on an Open Solaris system, or is it a list. 
If the latter, how do you every it.


drkirkby@hawk:~$ isalist
amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86

Do I need

xport LD_OPTIONS='-R/opt/csw/lib/amd64 -R opt/csw/lib/pentium_pro+mmx etc" ? I 
doubt it, but I'm not sure what you mean there.

Is it just this, or anything else I need to do? You say "typical blastwave
build 
would have at a minimum .." but I doubt you would consider gcc a "typical 
blastwave build" If there are further complications, can you let me know what 
they are.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[BlanchardJ at ieee dot org]

------- Comment #17 from BlanchardJ at ieee dot org  2010-01-15 12:37 -------

> Yes, thank you. That is helpful. How do you produce the $ISALIST? Is that
> simply 
> sparcv9 on a modern SPARC and amd64 on an Open Solaris system, or is it a list. 
> If the latter, how do you every it.
> 
> 
> drkirkby@hawk:~$ isalist
> amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86
> 
> Do I need
> 
> xport LD_OPTIONS='-R/opt/csw/lib/amd64 -R opt/csw/lib/pentium_pro+mmx etc" ? I 
> doubt it, but I'm not sure what you mean there.
> 
> Is it just this, or anything else I need to do? You say "typical blastwave
> build 
> would have at a minimum .." but I doubt you would consider gcc a "typical 
> blastwave build" If there are further complications, can you let me know what 
> they are.
> 
> Dave
> 

Hi,

It's just the string '$ISALIST' so it will appear as-is in the final run path.
The runtime linker will take care of expanding it correctly at runtime. So one
just export LD_OPTIONS as-is before building.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[david dot kirkby at onetel dot net]

------- Comment #18 from david dot kirkby at onetel dot net  2010-01-15 13:15 -------
Subject: Re:  gcc fails to build on Solaris x86 - it
 forgets the locations of libmpfr

BlanchardJ at ieee dot org wrote:
> ------- Comment #17 from BlanchardJ at ieee dot org  2010-01-15 12:37 -------
> 
>> Yes, thank you. That is helpful. How do you produce the $ISALIST? Is that
>> simply 
>> sparcv9 on a modern SPARC and amd64 on an Open Solaris system, or is it a list. 
>> If the latter, how do you every it.
>>
>>
>> drkirkby@hawk:~$ isalist
>> amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86
>>
>> Do I need
>>
>> xport LD_OPTIONS='-R/opt/csw/lib/amd64 -R opt/csw/lib/pentium_pro+mmx etc" ? I 
>> doubt it, but I'm not sure what you mean there.
>>
>> Is it just this, or anything else I need to do? You say "typical blastwave
>> build 
>> would have at a minimum .." but I doubt you would consider gcc a "typical 
>> blastwave build" If there are further complications, can you let me know what 
>> they are.
>>
>> Dave
>>
> 
> Hi,
> 
> It's just the string '$ISALIST' so it will appear as-is in the final run path.
> The runtime linker will take care of expanding it correctly at runtime. So one
> just export LD_OPTIONS as-is before building.
> 
> 

Thank you. That's very helpful. I really hate having to set LD_LIBRARY_PATH -
it 
is particularly an issue if you have multiple compilers. There's alyways the 
chance it gets set to the wrong compiler by mistake.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #19 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-01-28 05:16:22 UTC ---
dup of bug 42028.

*** This bug has been marked as a duplicate of bug 42028 ***