I am experiencing libgcc_s.so.1 open failed when trying to gmake
install php source.  I have Solaris 9 (sparc) with gcc-3.2 downloaded
from Sun website. I verified this libgcc_s.so.1 under
/opt/sfw/gcc-3.2/lib/
Any tips?

Here is the debug.log output
CONFIGURE: './configure' '--with-apxs=/usr/apache/bin/apxs'
'--enable-libgcc'  '--with-zlib' '--with-zlib-dir=/opt/local'
'--with-gd' '--with-jpeg-dir=/opt/local' '--with-png-dir=/opt/local'
'--with-zlib-dir=/opt/local' '--enable-rule=SHARED_CORE'
'--enable-shared=max'
CC: gcc
CFLAGS: -g -O2
CPPFLAGS: -D_POSIX_PTHREAD_SEMANTICS
CXX: 
CXXFLAGS: 
INCLUDES: -I$(top_builddir)/Zend -I/opt/local/include
LDFLAGS: -R/usr/ucblib -L/usr/ucblib
-R/opt/sfw/gcc-3.2/lib/gcc-lib/sparc-sun-solaris2.9/3.2
-L/opt/sfw/gcc-3.2/lib/gcc-lib/sparc-sun-solaris2.9/3.2 -R/opt/
local/lib -L/opt/local/lib
LIBS: -lpng -lz -ljpeg -lz -lresolv -lm -ldl -lnsl -lsocket -lgcc
DLIBS: 
SAPI: apache
PHP_RPATHS: /usr/ucblib
/opt/sfw/gcc-3.2/lib/gcc-lib/sparc-sun-solaris2.9/3.2 /opt/local/lib
uname -a: SunOS vmsun1 5.9 Generic sun4u sparc SUNW,Sun-Blade-100
gcc -o conftest -g -O2 -D_POSIX_PTHREAD_SEMANTICS -R/usr/ucblib
-L/usr/ucblib
-R/opt/sfw/gcc-3.2/lib/gcc-lib/sparc-sun-solaris2.9/3.2
-L/opt/sfw/gcc-3.2/lib/gcc-lib/sparc-sun-solaris2.9/3.2
-R/opt/local/lib -L/opt/local/lib conftest.c -lp
ng -lz -ljpeg -lz -lresolv -lm -ldl -lnsl -lsocket -lgcc 1>&5
ld.so.1: ./conftest: fatal: libgcc_s.so.1: open failed: No such file
or directory

Madhu Nair wrote:
> I am experiencing libgcc_s.so.1 open failed when trying to gmake
> install php source.  I have Solaris 9 (sparc) with gcc-3.2 downloaded
> from Sun website. I verified this libgcc_s.so.1 under
> /opt/sfw/gcc-3.2/lib/
> Any tips?

   I just compiled php 4.3.4 on solaris 9 (sparc) using gcc 3.2 from 
sunfreeware.com and there was no problems.  Maybe give that a try?

   /Marcin

I found the solution and a special thanks to Brian C. Hill ( bchill@bch.net) 
I added the path to this gcc library using crle command
# crle -u -l /opt/sfw/gcc-3.2/lib /opt/sfw/lib
Here is the output of crle
# crle

Configuration file [3]: /var/ld/ld.config  
  Default Library Path (ELF):   /opt/sfw/gcc-3.2/lib:/usr/lib:/opt/sfw/lib
  Trusted Directories (ELF):    /usr/lib/secure  (system default)

Command line:
  crle -c /var/ld/ld.config -l /opt/sfw/gcc-3.2/lib:/usr/lib:/opt/sfw/lib


Here /opt/sfw/gcc-3.2/lib is the path to the gcc 3.2 lib
and /opt/sfw/lib is the path to other open source stuff

After this gmake install went smooth and php is working with apache

Madhu

In article <ba154189.0311241654.3b94181@posting.google.com>,
Madhu Nair <eloormadhu@hotmail.com> wrote:
>from Sun website. I verified this libgcc_s.so.1 under
>/opt/sfw/gcc-3.2/lib/

