PG buildfarm member cisticola
Hello
A couple of days ago, PG buildfarm member cisticola started failing:
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=cisticola&br=HEAD
The failures[1]https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=cisticola&dt=2024-07-24%2010%3A20%3A37 are pretty mysterious:
make[3]: \347\246\273\345\274\200\347\233\256\345\275\225\342\200\234/home/postgres/buildfarm/HEAD/pgsql.build/src/backend/utils\342\200\235
ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -g -O2 access/brin/brin.o [...] libpq/be-secure-openssl.o [...] ../../src/timezone/localtime.o ../../src/timezone/pgtz.o ../../src/timezone/strftime.o jit/jit.o ../../src/common/libpgcommon_srv.a ../../src/port/libpgport_srv.a -L../../src/port -L../../src/common -Wl,--as-needed -Wl,-rpath,'/home/postgres/buildfarm/HEAD/inst/lib',--enable-new-dtags -Wl,--export-dynamic -lxslt -lxml2 -lssl -lcrypto -lgssapi_krb5 -lz -lpthread -lrt -ldl -lm -lldap -licui18n -licuuc -licudata -o postgres
/usr/bin/ld: libpq/be-secure-openssl.o: in function `.L388':
be-secure-openssl.c:(.text+0x1f8c): undefined reference to `ERR_new'
/usr/bin/ld: libpq/be-secure-openssl.o: in function `.L530':
be-secure-openssl.c:(.text+0x1fa4): undefined reference to `ERR_set_debug'
/usr/bin/ld: libpq/be-secure-openssl.o: in function `.LVL614':
be-secure-openssl.c:(.text+0x1fb8): undefined reference to `ERR_set_error'
/usr/bin/ld: libpq/be-secure-openssl.o: in function `.L539':
be-secure-openssl.c:(.text+0x2010): undefined reference to `ERR_new'
/usr/bin/ld: libpq/be-secure-openssl.o: in function `.L417':
be-secure-openssl.c:(.text+0x20b0): undefined reference to `SSL_get1_peer_certificate'
collect2: error: ld returned 1 exit status
Previously, this was working fine.
In this run, openssl is
checking for openssl... /usr/bin/openssl
configure: using openssl: OpenSSL 1.1.1g FIPS 21 Apr 2020
but that's the same that was used in the last successful run[2]https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=cisticola&dt=2024-07-20%2022%3A20%3A38&stg=configure, too.
Not sure what else could be relevant.
[1]: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=cisticola&dt=2024-07-24%2010%3A20%3A37
[2]: https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=cisticola&dt=2024-07-20%2022%3A20%3A38&stg=configure
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"No renuncies a nada. No te aferres a nada."
On 2024-Jul-24, Alvaro Herrera wrote:
be-secure-openssl.c:(.text+0x1f8c): undefined reference to `ERR_new'
be-secure-openssl.c:(.text+0x1fa4): undefined reference to `ERR_set_debug'
be-secure-openssl.c:(.text+0x1fb8): undefined reference to `ERR_set_error'
be-secure-openssl.c:(.text+0x2010): undefined reference to `ERR_new'
be-secure-openssl.c:(.text+0x20b0): undefined reference to `SSL_get1_peer_certificate'
In this run, openssl is
checking for openssl... /usr/bin/openssl
configure: using openssl: OpenSSL 1.1.1g FIPS 21 Apr 2020
Hmm, it appears that these symbols did not exist in 1.1.1g, and since
neither of them is invoked directly by the Postgres code, maybe the
reason for this is that the OpenSSL headers being used do not correspond
to the library being linked.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
On Wed, Jul 24, 2024 at 01:09:22PM +0200, Alvaro Herrera wrote:
Hmm, it appears that these symbols did not exist in 1.1.1g, and since
neither of them is invoked directly by the Postgres code, maybe the
reason for this is that the OpenSSL headers being used do not correspond
to the library being linked.
I am as puzzled as you are. The version of OpenSSL detected by
./configure is the same before and after the first failure. Well,
that's the output of `openssl` so perhaps we are just being lied here
and that we are trying to link to a different version in the
background. Impossible to say without more input from the machine
owner.
The two commits between the last success and the first failure are:
7e187a7386 Mon Jul 22 02:29:21 2024 UTC Fix unstable test in select_parallel.sql
2d8ef5e24f Mon Jul 22 00:28:01 2024 UTC Add new error code for "file name too long"
Discarding the first one points to the second, still I don't see a
relation, which would come down to a conflict with the new
ERRCODE_FILE_NAME_TOO_LONG (?).
--
Michael
On Thu, Jul 25, 2024 at 8:38 PM Michael Paquier <michael@paquier.xyz> wrote:
On Wed, Jul 24, 2024 at 01:09:22PM +0200, Alvaro Herrera wrote:
Hmm, it appears that these symbols did not exist in 1.1.1g, and since
neither of them is invoked directly by the Postgres code, maybe the
reason for this is that the OpenSSL headers being used do not correspond
to the library being linked.
Yeah, the OpenSSL 3.x header ssl.h contains:
/* Deprecated in 3.0.0 */
# ifndef OPENSSL_NO_DEPRECATED_3_0
# define SSL_get_peer_certificate SSL_get1_peer_certificate
# endif
PostgreSQL uses the name on the left, but OpenSSL 1.x library does not
contain the symbol on the right with the 1 in it. Part of a strategy
for deprecating that API, but perhaps on that OS it is possible to
install both OpenSSL versions, and something extra is needed for the
header search path and library search path to agree? I don't know
what Loongnix is exactly, but it has the aura of a RHEL-derivative.
Sorry for the late reply.
Yes ， it's the openssl , i accidentally install two version openssl the 3.x and 1.x on the same machine.
I remove the 3.x openssl and it's ok now.
----------
Best regards,
huchangqi
-----原始邮件-----
发件人: "Thomas Munro" <thomas.munro@gmail.com>
发送时间:2024-08-02 09:27:53 (星期五)
收件人: "Michael Paquier" <michael@paquier.xyz>
抄送: "Alvaro Herrera" <alvherre@alvh.no-ip.org>, huchangqi@loongson.cn, pgsql-hackers@lists.postgresql.org
主题: Re: PG buildfarm member cisticolaOn Thu, Jul 25, 2024 at 8:38 PM Michael Paquier <michael@paquier.xyz> wrote:
On Wed, Jul 24, 2024 at 01:09:22PM +0200, Alvaro Herrera wrote:
Hmm, it appears that these symbols did not exist in 1.1.1g, and since
neither of them is invoked directly by the Postgres code, maybe the
reason for this is that the OpenSSL headers being used do not correspond
to the library being linked.Yeah, the OpenSSL 3.x header ssl.h contains:
/* Deprecated in 3.0.0 */
# ifndef OPENSSL_NO_DEPRECATED_3_0
# define SSL_get_peer_certificate SSL_get1_peer_certificate
# endifPostgreSQL uses the name on the left, but OpenSSL 1.x library does not
contain the symbol on the right with the 1 in it. Part of a strategy
for deprecating that API, but perhaps on that OS it is possible to
install both OpenSSL versions, and something extra is needed for the
header search path and library search path to agree? I don't know
what Loongnix is exactly, but it has the aura of a RHEL-derivative.
本邮件及其附件含有龙芯中科的商业秘密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制或散发）本邮件及其附件中的信息。如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。
This email and its attachments contain confidential information from Loongson Technology , which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it.