Thread: 64-bit Compile Failure on Solaris 10 with OpenSSL
I've battled this for a while. I'm finally breaking down and asking for help. If you're answer to this is "why 64-bit" then don't answer. You wouldn't understand. Same if you say "why don't you use packages." Here is my scenerio: - Sun 420R x450Mhz UltraSPARC-II / 4GB RAM - Solaris 10 05/08 - OpenSSL 0.9.8h - PostgreSQL 8.3.3 - GCC 3.4.6 - GNU Make 3.81 OpenSSL configure line (compiles clean and works perfectly): ./Configure shared solaris64-sparcv9-gcc -R/usr/sfw/lib/sparcv9 -R/usr/local/ssl/lib PostgreSQL configure line: ./configure --with-openssl --without-readline CFLAGS="-m64 -mcpu=ultrasparc" CPPFLAGS="-I/usr/local/ssl/include" LDFLAGS="-L/usr/local/ssl/lib -R/usr/local/ssl/lib -R/usr/sfw/lib/sparcv9" If I don't include OpenSSL support, all is fine. This is the error I get during configure using the above flags: checking checking blah blah <snipped>.... checking test program... failed configure: error: Could not execute a simple test program. This may be a problem related to locating shared libraries. Check the file 'config.log' for the exact reason. The most glaring error in config.log shows this: configure:5635: gcc -o conftest -m64 -mcpu=ultrasparc -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labe ls -fno-strict-aliasing -fwrapv -I/usr/local/ssl/include -L/usr/local/ssl/lib -R/usr/local/ssl/lib -R/usr/sfw/lib/sparcv9 conftest.c -lutil -lm >&5 ld: fatal: library -lutil: not found ld: fatal: File processing errors. No output written to conftest collect2: ld returned 1 exit status configure:5641: $? = 1 configure: failed program was: | /* confdefs.h. */ Now, if I recall correctly, lutil is part of GLIBC - a Linux-only dev package. Why would it be using this on Solaris? Am I missing the real error or does this have something to do with the overall failure to configure (thus, compile)? Thanks everyone! Randy PS I put the entire config.log here for analysis: http://www.procyonlabs.com/temp/config.log
"Randal T. Rioux" <randy@procyonlabs.com> writes:
> checking checking blah blah <snipped>....
> checking test program... failed
> configure: error:
> Could not execute a simple test program. This may be a problem
> related to locating shared libraries. Check the file 'config.log'
> for the exact reason.
> The most glaring error in config.log shows this:
You're looking at the wrong thing --- library-not-found errors are
completely expected in config.log, because it has to find out what
libraries are present. The actual failure is down here:
configure:19839: checking test program
configure:19854: gcc -o conftest -m64 -mcpu=ultrasparc -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-after-statement-Wendif-labels -fno-strict-aliasing -fwrapv -I/usr/local/ssl/include -L/usr/local/ssl/lib
-R/usr/local/ssl/lib-R/usr/sfw/lib/sparcv9 conftest.c -lssl -lcrypto -lz -lrt -lsocket -lm >&5
configure:19857: $? = 0
configure:19859: ./conftest
ld.so.1: conftest: fatal: libgcc_s.so.1: open failed: No such file or directory
./configure: line 19860: 20583 Killed ./conftest$ac_exeext
configure:19862: $? = 137
configure: program exited with status 137
Since you say this doesn't happen when SSL support isn't requested,
I suppose that the problem has to do with libssl.so attempting to
reference libgcc_s.so. Beyond that, hard to say, but I bet there
is an rpath problem at the bottom of it.
regards, tom lane
On Sat, September 6, 2008 7:05 pm, Tom Lane wrote: > "Randal T. Rioux" <randy@procyonlabs.com> writes: >> checking checking blah blah <snipped>.... checking test program... >> failed configure: error: Could not execute a simple test program. This >> may be a problem related to locating shared libraries. Check the file >> 'config.log' for the exact reason. > >> The most glaring error in config.log shows this: > > You're looking at the wrong thing --- library-not-found errors are > completely expected in config.log, because it has to find out what > libraries are present. The actual failure is down here: > > configure:19839: checking test program configure:19854: gcc -o conftest > -m64 -mcpu=ultrasparc -Wall -Wmissing-prototypes -Wpointer-arith -Winline > -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing > -fwrapv -I/usr/local/ssl/include -L/usr/local/ssl/lib > -R/usr/local/ssl/lib -R/usr/sfw/lib/sparcv9 conftest.c -lssl -lcrypto > -lz -lrt -lsocket -lm >> &5 > configure:19857: $? = 0 configure:19859: ./conftest ld.so.1: conftest: > fatal: libgcc_s.so.1: open failed: No such file or directory ./configure: > line 19860: 20583 Killed ./conftest$ac_exeext configure:19862: $? = 137 > configure: program exited with status 137 Nice catch - but I can't tell which file open failed? > Since you say this doesn't happen when SSL support isn't requested, I > suppose that the problem has to do with libssl.so attempting to reference > libgcc_s.so. Beyond that, hard to say, but I bet there is an rpath > problem at the bottom of it. Could it be trying to hit the stock OpenSSL libs installed with Solaris, instead of my 64-bit version? I thought the LDFLAGS would have prevented that. Thanks! Randy
"Randal T. Rioux" <randy@procyonlabs.com> writes:
> On Sat, September 6, 2008 7:05 pm, Tom Lane wrote:
>> configure:19857: $? = 0 configure:19859: ./conftest ld.so.1: conftest:
>> fatal: libgcc_s.so.1: open failed: No such file or directory ./configure:
>> line 19860: 20583 Killed ./conftest$ac_exeext configure:19862: $? = 137
>> configure: program exited with status 137
> Nice catch - but I can't tell which file open failed?
It looks pretty clear to me that libgcc_s.so.1 was the file that
couldn't be found. One question is exactly where that lives on your
machine. Presumably it exists someplace, else the build of OpenSSL
should've failed.
>> Since you say this doesn't happen when SSL support isn't requested, I
>> suppose that the problem has to do with libssl.so attempting to reference
>> libgcc_s.so. Beyond that, hard to say, but I bet there is an rpath
>> problem at the bottom of it.
> Could it be trying to hit the stock OpenSSL libs installed with Solaris,
> instead of my 64-bit version? I thought the LDFLAGS would have prevented
> that.
I'm not a Solaris user, but I'd be kinda surprised if Solaris' own
libraries were built with gcc --- Sun has their own compiler no?
I think it's finding your custom libssl just fine but the subsequent
requirement of libgcc_s is somehow not working. ldd or local equivalent
might help debug this.
regards, tom lane
On Sat, September 6, 2008 8:21 pm, Tom Lane wrote:
> "Randal T. Rioux" <randy@procyonlabs.com> writes:
>> On Sat, September 6, 2008 7:05 pm, Tom Lane wrote:
>>> configure:19857: $? = 0 configure:19859: ./conftest ld.so.1:
>>> conftest: fatal: libgcc_s.so.1: open failed: No such file or
>>> directory ./configure: line 19860: 20583 Killed ./conftest$ac_exeext
configure:19862: $? = 137 configure: program exited with status 137
>
>> Nice catch - but I can't tell which file open failed?
>
> It looks pretty clear to me that libgcc_s.so.1 was the file that
couldn't
> be found. One question is exactly where that lives on your machine.
Presumably it exists someplace, else the build of OpenSSL should've
failed.
That's what I thought - just dismissed it because I know it is there:
sh-3.00# find / -name libgcc_s.so.1
/usr/local/lib/libgcc_s.so.1
/usr/local/lib/sparcv9/libgcc_s.so.1
>>> Since you say this doesn't happen when SSL support isn't requested, I
>>> suppose that the problem has to do with libssl.so attempting to
>>> reference libgcc_s.so. Beyond that, hard to say, but I bet there is
an rpath problem at the bottom of it.
>
>> Could it be trying to hit the stock OpenSSL libs installed with
Solaris, instead of my 64-bit version? I thought the LDFLAGS would have
prevented that.
>
> I'm not a Solaris user, but I'd be kinda surprised if Solaris' own
libraries were built with gcc --- Sun has their own compiler no? I think
it's finding your custom libssl just fine but the subsequent requirement
of libgcc_s is somehow not working. ldd or local equivalent might help
debug this.
bash-3.00# ldd /usr/local/lib/sparcv9/libgcc_s.so.1
libc.so.1 => /lib/64/libc.so.1
libm.so.2 => /lib/64/libm.so.2
/platform/SUNW,Ultra-80/lib/sparcv9/libc_psr.so.1
This is baffling me. Everything seems in place - but something is wrong.
What about including OpenSSL support could be doing this?
I just compiled Apache 2.2.9 with SSL and it went fine:
bash-3.00# file httpd
httpd: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically
linked, not stripped, no debugging information available
Thanks,
Randy
PS Your mail server bounced my message... called me a spammer! :-)
"Randal T. Rioux" <randy@procyonlabs.com> writes:
> On Sat, September 6, 2008 8:21 pm, Tom Lane wrote:
> ldd or local equivalent might help debug this.
> bash-3.00# ldd /usr/local/lib/sparcv9/libgcc_s.so.1
> libc.so.1 => /lib/64/libc.so.1
> libm.so.2 => /lib/64/libm.so.2
> /platform/SUNW,Ultra-80/lib/sparcv9/libc_psr.so.1
How about ldd on the libssl.so you're using?
regards, tom lane
On Sun, September 7, 2008 12:47 am, Tom Lane wrote:
> "Randal T. Rioux" <randy@procyonlabs.com> writes:
>> On Sat, September 6, 2008 8:21 pm, Tom Lane wrote:
>> ldd or local equivalent might help debug this.
>
>> bash-3.00# ldd /usr/local/lib/sparcv9/libgcc_s.so.1
>> libc.so.1 => /lib/64/libc.so.1
>> libm.so.2 => /lib/64/libm.so.2
>> /platform/SUNW,Ultra-80/lib/sparcv9/libc_psr.so.1
>
> How about ldd on the libssl.so you're using?
We're getting closer...
bash-3.00# ldd /usr/local/ssl/lib/libssl.so
libcrypto.so.0.9.8 => /usr/local/ssl/lib/libcrypto.so.0.9.8
libsocket.so.1 => /lib/64/libsocket.so.1
libnsl.so.1 => /lib/64/libnsl.so.1
libdl.so.1 => /lib/64/libdl.so.1
libgcc_s.so.1 => (file not found)
libgcc_s.so.1 => (file not found)
libc.so.1 => /lib/64/libc.so.1
libmp.so.2 => /lib/64/libmp.so.2
libmd.so.1 => /lib/64/libmd.so.1
libscf.so.1 => /lib/64/libscf.so.1
libdoor.so.1 => /lib/64/libdoor.so.1
libuutil.so.1 => /lib/64/libuutil.so.1
libgen.so.1 => /lib/64/libgen.so.1
libm.so.2 => /lib/64/libm.so.2
/platform/SUNW,Ultra-80/lib/sparcv9/libc_psr.so.1
/platform/SUNW,Ultra-80/lib/sparcv9/libmd_psr.so.1
Now why would libssl.so not be linked to libgcc_s.so.1? Why would
PostgreSQL care and not Apache?
Thanks so much for helping me out with this.
Randy
"Randal T. Rioux" <randy@procyonlabs.com> writes:
> bash-3.00# ldd /usr/local/ssl/lib/libssl.so
...
> libgcc_s.so.1 => (file not found)
Smoke, meet gun ...
> Now why would libssl.so not be linked to libgcc_s.so.1? Why would
> PostgreSQL care and not Apache?
Well, it is "linked", but the question is whether the dynamic linker
can find it. Different systems do this in different ways and I'm not
real familiar with how Solaris does it. The ideal thing to my mind is
to embed a linker search path in libssl.so so that its dependencies can
be found reliably, but I am not sure whether or how Solaris can do that.
It may be that the reason Apache works is that it sets LD_LIBRARY_PATH
or LD_RUN_PATH or some such environment variable that the dynamic linker
pays attention to. I can't say that I find that a reliable or secure
way to fix it, though.
regards, tom lane
On Mon, September 8, 2008 12:06 am, Tom Lane wrote: > "Randal T. Rioux" <randy@procyonlabs.com> writes: >> bash-3.00# ldd /usr/local/ssl/lib/libssl.so > ... >> libgcc_s.so.1 => (file not found) > > Smoke, meet gun ... > >> Now why would libssl.so not be linked to libgcc_s.so.1? Why would >> PostgreSQL care and not Apache? > > Well, it is "linked", but the question is whether the dynamic linker > can find it. Different systems do this in different ways and I'm not > real familiar with how Solaris does it. The ideal thing to my mind is > to embed a linker search path in libssl.so so that its dependencies can > be found reliably, but I am not sure whether or how Solaris can do that. > > It may be that the reason Apache works is that it sets LD_LIBRARY_PATH > or LD_RUN_PATH or some such environment variable that the dynamic linker > pays attention to. I can't say that I find that a reliable or secure > way to fix it, though. Well, that would explain this: -bash-3.00$ /usr/local/ssl/bin/openssl ld.so.1: openssl: fatal: libgcc_s.so.1: open failed: No such file or directory Killed Apache compiled with it, but yes - I looked through the scripts and configure logs and the paths were set by it correctly. I will mess with it more tonight and report my findings. Again, thanks for listening to me think out loud :-) Randy
On Sat, 6 Sep 2008, Randal T. Rioux wrote: > On Sat, September 6, 2008 8:21 pm, Tom Lane wrote: >> I'm not a Solaris user, but I'd be kinda surprised if Solaris' own > libraries were built with gcc --- Sun has their own compiler no? They released the instructions for how they were building their official PostgreSQL packages using their Sun Studio compiler at one point at http://wikis.sun.com/display/DBonSolaris/BuildingPostgreSQL > bash-3.00# ldd /usr/local/lib/sparcv9/libgcc_s.so.1 I note that they explicitly include a few directories using --with-libs in that example. May you need to add /usr/local/lib/sparcv9 similarly? There's also some LD_OPTIONS magic you may need. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Tom Lane napsal(a): > > I'm not a Solaris user I can sent you a installation media ;-), if you want. > , but I'd be kinda surprised if Solaris' own > libraries were built with gcc --- Sun has their own compiler no? Yes, sun studio. It is not installed by default, but it is possible to download it from http://developers.sun.com/sunstudio/downloads/. It is highly recommended to use sun studio compiler on SPARC. GCC is slower (~30%) and generates slower and sometimes buggy code on SPARC. Solaris 10 is compiled with Sun Studio 10, however integrated PostgreSQL is compiled with Sun Studio 11. Only gcc is compiled with gcc :-). Zdenek
Randal T. Rioux napsal(a): > I've battled this for a while. I'm finally breaking down and asking for help. > > If you're answer to this is "why 64-bit" then don't answer. You wouldn't > understand. Same if you say "why don't you use packages." > > Here is my scenerio: > > - Sun 420R x450Mhz UltraSPARC-II / 4GB RAM > - Solaris 10 05/08 > - OpenSSL 0.9.8h > - PostgreSQL 8.3.3 > - GCC 3.4.6 > - GNU Make 3.81 Three questions (yeah, you forbided ask, but ...) 1) Why 64 64bit code on SPARC is slower, because SPARC uses 4byte instructions and processing 64bit data needs more instructions. It is good only if you need more then 4GB share memory. When you use sunstudio compiler with best optimization 64bit application has 1%-5% performance degradation. 2) Why you don't use package You can use Solaris'es packages, which are integrated and optimized for Solaris. 3) Why you don't use build-in libssl? Integrated libssl is not only copy of original open ssl. It has lot of improvements and it uses crypto hardware accelerator if you have it (for example Niagara 2). See more: http://blogs.sun.com/janp/ http://blogs.sun.com/janp/entry/on_openssl_versions_in_solaris Zdenek
On Tue, September 9, 2008 5:25 am, Zdenek Kotala wrote: > Randal T. Rioux napsal(a): >> I've battled this for a while. I'm finally breaking down and asking for >> help. >> >> If you're answer to this is "why 64-bit" then don't answer. You wouldn't >> understand. Same if you say "why don't you use packages." >> >> Here is my scenerio: >> >> - Sun 420R x450Mhz UltraSPARC-II / 4GB RAM >> - Solaris 10 05/08 >> - OpenSSL 0.9.8h >> - PostgreSQL 8.3.3 >> - GCC 3.4.6 >> - GNU Make 3.81 > > Three questions (yeah, you forbided ask, but ...) grumble grumble grumble... > 1) Why 64 > > 64bit code on SPARC is slower, because SPARC uses 4byte instructions and > processing 64bit data needs more instructions. It is good only if you > need more then 4GB share memory. When you use sunstudio compiler with > best optimization 64bit application has 1%-5% performance degradation. A. Many databases use more than 4GB share memory. B. Re: SunStudio - that's why I'm using GCC. > 2) Why you don't use package > > You can use Solaris'es packages, which are integrated and optimized for > Solaris. Which are bloated with stuff I don't need and missing stuff I do. Not to mention terribly outdated. > 3) Why you don't use build-in libssl? > > Integrated libssl is not only copy of original open ssl. It has lot of > improvements and it uses crypto hardware accelerator if you have it (for > example Niagara 2). But it is 32-bit. Thanks, Randy
On Mon, September 8, 2008 9:38 am, Randal T. Rioux wrote: > On Mon, September 8, 2008 12:06 am, Tom Lane wrote: >> "Randal T. Rioux" <randy@procyonlabs.com> writes: >>> bash-3.00# ldd /usr/local/ssl/lib/libssl.so >> ... >>> libgcc_s.so.1 => (file not found) >> >> Smoke, meet gun ... >> >>> Now why would libssl.so not be linked to libgcc_s.so.1? Why would >>> PostgreSQL care and not Apache? >> >> Well, it is "linked", but the question is whether the dynamic linker >> can find it. Different systems do this in different ways and I'm not >> real familiar with how Solaris does it. The ideal thing to my mind is >> to embed a linker search path in libssl.so so that its dependencies can >> be found reliably, but I am not sure whether or how Solaris can do >> that. >> >> It may be that the reason Apache works is that it sets LD_LIBRARY_PATH >> or LD_RUN_PATH or some such environment variable that the dynamic >> linker pays attention to. I can't say that I find that a reliable or >> secure way to fix it, though. > > Well, that would explain this: > > -bash-3.00$ /usr/local/ssl/bin/openssl ld.so.1: openssl: fatal: > libgcc_s.so.1: open failed: No such file or directory Killed > > Apache compiled with it, but yes - I looked through the scripts and > configure logs and the paths were set by it correctly. > > I will mess with it more tonight and report my findings. Again, thanks > for listening to me think out loud :-) Found a kludgy fix! cp /usr/local/lib/sparcv9/libgcc_s.so.1 /usr/sfw/lib/sparcv9/ Now, both OpenSSL and PostgreSQL work great. In 64-bit mode. If anyone has a less hack-ish solution, please share. Thanks! Randy
Randal T. Rioux napsal(a):
> On Tue, September 9, 2008 5:25 am, Zdenek Kotala wrote:
>> Randal T. Rioux napsal(a):
>>> I've battled this for a while. I'm finally breaking down and asking for
>>> help.
>>>
>>> If you're answer to this is "why 64-bit" then don't answer. You wouldn't
>>> understand. Same if you say "why don't you use packages."
>>>
>>> Here is my scenerio:
>>>
>>> - Sun 420R x450Mhz UltraSPARC-II / 4GB RAM
>>> - Solaris 10 05/08
>>> - OpenSSL 0.9.8h
>>> - PostgreSQL 8.3.3
>>> - GCC 3.4.6
>>> - GNU Make 3.81
>> Three questions (yeah, you forbided ask, but ...)
>
> grumble grumble grumble...
>
>> 1) Why 64
>>
>> 64bit code on SPARC is slower, because SPARC uses 4byte instructions and
>> processing 64bit data needs more instructions. It is good only if you
>> need more then 4GB share memory. When you use sunstudio compiler with
>> best optimization 64bit application has 1%-5% performance degradation.
>
> A. Many databases use more than 4GB share memory.
Of course but you mention that you have only 4GB RAM.
> B. Re: SunStudio - that's why I'm using GCC.
I don't understand you there. Sunstudio generates better code on SPARC
and it is faster than code produced with GCC.
>> 2) Why you don't use package
>>
>> You can use Solaris'es packages, which are integrated and optimized for
>> Solaris.
>
> Which are bloated with stuff I don't need and missing stuff I do. Not to
> mention terribly outdated.
Could you be more specific? If is there something what you missing or
what is wrong in Solaris'es packages let me know. Maybe I can improve it.
>> 3) Why you don't use build-in libssl?
>>
>> Integrated libssl is not only copy of original open ssl. It has lot of
>> improvements and it uses crypto hardware accelerator if you have it (for
>> example Niagara 2).
>
> But it is 32-bit.
No, You have 64bit version in /usr/sfw/lib/64.
Zdenek
On Wed, September 10, 2008 10:54 am, Zdenek Kotala wrote: >>> Three questions (yeah, you forbided ask, but ...) >> >> grumble grumble grumble... >> >>> 1) Why 64 >>> >>> 64bit code on SPARC is slower, because SPARC uses 4byte instructions >>> and processing 64bit data needs more instructions. It is good only if >>> you need more then 4GB share memory. When you use sunstudio compiler >>> with best optimization 64bit application has 1%-5% performance >>> degradation. >> >> A. Many databases use more than 4GB share memory. > > Of course but you mention that you have only 4GB RAM. This is my test machine :-) >> B. Re: SunStudio - that's why I'm using GCC. > > I don't understand you there. Sunstudio generates better code on SPARC > and it is faster than code produced with GCC. I read your statement too fast. Nevermind my response to that. >>> 2) Why you don't use package >>> >>> You can use Solaris'es packages, which are integrated and optimized >>> for Solaris. >> >> Which are bloated with stuff I don't need and missing stuff I do. Not >> to mention terribly outdated. > > Could you be more specific? If is there something what you missing or > what is wrong in Solaris'es packages let me know. Maybe I can improve it. I just don't like the Solaris package system in general. It is, dare I say, worse than RPM. But this is a PostgreSQL list, so I'll save the rant! >>> 3) Why you don't use build-in libssl? >>> >>> Integrated libssl is not only copy of original open ssl. It has lot >>> of improvements and it uses crypto hardware accelerator if you have >>> it (for example Niagara 2). >> >> But it is 32-bit. > > No, You have 64bit version in /usr/sfw/lib/64. I did not know that! I need to check it out later. Thanks for the tip. Randy
Randal T. Rioux wrote: > > Found a kludgy fix! > > cp /usr/local/lib/sparcv9/libgcc_s.so.1 /usr/sfw/lib/sparcv9/ > > Now, both OpenSSL and PostgreSQL work great. In 64-bit mode. > > If anyone has a less hack-ish solution, please share. > > Thanks! > Randy Not sure if this'll make it to the list or not, I'm not currently registered, so apologies... The linker and the loader use two different things. The linker use LD_LIBRARY_PATH env. The loader does not. (and never never type 'ldconfig' on solaris cuz it'll really mess things up). use 'crle -u -l /usr/local/lib/sparcv9/' to add the path to the loaders search path. more here: http://blogs.sun.com/rie/entry/changing_search_paths_with_crle -Andy
Randal T. Rioux napsal(a):
> On Wed, September 10, 2008 10:54 am, Zdenek Kotala wrote:
> I just don't like the Solaris package system in general. It is, dare I
> say, worse than RPM. But this is a PostgreSQL list, so I'll save the rant!
Community solaris "package" on postgresql download website is only tarbal.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
Randal T. Rioux napsal(a): > On Mon, September 8, 2008 9:38 am, Randal T. Rioux wrote: > Found a kludgy fix! > > cp /usr/local/lib/sparcv9/libgcc_s.so.1 /usr/sfw/lib/sparcv9/ > > Now, both OpenSSL and PostgreSQL work great. In 64-bit mode. > > If anyone has a less hack-ish solution, please share. try to look on original Makefile for solaris fro inspiration: http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/postgres/postgresql-8.3/ http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/postgres/postgresql-8.3/Makefile.sfw Zdenek -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql