From: | Mankirat Singh <mankiratsingh1315(at)gmail(dot)com> |
---|---|
To: | "David E(dot) Wheeler" <david(at)justatheory(dot)com>, Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: ABI Compliance Checker GSoC Project |
Date: | 2025-06-04 13:11:37 |
Message-ID: | CAOtk82S99vMnLWcy61JZKzCEH4QL_34oA4_fJg6rJkyk2mmaDw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 3 Jun 2025 at 23:50, David E. Wheeler <david(at)justatheory(dot)com> wrote:
> >> Ummm, are you saying that it complains about changes to unexported
> >> symbols also?
>
> This is a good question.
No, it doesn’t complain about unexported symbols.
But it does complain about some exported symbols that, in my understanding,
shouldn’t be flagged.
This led me to a related question (which I had raised earlier too):
I initially assumed that the Postgres binary includes exported symbols that
are internal implementation functions - like _bt_pagedel(), as mentioned in
here[1] - and symbols like these should ideally be suppressed.
Is that correct?
If so, how do we reliably identify such internal but exported symbols?
There doesn't seem to be a consistent naming convention or regular
expression that we can use to suppress many of them at once.
> What’s the error? Maybe we can fix it.
As per my knowledge Postgres internal code lacks visibility annotations on
its symbols, which causes compilation errors when fvisibility flag is used.
Adding these annotations to the codebase could not be done in a few days
only.
Regards,
Mankirat
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2025-06-04 13:18:36 | Re: Speedup truncations of temporary relation forks |
Previous Message | Xuneng Zhou | 2025-06-04 12:59:50 | Request to Expedite Account Activation Cool-Off Period |