On Mon, 29 Jun 2009, Dr. David Kirkby wrote:
Marc Glisse wrote:
On Mon, 29 Jun 2009, Dr. David Kirkby wrote:
--with-libiconv-prefix=/usr/lib/iconv
What's that for? Either you use GNU libiconv or you use libc,
/usr/lib/iconv is just some private libc data.
Is the GNU one part of the compiler suite?
Not sure what you mean, but I think the answer is: no.
I noticed on one machine there was
a version of libiconv in /usr/local/lib but I was keen to use the system one,
rather than a local copy.
If you pass a --with-libiconv option, you will use the gnu one. To not use
it when it is installed in /usr/local is a bit painful, but you could try
to symlink the system /usr/include/iconv.h in the gcc source tree so it is
more likely to be found before the one in /usr/local/include (not sure
that will be enough though, as configure may not look for it there).
I noticed on one machine that c++ was linked against a local copy:
$ ldd c++
libiconv.so.2 => /usr/local/lib/libiconv.so.2
libc.so.1 => /lib/libc.so.1
libgcc_s.so.1 =>
/export/home/drkirkby/install-gcc-4.4.0-Sun-as-ld/lib/libgcc_s.so.1
libm.so.2 => /lib/libm.so.2
/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1
But on another machine
kirkby@t2:[/usr/local/gcc-4.4.0-sun-linker/bin] $ ldd c++
libc.so.1 => /lib/libc.so.1
It may be using the iconv implementation in libc (or not using iconv at
all).
libm.so.2 => /lib/libm.so.2
/platform/SUNW,T5240/lib/libc_psr.so.1
It just so happens that I'm having some problems compiling code on the latter
machine, with no link to libiconv, but not on the machine that does link to a
local copy. (I expect this is a red-herring, but it was a difference I
noticed).
By the way, I believe you forgot --disable-nls in your configure options,
to try and simplify things.
You can use the specs file to change the flags passed by gcc to the linker.
gcc -dumpspecs shows the default values and truss will show you where gcc
expects to find a specs file overriding these values. You could add some
-R/my/path in there (depending on m64/m32), which I think is what Sun
currently does in Solaris, although it means LD_RUN_PATH will be ignored (I
think Sun's compiler actually parses this variable to simulate its effect,
but that's too much work for gcc). You could instead add -c my.config to
make the program use an alternate ld.config (created with crle) which
hardcodes a different standard search path for libraries.
Where would I add the -c ?? to crle?
No. You use crle (read the man page) to create a config file with your
favorite search path. Then you pass the linker (ld) the option -c
myconfigfile. If you try: gcc -dumpspecs, you see what options gcc passes
to the linker. For instance on this linux computer:
*link_command:
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S: %(linker) %l %{pie:-pie} %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} %{r} %{s} %{t} %{u*} %{x} %{z} %{Z} %{!A:%{!nostdlib:%{!nostartfiles:%S}}} %{static:} %{L*} %(mfwrap) %(link_libgcc) %o %{fopenmp|ftree-parallelize-loops=*:%:include(libgomp.spec)%(link_gomp)} %(mflib) %{fprofile-arcs|fprofile-generate|coverage:-lgcov} %{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}} %{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}}}}}
You could add at the end of it:
%{!static:%{!m64:-R/path/lib}%{m64:-R/path/lib/sparcv9}}
Or:
%{!static:%{!m64:-c /path/myconfig}%{m64:-c /path/myconfig64}}
Or you may want to put that elsewhere (in the *libgcc: line?).
Then you put those modified 2 lines in a file called specs at an
appropriate place (use "truss -f gcc -E empty.c 2>&1 |grep specs"
(untested) or something like that to determine where that place is).
I haven't used a config file in years, so I am not completely sure how
they work anymore. In particular, they may be ignored by shared libraries
and only used by executables.
Although I do have root access, I'd like to build a solution which does not
require the user to have root access.
I know, I never suggested that.
--
Marc Glisse