Re: Linker errors while creating a PostgreSQL C extension function.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dmitry Igrishin <dmitigr(at)gmail(dot)com>
Cc: Tal Glozman <glozmantal(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Linker errors while creating a PostgreSQL C extension function.
Date: 2018-08-19 14:54:32
Message-ID: 20033.1534690472@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Dmitry Igrishin <dmitigr(at)gmail(dot)com> writes:
> вс, 19 авг. 2018 г. в 16:20, TalGloz <glozmantal(at)gmail(dot)com>:
>> I'll try it later when I'm home. Is there a reason that you are linking like
>> this
>> $(CXX) -Wl,--no-undefined -shared -o seal_diff_cpp.so $(LDFLAGS) $(LDLIBS)
>> seal_diff_cpp.o
>> And not like this?
>> $(CXX) -Wl,--no-undefined -shared -o seal_diff_cpp.so seal_diff_cpp.o
>> $(LDFLAGS) $(LDLIBS)

> If I recall correctly there were some problems with ordering arguments
> of the linker that are specified upon calling g++.

You're creating such problems, not solving them, if you put the library
first. Particularly with .a-style libraries, you *must* list the
referencing .o file first, or the linker will deem the library
unreferenced and unnecessary.

None of this explains the failures on the core-backend symbol references,
though. What platform is this? I'm suspecting macOS or AIX, which
require the postgres executable to be explicitly mentioned when linking
.so's you intend to be loaded by postgres. Most other platforms leave
such symbols to be resolved at runtime.

It might be a good idea to see if you can't use PGXS, which will deal
with a lot of these fine points for you.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message TalGloz 2018-08-19 15:10:55 Re: Linker errors while creating a PostgreSQL C extension function.
Previous Message Dmitry Igrishin 2018-08-19 14:28:52 Re: Linker errors while creating a PostgreSQL C extension function.