This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 -----


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]