Help Resolving Compiler Errors With enable-dtrace Flag - Mailing list pgsql-general

From Barry Walker
Subject Help Resolving Compiler Errors With enable-dtrace Flag
Date
Msg-id CAAiHg9UhjM6XN5XV_NMB184v0UO4H8rHGaBrtwJr0HHok8pJVA@mail.gmail.com
Whole thread Raw
Responses Re: Help Resolving Compiler Errors With enable-dtrace Flag
Re: Help Resolving Compiler Errors With enable-dtrace Flag
List pgsql-general
Hey folks,

I'm working on a custom version of Postgres that is roughly in line with 16.4 but has customizations in it. I'm trying to compile this custom version (on Linux) with `--enable-dtrace` but I'm running into an issue during the linker stage. I've done a clean and full rebuild but that doesn't help fix the problem. I get these errors for all probes:

access/transam/xact.o(.note.stapsdt+0x24): error: undefined reference to 'postgresql_transaction__start_semaphore'
access/transam/xact.o(.note.stapsdt+0x78): error: undefined reference to 'postgresql_transaction__commit_semaphore'
access/transam/xact.o(.note.stapsdt+0xcc): error: undefined reference to 'postgresql_transaction__abort_semaphore'
I can see the probes.h file gets generated what looks to be correctly, specifically these:
__extension__ extern unsigned short postgresql_transaction__commit_semaphore __attribute__ ((unused)) __attribute__ ((section (".probes")));
I have compiled vanilla pg16.4 with the same flags and the probes got created and linked as expected with no issues so I'm assuming there is some difference in the custom version that is causing the errors but I'm having a hard time tracking it down. I'm wondering if anyone here has any experience with this error or has any hints as to why the linker can't find these definitions or even just where the actual definitions for these probes should live so I can try to work backwards and see if there is any differences in the custom version that is messing with the linker.

Thanks!

pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: Postgres attach partition: AccessExclusive lock set on different tables depending on how attaching is performed
Next
From: Michel Pelletier
Date:
Subject: Using Expanded Objects other than Arrays from plpgsql