Thread: 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] 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.ojit/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], 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
Attachment
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 cisticola > > 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. > 本邮件及其附件含有龙芯中科的商业秘密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制或散发）本邮件及其附件中的信息。如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。 This email and its attachments contain confidential information from Loongson Technology , which is intended only for theperson or entity whose address is listed above. Any use of the information contained herein in any way (including, butnot 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 anddelete it.