Обсуждение: FreeBSD 12 and Postgres build failures
Both 10.7 and 11.2 fail on FreeBSD 12-STABLE if --with-openssl is part of the configure string.
The issue appears to be that FreeBSD updated OpenSSL to OpenSSL 1.1.1a-freebsd 20 Nov 2018 where the 11.x release of FreeBSD (and previous was on 1.0.x -- e.g. OpenSSL 1.0.2o-freebsd 27 Mar 2018)
The errors start here:
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -O2 -I../../../src/include -c -o be-secure-openssl.o be-secure-openssl.c
be-secure-openssl.c: In function 'be_tls_init':
be-secure-openssl.c:85:3: warning: implicit declaration of function 'OPENSSL_init_ssl'; did you mean 'OPENSSL_init'? [-Wimplicit-function-declaration]
OPENSSL_init_ssl(OPENSSL_INIT_LOAD_CONFIG, NULL);
^~~~~~~~~~~~~~~~
OPENSSL_init
be-secure-openssl.c:85:20: error: 'OPENSSL_INIT_LOAD_CONFIG' undeclared (first use in this function); did you mean 'OPENSSL_NO_PADLOCK'?
OPENSSL_init_ssl(OPENSSL_INIT_LOAD_CONFIG, NULL);
^~~~~~~~~~~~~~~~~~~~~~~~
OPENSSL_NO_PADLOCK
be-secure-openssl.c:85:20: note: each undeclared identifier is reported only once for each function it appears in
be-secure-openssl.c: In function 'my_sock_read':
be-secure-openssl.c:665:35: warning: implicit declaration of function 'BIO_get_data'; did you mean 'BIO_get_ex_data'? [-Wimplicit-function-declaration]
res = secure_raw_read(((Port *) BIO_get_data(h)), buf, size);
^~~~~~~~~~~~
BIO_get_ex_data
be-secure-openssl.c:665:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
res = secure_raw_read(((Port *) BIO_get_data(h)), buf, size);
^
Has anyone looked into and dealt with this yet or have suggestions?
Вложения
Karl Denninger <karl@denninger.net> writes:
> Both 10.7 and 11.2 fail on FreeBSD 12-STABLE if --with-openssl is part
> of the configure string.
Hmmm ... I don't have that exact configuration handy to try, but
we know that PG works against OpenSSL 1.1.1a in principle, and
it does work for me with FreeBSD 12.0-RC1 from mid-November,
which contains
# openssl version
OpenSSL 1.1.1-freebsd 11 Sep 2018
The error you quote looks a bit like bad decisions in PG's configure
script --- maybe you need to re-run configure? Be sure to blow
away any autoconf cache file if you're using one.
regards, tom lane
On Wed, Mar 20, 2019 at 11:13 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Karl Denninger <karl@denninger.net> writes: > > Both 10.7 and 11.2 fail on FreeBSD 12-STABLE if --with-openssl is part > > of the configure string. > > Hmmm ... I don't have that exact configuration handy to try, but > we know that PG works against OpenSSL 1.1.1a in principle, and > it does work for me with FreeBSD 12.0-RC1 from mid-November, > which contains > # openssl version > OpenSSL 1.1.1-freebsd 11 Sep 2018 > > The error you quote looks a bit like bad decisions in PG's configure > script --- maybe you need to re-run configure? Be sure to blow > away any autoconf cache file if you're using one. Builds OK for me on FreeBSD 12.0-RELEASE (using OpenSSL 1.1.1a-freebsd from base system), tested with PostgreSQL REL_11_STABLE. +1 for the autoconf cache theory. -- Thomas Munro https://enterprisedb.com
>>>>> "Karl" == Karl Denninger <karl@denninger.net> writes: Karl> Both 10.7 and 11.2 fail on FreeBSD 12-STABLE if --with-openssl is Karl> part of the configure string. Nope, they work fine for me, running under 12-stable as of a couple of weeks ago. -- Andrew (irc:RhodiumToad)
Karl Denninger <karl@denninger.net> writes:Both 10.7 and 11.2 fail on FreeBSD 12-STABLE if --with-openssl is part of the configure string.Hmmm ... I don't have that exact configuration handy to try, but we know that PG works against OpenSSL 1.1.1a in principle, and it does work for me with FreeBSD 12.0-RC1 from mid-November, which contains # openssl version OpenSSL 1.1.1-freebsd 11 Sep 2018 The error you quote looks a bit like bad decisions in PG's configure script --- maybe you need to re-run configure? Be sure to blow away any autoconf cache file if you're using one. regards, tom lane
That was on a bare, new grab of the source from your repository and a straight-up run of "./configure --with-openssl --with-perl", then "gmake".
It's a new directory tree - there's no autoconf or other cache files laying around.
Same grab on FreeBSD 11.x builds fine.
Digging around I had the openssl-1.0.2r port on the system, which used to be necessary for some other stuff back before 12.x. I've removed it and it looks like that took care of it; for whatever reason configure was getting confused (in theory this shouldn't get you, but theory and practice sometimes don't play nice. :-)
Thanks for the confirm that others do have it working; gave me a place to start looking for the issue.
Вложения
On Wed, Mar 20, 2019 at 11:33 AM Karl Denninger <karl@denninger.net> wrote: > Digging around I had the openssl-1.0.2r port on the system, which used to be necessary for some other stuff back before12.x. I've removed it and it looks like that took care of it; for whatever reason configure was getting confused (intheory this shouldn't get you, but theory and practice sometimes don't play nice. :-) Hmm. I guess it'd be good not to get confused between ports and base OpenSSL installations... is there something we're doing wrong that makes that happen? -- Thomas Munro https://enterprisedb.com
>>>>> "Karl" == Karl Denninger <karl@denninger.net> writes: Karl> That was on a bare, new grab of the source from your repository and a Karl> straight-up run of "./configure --with-openssl --with-perl", then "gmake". That's a configure line that has never worked on FreeBSD: % ./configure --with-openssl --with-perl [...] configure: error: readline header not found If you have libedit already installed, see config.log for details on the failure. It is possible the compiler isn't looking in the proper directory. Use --without-readline to disable libedit support. % (If you don't use --without-readline then you must add --with-includes=/usr/local/include and --with-libs=/usr/local/lib to pick up either ports readline or ports libedit. Or you might be able to use --with-includes=/usr/include/edit to get base system libedit, but that's not really the recommended method. Besides libedit sucks for actual use so you want readline anyway.) If you didn't explicitly specify any of those, but configure found a readline to use anyway, then it means you have defined some non-standard compiler options or have messed with the include paths in some other way, which could be relevant to your problem. -- Andrew (irc:RhodiumToad)
"Karl" == Karl Denninger <karl@denninger.net> writes:Karl> That was on a bare, new grab of the source from your repository and aKarl> straight-up run of "./configure --with-openssl --with-perl", then "gmake". That's a configure line that has never worked on FreeBSD: % ./configure --with-openssl --with-perl [...] configure: error: readline header not found If you have libedit already installed, see config.log for details on the failure. It is possible the compiler isn't looking in the proper directory. Use --without-readline to disable libedit support. %
Uh, it has worked on all my FreeBSD systems for a very long time; I've been running Postgres as the backend for a web forum/blogging system for the last many years. Then again:
[karl@NewFS ~]$ pkg info|grep readline
readline-7.0.5 Library for editing command lines as they are typed
Вложения
>>>>> "Karl" == Karl Denninger <karl@denninger.net> writes: >> That's a configure line that has never worked on FreeBSD: >> >> % ./configure --with-openssl --with-perl >> [...] >> configure: error: readline header not found >> If you have libedit already installed, see config.log for details on the >> failure. It is possible the compiler isn't looking in the proper directory. >> Use --without-readline to disable libedit support. >> % Karl> Uh, it has worked on all my FreeBSD systems for a very long time; Then you have done something non-standard, because "cc" on FreeBSD does not look in /usr/local/include or /usr/local/lib without being told to do so, and the configure checks for readline will fail without that. Possible explanations include having a "gcc" (without a specific version suffix) on the $PATH (gcc will be chosen over cc in that case), or having configured CFLAGS or CPPFLAGS in the environment to ./configure. You might post your full output of ./configure rather than leaving us to guess at it. -- Andrew (irc:RhodiumToad)
"Karl" == Karl Denninger <karl@denninger.net> writes:>> That's a configure line that has never worked on FreeBSD:>> >> % ./configure --with-openssl --with-perl>> [...]>> configure: error: readline header not found>> If you have libedit already installed, see config.log for details on the>> failure. It is possible the compiler isn't looking in the proper directory.>> Use --without-readline to disable libedit support.>> % Karl> Uh, it has worked on all my FreeBSD systems for a very long time; Then you have done something non-standard, because "cc" on FreeBSD does not look in /usr/local/include or /usr/local/lib without being told to do so, and the configure checks for readline will fail without that. Possible explanations include having a "gcc" (without a specific version suffix) on the $PATH (gcc will be chosen over cc in that case), or having configured CFLAGS or CPPFLAGS in the environment to ./configure. You might post your full output of ./configure rather than leaving us to guess at it.
"cc" on FreeBSD is now (and has been for quite some time) clang: root@NewFS:/home/karl # cc -v
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)
Target: x86_64-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin
If it will compile Postgres now it definitely would not when it was first shifted to; gcc, on the other hand (and gmake) does just fine and yes, they are ports (packages in this case as they're binary installs on this box) and not part of the base system:
root@NewFS:/home/karl # which gcc
/usr/local/bin/gcc
root@NewFS:/home/karl # gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc8/gcc/x86_64-portbld-freebsd12.0/8.3.0/lto-wrapper
Target: x86_64-portbld-freebsd12.0
Configured with: /wrkdirs/usr/ports/lang/gcc8/work/gcc-8.3.0/configure --with-build-config=bootstrap-debug --disable-nls --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc8 --libexecdir=/usr/local/libexec/gcc8 --program-suffix=8 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc8/include/c++/ --with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --enable-languages=c,c++,objc,fortran --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/share/info/gcc8 --build=x86_64-portbld-freebsd12.0
Thread model: posix
gcc version 8.3.0 (FreeBSD Ports Collection)
I'll spin up a test machine on a "virgin" install when I get one free from other things and see exactly what I have to put on there in terms of ports.
In any event with the removal of the openssl port it now configures, compiles, links and runs.
config.log makes clear it is using gcc (as did the blowup)
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by PostgreSQL configure 11.2, which was
generated by GNU Autoconf 2.69. Invocation command line was
$ ./configure --with-openssl --with-perl
## --------- ##
## Platform. ##
## --------- ##
hostname = NewFS.denninger.net
uname -m = amd64
uname -r = 12.0-STABLE
uname -s = FreeBSD
uname -v = FreeBSD 12.0-STABLE r343809 KSD-SMP
/usr/bin/uname -p = amd64
/bin/uname -X = unknown
/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
PATH: /sbin
PATH: /bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /root/bin
## ----------- ##
## Core tests. ##
## ----------- ##
configure:2840: checking build system type
configure:2854: result: x86_64-unknown-freebsd12.0
configure:2874: checking host system type
configure:2887: result: x86_64-unknown-freebsd12.0
configure:2909: checking which template to use
configure:2977: result: freebsd
configure:3102: checking whether NLS is wanted
configure:3134: result: no
configure:3142: checking for default port number
configure:3167: result: 5432
configure:3672: checking for block size
configure:3706: result: 8kB
configure:3718: checking for segment size
configure:3747: result: 1GB
configure:3759: checking for WAL block size
configure:3794: result: 8kB
configure:3891: checking for gcc
configure:3907: found /usr/local/bin/gcc
configure:3918: result: gcc
configure:3949: checking for C compiler version
configure:3958: gcc --version >&5
gcc (FreeBSD Ports Collection) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
configure:3969: $? = 0
configure:3958: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc8/gcc/x86_64-portbld-freebsd12.0/8.3.0/lto-wrapper
Target: x86_64-portbld-freebsd12.0
Configured with: /wrkdirs/usr/ports/lang/gcc8/work/gcc-8.3.0/configure --with-build-config=bootstrap-debug --disable-nls --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc8 --libexecdir=/usr/local/libexec/gcc8 --program-suffix=8 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc8/include/c++/ --with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --enable-languages=c,c++,objc,fortran --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/share/info/gcc8 --build=x86_64-portbld-freebsd12.0
Thread model: posix
gcc version 8.3.0 (FreeBSD Ports Collection)
configure:3969: $? = 0
configure:3958: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:3969: $? = 1
configure:3958: gcc -qversion >&5
gcc: error: unrecognized command line option '-qversion'; did you mean '--version'?
gcc: fatal error: no input files
compilation terminated.
..... (the whole file is over 10k lines....)
Вложения
>>>>> "Karl" == Karl Denninger <karl@denninger.net> writes: Karl> "cc" on FreeBSD is now (and has been for quite some time) clang: Karl> If it will compile Postgres now it definitely would not when it Karl> was first shifted to; People have been building PG with clang since at least as far back as clang 3.1, and the FreeBSD 10.0 (which I believe was the first FreeBSD release where clang was the default) package builds of PG were built with clang 3.3. (Now, of course, clang is _required_ if you want to try out the new JIT features.) Building with gcc on FreeBSD is not the default on a clean system, and as we've recently seen with another report, there are issues with mixing the gcc and llvm toolchains on some architectures that are not in any way PG's problem to solve. (Though the fact that we prefer gcc to cc in configure if both are found is a decision that should probably be revisited, given that the reasons for that preference are mostly consigned to the graveyard of commercial Unix variants.) You might also have considered that the fact that package builds exist for pg 10 and 11 on FreeBSD 12 is a demonstration that building them is, in fact, possible on a clean system... Karl> root@NewFS:/home/karl # which gcc Karl> /usr/local/bin/gcc I had not previously noticed that the lang/gcc metaport (which I have never installed, though I have lang/gcc8 installed at the moment) installs a symlink to the selected gcc version as just "gcc". That explains a lot. -- Andrew (irc:RhodiumToad)
On Wed, Mar 20, 2019 at 6:41 PM Andrew Gierth <andrew@tao11.riddles.org.uk> wrote: > ... (Though the fact that we prefer gcc to cc in > configure if both are found is a decision that should probably be > revisited, given that the reasons for that preference are mostly > consigned to the graveyard of commercial Unix variants.) +1 I'm not against looking for gcc and g++ if cc and c++ can't be found, but preferring them (ie implying that some random GCC found on the path that you didn't explicitly ask for must surely be better than whatever crap the vendor ships) makes no sense in this day and age. The silliest case is macOS, where gcc and g++ are found and used but are in fact... wrappers for clang, for maximum confusion. -- Thomas Munro https://enterprisedb.com