I wrote:
> Huh. So what that suggests is that the problem is related to picking
> up copies of our libraries from outside the build tree. Do you have
> any copies of libpgport.a/.so or libpgcommon.a/.so in
> /usr/local/lib or /usr/lib or /lib ?
Ah, no, scratch that, I see the problem. In v10, peripatus builds
insert_username.so like this:
ccache clang -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
-Wformat-security -fno-strict-aliasing -fwrapv
-Wno-unused-command-line-argument -g -O2 -fPIC -DPIC -L../../src/port
-L../../src/common -L/usr/local/lib -L/usr/local/lib -L/usr/lib
-Wl,--as-needed -Wl,-R'/home/pgbuildfarm/buildroot/REL_10_STABLE/inst/lib'
-L../../src/port -lpgport -shared -o insert_username.so insert_username.o
while v11 does it like this:
ccache clang -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
-Wformat-security -fno-strict-aliasing -fwrapv
-Wno-unused-command-line-argument -g -O2 -fPIC -DPIC -L../../src/port
-L../../src/common -L/usr/local/lib -L/usr/local/lib -L/usr/lib
-Wl,--as-needed -Wl,-R'/home/pgbuildfarm/buildroot/REL_11_STABLE/inst/lib'
-shared -o insert_username.so insert_username.o
In the first case, we're trying to include code from libpgport.a directly
into the .so, and since libpgport.a isn't built with -fPIC, it blows up.
In the second case, we *don't* link libpgport.a here at all. Rather,
any symbols that insert_username.so needs from that library will be
resolved in the main backend's copy of the library, for which
relocatability isn't required.
Note that there's a second problem with the way this is happening pre-v11:
for any src/port/ file that compiles different logic for frontend and
backend, insert_username.so would be picking up the wrong logic. Perhaps
we've not noticed because that module doesn't use any files in which
there's a meaningful difference, but there's an obvious hazard there.
Fooling with -fPIC isn't enough to fix it.
I'd been hesitant to back-patch dddfc4cb2 back in April; but now that
it's survived some beta testing, I think that doing so seems like the
most appropriate way to fix this.
regards, tom lane