env LDFLAGS="-R/opt/sfw/gcc-3.2/lib" ./configure --blah

John
groenveld@acm.org

On Tue, 25 Nov 2003 14:20:01 -0800, Madhu Nair wrote:

> Command line:
>   crle -c /var/ld/ld.config -l /opt/sfw/gcc-3.2/lib:/usr/lib:/opt/sfw/lib
> 

Dont. Mess. With. crle

This is similar to "dont mess with LD_LIBRARY_PATH".

if you cant compile programs that work right, let others do it for you.
But dont mess up all potential future programs, by tweaking your entire
system with crle.

In article <ba154189.0311251420.15dd34f7@posting.google.com>,
Madhu Nair <eloormadhu@hotmail.com> did thusly spew forth: 
>I found the solution and a special thanks to Brian C. Hill ( bchill@bch.net) 
>I added the path to this gcc library using crle command
># crle -u -l /opt/sfw/gcc-3.2/lib /opt/sfw/lib
>Here is the output of crle

Rather than screw around with crle and potentially hoark other binaries
on your system, use LD_RUN_PATH at compile time to correctly configure the
binaries and libraries that you are producing to look in the correct places
for their dynamic links.

It would really suck if you were to cause something that required the stock
Sun libraries to link against different and, possibly, incompatible libraries.
Using LD_RUN_PATH at compile time rather than crle after compilation will
prevent such breakage.

-tom

On Fri, 02 Jan 2004 19:37:26 -0600 Thomas H Jones II <ferric@xanthia.com> wrote:
> In article <ba154189.0311251420.15dd34f7@posting.google.com>,
> Madhu Nair <eloormadhu@hotmail.com> did thusly spew forth: 
>>I found the solution and a special thanks to Brian C. Hill ( bchill@bch.net) 
>>I added the path to this gcc library using crle command
>># crle -u -l /opt/sfw/gcc-3.2/lib /opt/sfw/lib
>>Here is the output of crle
>
> Rather than screw around with crle and potentially hoark other binaries
> on your system, use LD_RUN_PATH at compile time to correctly configure the
> binaries and libraries that you are producing to look in the correct places
> for their dynamic links.
>
> It would really suck if you were to cause something that required the stock
> Sun libraries to link against different and, possibly, incompatible libraries.

That shouldn't happen thanks to library versioning.

/fc

In article <m33cax7btl.fsf@magma.savecore.net>,
Frank Cusack  <fcusack@fcusack.com> did thusly spew forth: 
>On Fri, 02 Jan 2004 19:37:26 -0600 Thomas H Jones II <ferric@xanthia.com> wrote:
>> It would really suck if you were to cause something that required the stock
>> Sun libraries to link against different and, possibly, incompatible libraries.
>
>That shouldn't happen thanks to library versioning.

I will use OpenSSL as an example. Most programs will attempt to link against
0.9.x. However, if you happen to modify your library search path via crle
and one of your binaries is expecting to link against 0.9.7b but you've
put a library path for 0.9.7c first in your library search path, you may
find that things that -were- working previously no longer do.

Or, lets try a more general example. Say your OS came with a library that
had certain features compiled into it. You then change your library path
via crle. You may have subsequently installed another copy of that same
library version, but one that was compiled with different features. If
you change things via crle, versioning won't protect you from differences
between the two copies of the same library version.

When people say not to use crle or a system-wide LD_LIBRARY_PATH or
similar construct, it's because we have seen the negative effects of
making system-level changes to solve what should be a very localized issue.

Always remember, it's typically best to use a scalpel rather than a sledge-
hammer when you are trying to solve a specific problem.

-tom

On Sat, 03 Jan 2004 04:02:18 -0600 Thomas H Jones II <ferric@xanthia.com> wrote:
> In article <m33cax7btl.fsf@magma.savecore.net>,
> Frank Cusack  <fcusack@fcusack.com> did thusly spew forth: 
>>On Fri, 02 Jan 2004 19:37:26 -0600 Thomas H Jones II <ferric@xanthia.com> wrote:
>>> It would really suck if you were to cause something that required the stock
>>> Sun libraries to link against different and, possibly, incompatible libraries.
>>
>>That shouldn't happen thanks to library versioning.
>
> I will use OpenSSL as an example.

