This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: gcc 3 on solaris dependency problem with libgcc_s.so.1
- From: pkurpis at keck dot hawaii dot edu (Peter Kurpis)
- To: gcc-help at gcc dot gnu dot org
- Date: Wed, 22 May 2002 11:09:47 -1000 (HST)
- Subject: Re: gcc 3 on solaris dependency problem with libgcc_s.so.1
We had email problems this morning, so don't know whether this made
it out. Sorry if duplicate.
> From rgp@systame.com Wed May 22 04:35:14 2002
> Tried this configure:
> setenv LDFLAGS="-L/usr/local/lib -R/usr/local/lib"; ./configure
> --with-libraries=/usr/local/lib:/usr/local/ssl/lib:/usr/local/lib/sasl
> --enable-syslog
>
> Had to remove the --with-includes as it generated errors saying the path was
> already set once.
>
> Same results -- still can't find libgcc
>
> >
> > (3) If the build of postgres uses gcc or g++ to link, instead of ld (which
> > is likely), you should use -Wl,-R /usr/local/lib . That is, prepend
> > a -Wl, before the -R , for a command to pass to ld . Note that
> > the l is ell not numeric one.
> >
> Can you give me some guidance; I'm not very familiar with make and ld.
I think you're almost there. I did some experimenting (albeit with a GNU package,
as I don't have postgres here). So I'm satisfied that the GNU build is designed to
accept a LDFLAGS override from the environment.
Secondly, I am guessing that (3) above is true in the postgres build, as it almost
always is. Usually, executables built from C++ source are linked with g++, not ld.
The reason is that g++ is smarter about which startup code (e.g. crt0.o) and so on
has to be linked in, whereas ld usually has to be told explicitly.
As you have discovered, however, g++ does not provide a runtime link search path
for libstdc++.so, as one might expect (because it does on Solaris for the somewhat
analogous libc.so).
One thing, though, is that g++ (and gcc, for that matter) require all but a few linker
options to be passed with a "wrapper flag" (my naive term) -W,l which says to g++
to just pass this flag to the linker stage, and ignore it for preceding stages of
compilation. That is, where you might have
/usr/ccs/bin/ld ... -L/usr/local/lib -R/usr/local/lib ...
you would have to say
/usr/local/bin/g++ ... -L/usr/local/lib -Wl,-R/usr/local/lib ...
Note that the -L option is one of the few linker options not requiring the "wrapper
flag."
So I think the bottom line is to try
setenv LDFLAGS="-L/usr/local/lib -Wl,-R/usr/local/lib"; ./configure
--with-libraries=/usr/local/lib:/usr/local/ssl/lib:/usr/local/lib/sasl
--enable-syslog
with the only change being the prepended -Wl,-R (which has an "ell" not numeric one!)
I think if you look in your Makefile (or diff it against the last failed one) you'll
see the difference.
Good luck.
----- End Included Message -----