--- Comment #12 from ebotcazou at gcc dot gnu dot org 2009-06-28 06:22
---
FWIW, BOOT_LDFLAGS. that did not solve it either. I think I'll have a go with
'sed' and change /usr/local to somewhere else in the gcc-4.4.0.tar file.
Hopefully that will avoid the need for setting LD library
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-06-28 11:05
---
At least with BOOT_LDFLAGS the error is no longer that it cannot find the
libraries.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
--- Comment #14 from david dot kirkby at onetel dot net 2009-06-28 16:49
---
Created an attachment (id=18086)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18086action=view)
Top level config.log, with libraries in /usr/local/lib
This is the top level config.log. I'll post the
--- Comment #15 from david dot kirkby at onetel dot net 2009-06-28 16:52
---
Created an attachment (id=18087)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18087action=view)
sparc-sun-solaris2.10/libgcc/config.log with mpfr and gmp libraires in
/usr/local/lib.
As you will note,
--- Comment #16 from david dot kirkby at onetel dot net 2009-06-28 16:55
---
I thought my comments were going to appear before the files were posted, not
after it. Anyway, the libraries are in /usr/local/lib, and appear to work, as I
can compile and link against them.
kir...@t2:[~] $
--- Comment #17 from david dot kirkby at onetel dot net 2009-06-28 17:17
---
I just realised that:
LDFLAGS='-L/usr/local/lib -R/usr/local/lib'
BOOT_LDFLAGS='-L/usr/local/lib -R/usr/local/lib'
export LDFLAGS
export BOOT_LDFLAGS
was probably not the best way to do this. I'm not even
--- Comment #18 from david dot kirkby at onetel dot net 2009-06-28 19:30
---
I have solved this. The key was setting LD_OPTIONS
LD_OPTIONS='-L/usr/local/lib -R/usr/local/lib'
I suspect that is a Solaris Environment variable, which is useful to the Sun
linker I was using, but not to
--- Comment #1 from david dot kirkby at onetel dot net 2009-06-27 20:25
---
Created an attachment (id=18081)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18081action=view)
Top level config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
--- Comment #2 from david dot kirkby at onetel dot net 2009-06-27 20:29
---
Created an attachment (id=18082)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18082action=view)
sparc-sun-solaris2.10/libgcc/config.log
This is the file, which shows it can't find the library, a couple
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-27 20:35 ---
What is the LDFLAGS supposed to do? Is it supposed to adjust the run-path of
the built executables to find the mpfr/gmp libraries to not need
LD_LIBRARY_PATH
set?
Note that setting LDFLAGS maybe not what you want
--- Comment #4 from david dot kirkby at onetel dot net 2009-06-27 20:57
---
(In reply to comment #3)
What is the LDFLAGS supposed to do? Is it supposed to adjust the run-path of
the built executables to find the mpfr/gmp libraries to not need
LD_LIBRARY_PATH
set?
Note that
--- Comment #5 from david dot kirkby at onetel dot net 2009-06-27 21:00
---
(In reply to comment #3)
Note that setting LDFLAGS maybe not what you want (it affects stage1 only
AFAIK), you likely want to set BOOT_LDFLAGS.
Sorry, forget to comment on that.
I'll try that. I would
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-06-27 21:46 ---
LD_LIBRARY_PATH is for the runtime linker/loader so it is needed as you are
running programs which use shared libraries stored in a non standard place.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #7 from david dot kirkby at onetel dot net 2009-06-27 22:31
---
(In reply to comment #6)
LD_LIBRARY_PATH is for the runtime linker/loader so it is needed as you are
running programs which use shared libraries stored in a non standard place.
So is any user who uses the
--- Comment #8 from david dot kirkby at onetel dot net 2009-06-27 22:57
---
It looks as though we will have to agree to differ about the LD_LIBRARY_PATH
being the right way to do things.
But do you not agree that this probably should be found at an earlier stage in
the build
--- Comment #9 from pinskia at gcc dot gnu dot org 2009-06-27 23:39 ---
This is just like building any other program and running the result if you link
with a library stored somewhere else. /usr/local/lib not being standard is up
to your distro really, it is a standard location
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-06-27 23:39
---
It is semi hard to figure out early on really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
--- Comment #11 from david dot kirkby at onetel dot net 2009-06-28 03:51
---
(In reply to comment #3)
Note that setting LDFLAGS maybe not what you want (it affects stage1 only
AFAIK), you likely want to set BOOT_LDFLAGS.
FWIW, BOOT_LDFLAGS. that did not solve it either. I think
18 matches
Mail list logo
