[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr
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 ***
[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr
--- 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. drkir...@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
--- 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. drkir...@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
--- 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. drkir...@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
--- 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 (mockbu...@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
--- 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
--- 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
--- 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
--- 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 makes 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
--- 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
--- 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=500 --split-size=500; 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
--- 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=17522action=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
--- 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 (0x00329620) libc.so.6 = /lib64/libc.so.6 (0x003365a0) /lib64/ld-linux-x86-64.so.2 (0x00336560) 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
--- 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
--- 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=17524action=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: u...@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
--- 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
--- 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
--- 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
