Thread: how to compile postgresql with other version of openssl?
Postgresql is first linux program based on automake I've ever seen (and i've been compiling linux stuff nice 1999) that does not allow specyfying lib locations on ./configure like (like --with-openssl=/path/to/openssl) So how do I link it to other version of openssl than one that is present in os system directories? I've tried: PKG_CONFIG=/usr/openssl-0.9.8zg/lib/pkgconfig ./configure --with-openssl LD_LIBRARY_PATH=/usr/openssl-0.9.8zg/lib ./configure --with-openssl LDFLAGS="-L/usr/openssl-0.9.8zg/lib" ./configure --with-openssl but build binnary is linked to system openssl (check for example by ldd src/psql/psql|grep ssl) ./configure script does not even say what openssl files it checks. I've also tried ./configure --includedir=/usr/openssl-0.9.8zg/include --with-libraries=/usr/openssl-0.9.8zg/lib --with-openssl it does in this case it does not even complete ./configure script
On Sun, Jul 26, 2015 at 2:55 PM, krzf83@gmail.com <krzf83@gmail.com> wrote:
> Postgresql is first linux program based on automake I've ever seen
> (and i've been compiling linux stuff nice 1999) that does not allow
> specyfying lib locations on ./configure like
> (like --with-openssl=/path/to/openssl)
You could use CFLAGS and LDFLAGS for this purpose:
./configure CFLAGS="-I/usr/openssl-0.9.8zg/include" \
LDFLAGS="-L/usr/openssl-0.9.8zg/lib" \
--with-openssl
--
Michael
# ./configure CFLAGS="-I/usr/openssl-0.9.8zg/include" LDFLAGS="-L/usr/openssl-0.9.8zg/lib" --with-openssl 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. # tail config.log ... #define HAVE_GETHOSTBYNAME_R 1 #define GETPWUID_R_5ARG 1 configure: exit 1 It does compile without a problem when used without CFLAGS and LDFLAGS but against system lib /lib64/libssl.so.6 # LDFLAGS="-L/usr/openssl-0.9.8zg/lib" ./configure --with-openssl 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. # tail config.log ... #define HAVE_GETHOSTBYNAME_R 1 #define GETPWUID_R_5ARG 1 configure: exit 1 setting LDFLAGS to openssl lib dir causes postgresql ./configure to fail without real explanation. A bug? 2015-07-26 9:06 GMT+02:00 Michael Paquier <michael.paquier@gmail.com>: > On Sun, Jul 26, 2015 at 2:55 PM, krzf83@gmail.com <krzf83@gmail.com> wrote: >> Postgresql is first linux program based on automake I've ever seen >> (and i've been compiling linux stuff nice 1999) that does not allow >> specyfying lib locations on ./configure like >> (like --with-openssl=/path/to/openssl) > > You could use CFLAGS and LDFLAGS for this purpose: > ./configure CFLAGS="-I/usr/openssl-0.9.8zg/include" \ > LDFLAGS="-L/usr/openssl-0.9.8zg/lib" \ > --with-openssl > -- > Michael
On Mon, Jul 27, 2015 at 8:34 AM, krzf83@gmail.com <krzf83@gmail.com> wrote: > setting LDFLAGS to openssl lib dir causes postgresql ./configure to > fail without real explanation. (Please do not top-post). It may be missing dependencies. You should check config.log for more input about the reason why it failed and then check your distribution packages or the toolchain you are trying to build the code on. > A bug? I don't think so. -- Michael
> It may be missing dependencies. Like I mentioned without LDFLAGS CFLAGS there are no problem with compilation so problem is with configure script and CFLAGS LDFLAGS or/and openssl library >You should check config.log for more input I've previously pasted config.log. It does not contain any information, only "configure: exit 1", nothing else. for tests openssl was compiled with CFLAGS=-fPIC ./config shared zlib zlib-dynamic --openssldir=/usr/openssl-0.9.8zg CFLAGS=-fPIC ./config shared zlib zlib-dynamic --openssldir=/usr/openssl-1.0.1p # LDFLAGS="-L/usr/openssl-0.9.8zg/lib" ./configure --with-openssl 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. # LDFLAGS="-L/usr/openssl-1.0.1p/lib" ./configure --with-openssl works. Compiles ok. ldd psql does not show linking to any openssl lib for some reason for this new version of openssl (maybe its compiled staticly?) so I don't know any other method to check if 1.0.1p is actualy compiled in (?) so a bug... postgresql incomaptibility with openssl 0.9.8zg and a bug with ./configure program that does not output anything usefull that would indicate cause.
On 07/26/2015 04:34 PM, krzf83@gmail.com wrote: > # ./configure CFLAGS="-I/usr/openssl-0.9.8zg/include" > LDFLAGS="-L/usr/openssl-0.9.8zg/lib" --with-openssl > > 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. > > # tail config.log > ... > #define HAVE_GETHOSTBYNAME_R 1 > #define GETPWUID_R_5ARG 1 > > configure: exit 1 > > It does compile without a problem when used without CFLAGS and LDFLAGS > but against system lib /lib64/libssl.so.6 > > # LDFLAGS="-L/usr/openssl-0.9.8zg/lib" ./configure --with-openssl > 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. > # tail config.log > ... > #define HAVE_GETHOSTBYNAME_R 1 > #define GETPWUID_R_5ARG 1 > > configure: exit 1 > > > setting LDFLAGS to openssl lib dir causes postgresql ./configure to > fail without real explanation. A bug? Well if it where me I would do: grep -i ssl config.log instead of tail > > 2015-07-26 9:06 GMT+02:00 Michael Paquier <michael.paquier@gmail.com>: >> On Sun, Jul 26, 2015 at 2:55 PM, krzf83@gmail.com <krzf83@gmail.com> wrote: >>> Postgresql is first linux program based on automake I've ever seen >>> (and i've been compiling linux stuff nice 1999) that does not allow >>> specyfying lib locations on ./configure like >>> (like --with-openssl=/path/to/openssl) >> >> You could use CFLAGS and LDFLAGS for this purpose: >> ./configure CFLAGS="-I/usr/openssl-0.9.8zg/include" \ >> LDFLAGS="-L/usr/openssl-0.9.8zg/lib" \ >> --with-openssl >> -- >> Michael > > -- Adrian Klaver adrian.klaver@aklaver.com
On 07/26/2015 05:24 PM, krzf83@gmail.com wrote: >> It may be missing dependencies. > Like I mentioned without LDFLAGS CFLAGS there are no problem with > compilation so problem is with configure script and CFLAGS LDFLAGS > or/and openssl library > >> You should check config.log for more input > I've previously pasted config.log. It does not contain any > information, only "configure: exit 1", nothing else. Unless I missed something all you showed was the last three lines of the file, which may or may not have anything to do with issue. > > for tests openssl was compiled with > CFLAGS=-fPIC ./config shared zlib zlib-dynamic --openssldir=/usr/openssl-0.9.8zg > CFLAGS=-fPIC ./config shared zlib zlib-dynamic --openssldir=/usr/openssl-1.0.1p > > # LDFLAGS="-L/usr/openssl-0.9.8zg/lib" ./configure --with-openssl > 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. > > # LDFLAGS="-L/usr/openssl-1.0.1p/lib" ./configure --with-openssl > works. Compiles ok. ldd psql does not show linking to any openssl lib > for some reason for this new version of openssl (maybe its compiled > staticly?) so I don't know any other method to check if 1.0.1p is > actualy compiled in (?) > > so a bug... postgresql incomaptibility with openssl 0.9.8zg and a bug > with ./configure program that does not output anything usefull that > would indicate cause. > > -- Adrian Klaver adrian.klaver@aklaver.com
# LDFLAGS="-L/usr/openssl-0.9.8zg/lib" ./configure --with-openssl 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. # grep -i ssl config.log configure:13056: gcc -o conftest -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -O2 -D_GNU_SOURCE -L/usr/openssl-0.9.8zg/lib conftest.c -lssl -lcrypto -lz -lreadline -ltermcap -lrt -lcrypt -ldl -lm >&5 ./conftest: error while loading shared libraries: libssl.so.0.9.8: cannot open shared object file: No such file or directory # ls /usr/openssl-0.9.8zg/lib ./ ../ engines/ libcrypto.a libcrypto.so@ libcrypto.so.0.9.8* libssl.a libssl.so@ libssl.so.0.9.8* pkgconfig/ For some reason LDFLAGS="-L/usr/openssl-1.0.1p/lib" ./configure --with-openssl seems to compile ok
and that is probably why openssl-1.0.1p works - it does not seem to have any *.so files so I guess its not dynamicly linked into other programs (?). root@sv1 [/root]# ls /usr/openssl-0.9.8zg/lib ./ ../ engines/ libcrypto.a libcrypto.so@ libcrypto.so.0.9.8* libssl.a libssl.so@ libssl.so.0.9.8* pkgconfig/ root@sv1 [/root]# ls /usr/openssl-1.0.1p/lib ./ ../ engines/ libcrypto.a libssl.a pkgconfig/ Still seems a postgresql bug when linking against openssl-0.9.8zg in a custom location or maybe actualy any *.so lib anywhere pinpointed by LDFLAGS ./configure CFLAGS="-I/usr/openssl-0.9.8zg/include" LDFLAGS="-L/usr/openssl-0.9.8zg/lib" --with-openssl 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. # grep -i ssl config.log configure:13056: gcc -o conftest -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -I/usr/openssl-0.9.8zg/include -D_GNU_SOURCE -L/usr/openssl-0.9.8zg/lib conftest.c -lssl -lcrypto -lz -lreadline -ltermcap -lrt -lcrypt -ldl -lm >&5 ./conftest: error while loading shared libraries: libssl.so.0.9.8: cannot open shared object file: No such file or directory # ls /usr/openssl-0.9.8zg/lib ./ ../ engines/ libcrypto.a libcrypto.so@ libcrypto.so.0.9.8* libssl.a libssl.so@ libssl.so.0.9.8* pkgconfig/
On 07/26/2015 05:32 PM, krzf83@gmail.com wrote: > # LDFLAGS="-L/usr/openssl-0.9.8zg/lib" ./configure --with-openssl > 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. > > # grep -i ssl config.log > configure:13056: gcc -o conftest -Wall -Wmissing-prototypes > -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels > -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing > -fwrapv -O2 -D_GNU_SOURCE -L/usr/openssl-0.9.8zg/lib conftest.c > -lssl -lcrypto -lz -lreadline -ltermcap -lrt -lcrypt -ldl -lm >&5 > ./conftest: error while loading shared libraries: libssl.so.0.9.8: > cannot open shared object file: No such file or directory > > # ls /usr/openssl-0.9.8zg/lib > ./ ../ engines/ libcrypto.a libcrypto.so@ libcrypto.so.0.9.8* > libssl.a libssl.so@ libssl.so.0.9.8* pkgconfig/ So what does ls -al show? And what does ldd /usr/openssl-0.9.8zg/lib/libssl.so.0.9.8 show? > > For some reason > LDFLAGS="-L/usr/openssl-1.0.1p/lib" ./configure --with-openssl > seems to compile ok > -- Adrian Klaver adrian.klaver@aklaver.com
"krzf83@gmail.com " <krzf83@gmail.com> writes:
> # grep -i ssl config.log
> configure:13056: gcc -o conftest -Wall -Wmissing-prototypes
> -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels
> -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
> -fwrapv -O2 -D_GNU_SOURCE -L/usr/openssl-0.9.8zg/lib conftest.c
> -lssl -lcrypto -lz -lreadline -ltermcap -lrt -lcrypt -ldl -lm >&5
> ./conftest: error while loading shared libraries: libssl.so.0.9.8:
> cannot open shared object file: No such file or directory
Please try to be a little bit more effective about examining config.log.
There is likely to be useful information in the log immediately around the
lines you have grepped for.
(Also, "tail config.log" is just about guaranteed to be useless, because
autoconf always ends that file with a dump of the script's state
variables, of which there are hundreds. Typically what you need to look
at to debug a failure is the last few dozen lines before the line reading
"## Cache variables. ##".)
In this particular case, though, I can pretty much predict what your
problem is: Linux is not very friendly to shared libraries that are
installed outside the normal shared-library directories such as /usr/lib.
Adding a -L switch is *not* sufficient to overcome that: -L only fixes
program construction not program execution. You can overcome it with an
"rpath" setting, which is what Postgres uses so that psql et al can find
libpq.so when we're asked to install into nonstandard locations. But we
don't have a provision for adding anything except our own lib directory
to our rpath (and I don't think many other packages offer such a thing
either). If you want to have your own private libssl installation in a
nonstandard location, the best bet is to teach the dynamic loader about
that library directory by adding it to /etc/ld.so.conf or similar
location. ("man ldconfig" is worth reading first.)
regards, tom lane
PS: you'll need the -L switch as well. And the -I switch. They each
solve distinct parts of the problem when dealing with a library in a
nonstandard location.