Re: [GENERAL] 64-bit Compile Failure on Solaris 10 with OpenSSL
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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 64-bit Compile Failure on Solaris 10 with OpenSSL
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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 64-bit Compile Failure on Solaris 10 with OpenSSL
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 [EMAIL PROTECTED] 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 64-bit Compile Failure on Solaris 10 with OpenSSL
On Mon, September 8, 2008 12:06 am, Tom Lane wrote: Randal T. Rioux [EMAIL PROTECTED] 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 64-bit Compile Failure on Solaris 10 with OpenSSL
On Sun, September 7, 2008 12:47 am, Tom Lane wrote: Randal T. Rioux [EMAIL PROTECTED] 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 64-bit Compile Failure on Solaris 10 with OpenSSL
On Sat, September 6, 2008 7:05 pm, Tom Lane wrote: Randal T. Rioux [EMAIL PROTECTED] 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 64-bit Compile Failure on Solaris 10 with OpenSSL
On Sat, September 6, 2008 8:21 pm, Tom Lane wrote: Randal T. Rioux [EMAIL PROTECTED] 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! :-) -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
