Re: gcc 3 on solaris dependency problem with libgcc_s.so.1

Re: gcc 3 on solaris dependency problem with libgcc_s.so.1

[Peter Kurpis]

Given what you say, I don't think this has anything to do with the gcc 
version.  I often find myself in the same position of avoiding use of
LD_LIBRARY_PATH, etcetera.

Here's a few tips:

(1) Depending on your platform, and whether you're using the native ld or
    GNU ld, you might have to use  -rpath  instead of  -R .  (I'm not sure
    GNU ld always understands -R , if that's what you're using.)

(2) I think you mean  -R /usr/local/lib  instead of  -R /usr/local/bin .
                                    ^^^

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

(4) I am not sure how to pass overrides to configure.  Perhaps setting 
    LDFLAGS in the environtment, as you do, does the trick.  But check
    the makefiles that are produced.  Also, check that your build actually
    links using these additions.

(5) Sometimes I just get ugly and modify makefiles after the configure
    step, if I can't get it to work cleanly.

Good luck.

> Trying to upgrade to PostgreSQL 7.2.1 and building with gcc 3.0.3. I'm
> trying to find a way to avoid needing LD_LIBRARY_PATH (which points to
> libgcc_s.so.1) to be read by cron, cgi, and php scripts. It's a real pain to
> get environment variables to work in cgi scripts.
> 
> Was told to try setting LDFLAGS but that didn't work. Here's my latest
> config command:
> 
> setenv LDFLAGS="-L/usr/local/lib -R/usr/local/bin"; ./configure
> --with-includes=/usr/local/include
> --with-libraries=/usr/local/lib:/usr/local/ssl/lib:/usr/local/lib/sasl
> --enable-syslog
> 
> 
> Was also told to go back to 2.95 if I couldn't resolve it.
> 
> Can anyone help? Will 3.1 be any better?

Re: gcc 3 on solaris dependency problem with libgcc_s.so.1

[Randall Perry]

> Given what you say, I don't think this has anything to do with the gcc
> version.  I often find myself in the same position of avoiding use of
> LD_LIBRARY_PATH, etcetera.
> 
> Here's a few tips:
> 
> (1) Depending on your platform, and whether you're using the native ld or
>   GNU ld, you might have to use  -rpath  instead of  -R .  (I'm not sure
>   GNU ld always understands -R , if that's what you're using.)
> 
Just installed gcc 3.1 Solaris pkg. It uses Solaris ld.


> (2) I think you mean  -R /usr/local/lib  instead of  -R /usr/local/bin .
>            
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.
> 
> (4) I am not sure how to pass overrides to configure.  Perhaps setting
>   LDFLAGS in the environtment, as you do, does the trick.  But check
>   the makefiles that are produced.  Also, check that your build actually
>   links using these additions.
> 

Can you give me some guidance; I'm not very familiar with make and ld.
Though, ironically, one of the first things I did on computers was learn C
using gcc on an Atari ST.

> (5) Sometimes I just get ugly and modify makefiles after the configure
>   step, if I can't get it to work cleanly.
> 
> Good luck.
> 
>> Trying to upgrade to PostgreSQL 7.2.1 and building with gcc 3.0.3. I'm
>> trying to find a way to avoid needing LD_LIBRARY_PATH (which points to
>> libgcc_s.so.1) to be read by cron, cgi, and php scripts. It's a real pain to
>> get environment variables to work in cgi scripts.
>> 
>> Was told to try setting LDFLAGS but that didn't work. Here's my latest
>> config command:
>> 
>> setenv LDFLAGS="-L/usr/local/lib -R/usr/local/bin"; ./configure
>> --with-includes=/usr/local/include
>> --with-libraries=/usr/local/lib:/usr/local/ssl/lib:/usr/local/lib/sasl
>> --enable-syslog
>> 
>> 
>> Was also told to go back to 2.95 if I couldn't resolve it.
>> 
>> Can anyone help? Will 3.1 be any better?

-- 
Randy Perry
sysTame
Mac Consulting/Sales

phn                 772.589.6449
mobile email        help@systame.com

Re: gcc 3 on solaris dependency problem with libgcc_s.so.1

[Peter Kurpis]

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

Re: gcc 3 on solaris dependency problem with libgcc_s.so.1

[Peter Kurpis]

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

gcc 3 on solaris dependency problem with libgcc_s.so.1

[Randall Perry]

Trying to upgrade to PostgreSQL 7.2.1 and building with gcc 3.0.3. I'm
trying to find a way to avoid needing LD_LIBRARY_PATH (which points to
libgcc_s.so.1) to be read by cron, cgi, and php scripts. It's a real pain to
get environment variables to work in cgi scripts.

Was told to try setting LDFLAGS but that didn't work. Here's my latest
config command:

setenv LDFLAGS="-L/usr/local/lib -R/usr/local/bin"; ./configure
--with-includes=/usr/local/include
--with-libraries=/usr/local/lib:/usr/local/ssl/lib:/usr/local/lib/sasl
--enable-syslog


Was also told to go back to 2.95 if I couldn't resolve it.

Can anyone help? Will 3.1 be any better?


-- 
Randy Perry
sysTame
Mac Consulting/Sales

phn                 772.589.6449
mobile email        help@systame.com