Re: Help Resolving Compiler Errors With enable-dtrace Flag

From: Barry Walker <mstrchef7(at)gmail(dot)com>
To: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Help Resolving Compiler Errors With enable-dtrace Flag
Date: 2024-10-20 19:02:06
Message-ID: CAAiHg9UYgC93EHfLoNrWmWg3myvv5pdE91+USJ=1VvbyruJuqw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Unfortunately the people remaining are just as lost as me. No one has
attempted to build with dtrace so I'm in uncharted territory.

A diff of the object file doesn't give any useful information, the custom
version has a lot of differences since there have been a number of changes
from stock. postgresql_transaction__commit_semaphore does exist in the
symbol table of both .o files though when compared with objdump.

On Sun, Oct 20, 2024 at 1:50 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:

> On 10/20/24 09:30, Barry Walker wrote:
> > Hey folks,
>
> > 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.
>
> Talking to the folks that created the custom version is not possible?
>
> If you do a diff on:
>
> access/transam/xact.o
>
> between the stock and custom version does it shed any light?
>
> >
> > Thanks!
>
> --
> Adrian Klaver
> adrian(dot)klaver(at)aklaver(dot)com
>
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2024-10-20 19:19:00 Re: Using Expanded Objects other than Arrays from plpgsql
Previous Message Michel Pelletier 2024-10-20 18:25:30 Re: Using Expanded Objects other than Arrays from plpgsql