Ouch, bad example. :)

[comments about OpenSSL release processes elided]

/fc

In article <x4GdndzcOYK3DmuiRVn-jg@speakeasy.net>, Thomas H Jones II wrote:
> In article <m33cax7btl.fsf@magma.savecore.net>,
> Frank Cusack  <fcusack@fcusack.com> did thusly spew forth: 
>>On Fri, 02 Jan 2004 19:37:26 -0600 Thomas H Jones II <ferric@xanthia.com> wrote:
>>> It would really suck if you were to cause something that required the stock
>>> Sun libraries to link against different and, possibly, incompatible libraries.
>>
>>That shouldn't happen thanks to library versioning.
> 
> I will use OpenSSL as an example. Most programs will attempt to link against
> ...
> Always remember, it's typically best to use a scalpel rather than a sledge-
> hammer when you are trying to solve a specific problem.

I think your point is correct, but you need a better metaphor.  One would
not use a scalpel for the specific problem of pounding a stake into the
ground, for example.

-- 
Jim Cochrane; jtc@dimensional.com
[When responding by email, include the term non-spam in the subject line to
get through my spam filter.]

On Mon, 24 Nov 2003 16:54:38 -0800, Madhu Nair wrote:

> I am experiencing libgcc_s.so.1 open failed when trying to gmake
> install php source.  I have Solaris 9 (sparc) with gcc-3.2 downloaded
> from Sun website. I verified this libgcc_s.so.1 under
> /opt/sfw/gcc-3.2/lib/
> Any tips?
> 


I suggest you save yourself a lot of hassle, now, and in the future when
you want to add more options, by using the blastwave.org binaries of php
If you needed oracle support, it would be another story, but judging by
your compiler flags, you dont.



> Here is the debug.log output
> CONFIGURE: './configure' '--with-apxs=/usr/apache/bin/apxs'
> '--enable-libgcc'  '--with-zlib' '--with-zlib-dir=/opt/local'
> '--with-gd' '--with-jpeg-dir=/opt/local' '--with-png-dir=/opt/local'
> '--with-zlib-dir=/opt/local' '--enable-rule=SHARED_CORE'
> '--enable-shared=max'


PS: the blastwave php is compiled to support access to both mysql, and
postgres

In article <pan.2004.01.13.08.33.22.756119@bolthole.com>,
Phil Brown  <spam@bolthole.com> did thusly spew forth: 
>On Mon, 24 Nov 2003 16:54:38 -0800, Madhu Nair wrote:
>
>> I am experiencing libgcc_s.so.1 open failed when trying to gmake
>> install php source.  I have Solaris 9 (sparc) with gcc-3.2 downloaded
>> from Sun website. I verified this libgcc_s.so.1 under
>> /opt/sfw/gcc-3.2/lib/
>> Any tips?
>> 
>
>
>I suggest you save yourself a lot of hassle, now, and in the future when
>you want to add more options, by using the blastwave.org binaries of php
>If you needed oracle support, it would be another story, but judging by
>your compiler flags, you dont.

Not the most helpful approach. Assuming he wants to use a non-static
libphp, he will need to download any library dependencies that the
blastwave files have. Whereas, it's fairly apparent that he already
seems to have a number of libraries on his system, but in locations
that the blastwave php modules might not check.

In other words, there's more reasons than just "oracle support" for
wanting to compile your own software.

>> Here is the debug.log output
>> CONFIGURE: './configure' '--with-apxs=/usr/apache/bin/apxs'
>> '--enable-libgcc'  '--with-zlib' '--with-zlib-dir=/opt/local'
>> '--with-gd' '--with-jpeg-dir=/opt/local' '--with-png-dir=/opt/local'
>> '--with-zlib-dir=/opt/local' '--enable-rule=SHARED_CORE'
>> '--enable-shared=max'

-tom