Обсуждение: Symbol referencing errors
Hi, When I compile PostgreSQL-11.2 on SmartOS, I find the following errors: Undefined first referenced symbol in file per_MultiFuncCall adminpack.o end_MultiFuncCall adminpack.o BuildTupleFromCStrings adminpack.o DecodeDateTime adminpack.o TupleDescGetAttInMetadata adminpack.o path_is_prefix_of_path adminpack.o canonicalize_path adminpack.o text_to_cstring adminpack.o errmsg adminpack.o superuser adminpack.o errcode_for_file_access adminpack.o palloc adminpack.o CurrentMemoryContext adminpack.o pstrdup adminpack.o ReadDir adminpack.o FreeFile adminpack.o errfinish adminpack.o init_MultiFuncCall adminpack.o errstart adminpack.o AllocateDir adminpack.o GetUserId adminpack.o is_member_of_role adminpack.o psprintf adminpack.o DataDir adminpack.o Log_filename adminpack.o Log_directory adminpack.o AllocateFile adminpack.o path_is_relative_and_below_cwd adminpack.o HeapTupleHeaderGetDatum adminpack.o errcode adminpack.o FreeDir adminpack.o ParseDateTime adminpack.o path_contains_parent_reference adminpack.o pg_detoast_datum_packed adminpack.o CreateTemplateTupleDesc adminpack.o TupleDescInitEntry adminpack.o ld: warning: symbol referencing errors make[1]: Leaving directory '/home/postgres/postgresql-11.2/contrib/adminpack' My environment is: # cat /etc/release SmartOS x86_64 Copyright 2010 Sun Microsystems, Inc. All Rights Reserved. Copyright 2015 Joyent, Inc. All Rights Reserved. Use is subject to license terms. See joyent_20161108T160947Z for assembly date and time. # $ pg_config BINDIR = /home/postgres/pg11.2/bin DOCDIR = /home/postgres/pg11.2/share/doc HTMLDIR = /home/postgres/pg11.2/share/doc INCLUDEDIR = /home/postgres/pg11.2/include PKGINCLUDEDIR = /home/postgres/pg11.2/include INCLUDEDIR-SERVER = /home/postgres/pg11.2/include/server LIBDIR = /home/postgres/pg11.2/lib PKGLIBDIR = /home/postgres/pg11.2/lib LOCALEDIR = /home/postgres/pg11.2/share/locale MANDIR = /home/postgres/pg11.2/share/man SHAREDIR = /home/postgres/pg11.2/share SYSCONFDIR = /home/postgres/pg11.2/etc PGXS = /home/postgres/pg11.2/lib/pgxs/src/makefiles/pgxs.mk CONFIGURE = '--prefix=/home/postgres/pg11.2' 'CFLAGS=-g -O0' CC = gcc CPPFLAGS = CFLAGS = -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -O0 CFLAGS_SL = -fPIC LDFLAGS = -Wl,-R'/home/postgres/pg11.2/lib' LDFLAGS_EX = LDFLAGS_SL = LIBS = -lpgcommon -lpgport -lz -lreadline -lnsl -lsocket -lm VERSION = PostgreSQL 11.2 Can anyone help me out? Thanks! Best regards! Japin Li
Li Japin <japinli@hotmail.com> writes: > When I compile PostgreSQL-11.2 on SmartOS, I find the following errors: > ... > ld: warning: symbol referencing errors Yeah, our SmartOS buildfarm members show those warnings too, eg https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=damselfly&dt=2019-04-22%2010%3A00%3A15&stg=make-contrib AFAICT they're harmless, so my advice is just ignore them. If you're sufficiently annoyed by them to find the cause and try to fix it, go ahead, but I haven't heard anyone else worried about it. It might be that SmartOS wants something like what we have to do on macOS and AIX, ie provide the core postgres executable in some sort of linker switch while linking shlibs that will be loaded by that executable. regards, tom lane
On 4/23/19 12:09 PM, Tom Lane wrote: > AFAICT they're harmless, so my advice is just ignore them. > > If you're sufficiently annoyed by them to find the cause > and try to fix it, go ahead, but I haven't heard anyone > else worried about it. It might be that SmartOS wants > something like what we have to do on macOS and AIX, > ie provide the core postgres executable in some sort of > linker switch while linking shlibs that will be loaded > by that executable. Yes, those errors does not impact the postgresql, but when I use oracle_fdw extension, I couldn't startup the postgresql, and I find that the dlopen throw an error which lead postmaster exit, and there is not more information. regards, Japin Li
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: >> When I compile PostgreSQL-11.2 on SmartOS, I find the following errors: >> ... >> ld: warning: symbol referencing errors Tom> Yeah, our SmartOS buildfarm members show those warnings too, eg Tom> https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=damselfly&dt=2019-04-22%2010%3A00%3A15&stg=make-contrib Tom> AFAICT they're harmless, so my advice is just ignore them. Tom> If you're sufficiently annoyed by them to find the cause Tom> and try to fix it, go ahead, but I haven't heard anyone Tom> else worried about it. It might be that SmartOS wants Tom> something like what we have to do on macOS and AIX, Tom> ie provide the core postgres executable in some sort of Tom> linker switch while linking shlibs that will be loaded Tom> by that executable. I wonder if it's the use of -Bsymbolic that causes this (buildfarm logs don't seem to go back far enough to check). (Note to original poster: -Bsymbolic is there for a reason, you can't just remove it - but see below.) Since this is an ELF platform - arguably the closest thing to the original reference ELF platform, at least by descent - it should not require the kinds of tricks used on macOS and AIX; but we haven't done the work needed to test using version scripts in place of -Bsymbolic for fixing the symbol conflict problems. That ought to be a relatively straightforward project for someone with access to a system to test on (and I'm happy to advise on it). The thing to do would be to try and copy the changes made to the *BSD ports in commit e3d77ea6b instead of the change made in 4fa3741d1. The contrib/postgres_fdw tests should show whether it worked or not. -- Andrew (irc:RhodiumToad)
On Tue, 2019-04-23 at 04:26 +0000, Li Japin wrote: > Yes, those errors does not impact the postgresql, but when > I use oracle_fdw extension, I couldn't startup the postgresql, > and I find that the dlopen throw an error which lead postmaster > exit, and there is not more information. That may wall be a bug in oracle_fdw, since I have no reports of anybody running it on that operating system. Maybe you should open an oracle_fdw issue, but I don't know how much I can help you, since this is the first time I have heard of SmartOS. Yours, Laurenz Albe
On 2019-Apr-23, Laurenz Albe wrote: > Maybe you should open an oracle_fdw issue, but I don't know how > much I can help you, since this is the first time I have heard > of SmartOS. SmartOS is just the continuation of OpenSolaris, AFAIU. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2019-Apr-23, Laurenz Albe wrote:
>> Maybe you should open an oracle_fdw issue, but I don't know how
>> much I can help you, since this is the first time I have heard
>> of SmartOS.
> SmartOS is just the continuation of OpenSolaris, AFAIU.
Yeah. You can see these same link warnings on castoroides and
protosciurus, though they're no longer building HEAD for
lack of C99-compliant system headers.
regards, tom lane
Hi,
Finally, I find this crash is caused by shmget_osm, which does not support SmartOS (maybe,
I am not sure). When I install Oracle Instant Client 12.2.0.1.0, it works.
https://github.com/laurenz/oracle_fdw/issues/313
Finally, I find this crash is caused by shmget_osm, which does not support SmartOS (maybe,
I am not sure). When I install Oracle Instant Client 12.2.0.1.0, it works.
https://github.com/laurenz/oracle_fdw/issues/313
On 4/23/19 3:09 PM, Laurenz Albe wrote:
On Tue, 2019-04-23 at 04:26 +0000, Li Japin wrote:Yes, those errors does not impact the postgresql, but when I use oracle_fdw extension, I couldn't startup the postgresql, and I find that the dlopen throw an error which lead postmaster exit, and there is not more information.That may wall be a bug in oracle_fdw, since I have no reports of anybody running it on that operating system. Maybe you should open an oracle_fdw issue, but I don't know how much I can help you, since this is the first time I have heard of SmartOS.
Hi, On 2019-04-23 06:23:13 +0100, Andrew Gierth wrote: > I wonder if it's the use of -Bsymbolic that causes this (buildfarm logs > don't seem to go back far enough to check). (Note to original poster: > -Bsymbolic is there for a reason, you can't just remove it - but see > below.) For the record, yes, the "ld: warning: symbol referencing errors" warnings are due to -Bsymbolic while linking extensions. The man page says: "The link-editor issues warnings for undefined symbols unless -z defs overrides" > Since this is an ELF platform - arguably the closest thing to the > original reference ELF platform, at least by descent - it should not > require the kinds of tricks used on macOS and AIX; but we haven't done > the work needed to test using version scripts in place of -Bsymbolic for > fixing the symbol conflict problems. That ought to be a relatively > straightforward project for someone with access to a system to test on > (and I'm happy to advise on it). It's indeed trivial - the only change needed from linux is to replace -Wl,--version-script=... with -Wl,-M... Greetings, Andres Freund
Hi, On 2022-08-23 01:34:36 -0700, Andres Freund wrote: > On 2019-04-23 06:23:13 +0100, Andrew Gierth wrote: > > I wonder if it's the use of -Bsymbolic that causes this (buildfarm logs > > don't seem to go back far enough to check). (Note to original poster: > > -Bsymbolic is there for a reason, you can't just remove it - but see > > below.) > > For the record, yes, the "ld: warning: symbol referencing errors" warnings are > due to -Bsymbolic while linking extensions. The man page says: > "The link-editor issues warnings for undefined symbols unless -z defs overrides" > > > > Since this is an ELF platform - arguably the closest thing to the > > original reference ELF platform, at least by descent - it should not > > require the kinds of tricks used on macOS and AIX; but we haven't done > > the work needed to test using version scripts in place of -Bsymbolic for > > fixing the symbol conflict problems. That ought to be a relatively > > straightforward project for someone with access to a system to test on > > (and I'm happy to advise on it). > > It's indeed trivial - the only change needed from linux is to replace > -Wl,--version-script=... with -Wl,-M... Patch attached. Passed check-world (without tap tests, didn't install the perl mods) on solaris. Does anybody see a reason not to apply? Even just having less noisy build logs seem like an advantage. Greetings, Andres Freund