Subject: BUG #18833: libpq.so doesn't contain declared symbol in rpm --provides

From: PG Bug reporting form <[email-masked]>
Date: Thu, 06 Mar 2025 10:16:12 +0000

The following bug has been logged on the website:

Bug reference:      18833
Logged by:          Bruno Friedmann
Email address:      [email-masked]
PostgreSQL version: 17.4
Operating system:   rhel 9.5
Description:        

if you check the following
```
rpm -q libpq5 --provides
libpq >= 10.0
libpq.so.5
libpq.so.5()(64bit)
libpq.so.5(RHPG_10)(64bit)
libpq.so.5(RHPG_11)(64bit)
libpq.so.5(RHPG_12)(64bit)
libpq.so.5(RHPG_13)(64bit)
libpq.so.5(RHPG_14)(64bit)
libpq.so.5(RHPG_15)(64bit)
libpq.so.5(RHPG_9.6)(64bit)
libpq5 = 17.4-1PGDG.rhel9
libpq5(x86-64) = 17.4-1PGDG.rhel9
postgresql-libs >= 9.2
```

You find that you are 100% similar (extended to certain version) to what is
provided as operating system
```
rpm -q libpq --provides
libpq = 13.20-1.el9_5
libpq(x86-64) = 13.20-1.el9_5
libpq.so.5()(64bit)
libpq.so.5(RHPG_10)(64bit)
libpq.so.5(RHPG_12)(64bit)
libpq.so.5(RHPG_13)(64bit)
libpq.so.5(RHPG_9.6)(64bit)
postgresql-libs = 13.20-1.el9_5
```

This should allow a software build against rhel libpq-devel to be satisfied
with pgdg packaged libpq
but the following message appears like the following
```
bareos-dir: /usr/pgsql-14/lib/libpq.so.5: no version information available
(required by /usr/lib64/bareos/libbareossql.so.24)
```

when you use strings on both library, pgdg doesn't contains the expected
symbol
pgdg
```
strings /usr/lib64/libpq.so.5 | grep RHPG
```
versus
rhel 13.20
```
strings /usr/lib64/libpq.so.5 | grep RHPG
RHPG_9.6
RHPG_10
RHPG_12
RHPG_13
```

---

From: Álvaro Herrera <[email-masked]>
Date: Mon, 10 Mar 2025 18:08:35 +0100

> Operating system:   rhel 9.5

It's been suggested that this belongs in the pgsql-pkg-yum mailing list.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"Linux transformó mi computadora, de una `máquina para hacer cosas',
en un aparato realmente entretenido, sobre el cual cada día aprendo
algo nuevo" (Jaime Salinas)

---

From: Devrim Gündüz <[email-masked]>
Date: Tue, 11 Mar 2025 05:21:13 +0300

Hi,

On Mon, 2025-03-10 at 18:08 +0100, Álvaro Herrera wrote:
> This should allow a software build against rhel libpq-devel to be
> satisfied with pgdg packaged libpq

I don't think so. I think Red Hat adds a small patch to libpq package:

https://src.fedoraproject.org/rpms/libpq/blob/rawhide/f/libpq-12.1-symbol-versioning.patch

<rant>PGDG packages are PostgreSQL compatible. Red Hat packages are Red
Hat compatible.</rant>

> bareos-dir: /usr/pgsql-14/lib/libpq.so.5: no version information
> available (required by /usr/lib64/bareos/libbareossql.so.24)

That said, IIRC this message means bareos did not build their packages
against our libpq. 

-HTH

Regards,
-- 
Devrim Gündüz
Open Source Solution Architect, PostgreSQL Major Contributor
Twitter: @DevrimGunduz , @DevrimGunduzTR

---

From: Bruno Friedmann <[email-masked]>
Date: Tue, 11 Mar 2025 09:23:10 +0100

On mardi, 11 mars 2025 03.21:13 h heure normale d’Europe centrale Devrim 
> That said, IIRC this message means bareos did not build their packages

Here the situation, if I didn't explain it correctly.

We (Bareos dev's team) build our software on what's distributed by the OS 
editor. which means for RHEL9 libpq5-devel 13.20 (rhel)

From time to time people want (for good reasons :-) ) use pgdg binaries,

if you go that way libpq from pgdg is installed and as the rpm provides all RH 
symbol you will get only this.

The problem is: if the rpm provides the symbol the pgdg libpq build is not 
providing them. As such any software that try to use that "pseudo" compatible 
lib doesn't find the searched symbol and emit in the least worse case a 
warning.

I (we) believe that the patch now included in fedora, is the way to go, if 
100% ABI compatible is still a moto for pgdg.

Please no offense on that, it's just really better for either consumer of pgdg 
software in redhat/rpm world whatever they are: software editor, end users.

Regards.

-- 
Bruno Friedmann
 Ioda-Net Sàrl www.ioda-net.ch
   expertise en open-source

 GPG KEY: E4720D8715B696B4 
 irc: tigerfoot
Computing freedom with openSUSE Tumbleweed - 20250307
Linux 6.13.5-1-default x86_64 GNU/Linux, nvidia: 
 ,   , Plasma: 6.3.2, kmail2 6.3.3 (24.12.3)

---

From: Álvaro Herrera <[email-masked]>
Date: Tue, 11 Mar 2025 10:11:27 +0100

> symbol you will get only this.

Wouldn't this be solved if you built your software using the PGDG
packages instead?  That should be compatible with both the PGDG _and_
the RH packages.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
 Are you not unsure you want to delete Firefox?
       [Not unsure]     [Not not unsure]    [Cancel]
                   http://smylers.hates-software.com/2008/01/03/566e45b2.html

---

From: Christoph Berg <[email-masked]>
Date: Tue, 11 Mar 2025 11:13:15 +0100

Re: Bruno Friedmann
> symbol you will get only this.

Is this only hitting Bareos and not every other application
distributed by RH itself? If so, why?

Christoph

---

From: Bruno Friedmann <[email-masked]>
Date: Tue, 11 Mar 2025 11:58:49 +0100

On mardi, 11 mars 2025 10.11:27 h heure normale d’Europe centrale Álvaro 
Herrera wrote:
> > if you go that way libpq from pgdg is installed and as the rpm provides
> > all RH symbol you will get only this.
> 

And why we would do that ? pgdg is an additional third repository.
We have to build binaries that will work out of the box from the software 
vendor with restricted possibility. which is what we do.

---

From: Laurenz Albe <[email-masked]>
Date: Tue, 11 Mar 2025 12:03:08 +0100

On Tue, 2025-03-11 at 11:58 +0100, Bruno Friedmann wrote:
> On mardi, 11 mars 2025 10.11:27 h heure normale d’Europe centrale Álvaro Herrera wrote:

But that is exactly the idea.  Build against the PGDG packages, then
the binaries should work out of the box with the Redhat packages as well.

Are you trying to make things work or is this a matter of principle?

Yours,
Laurenz Albe

---

From: Bruno Friedmann <[email-masked]>
Date: Tue, 11 Mar 2025 13:36:53 +0100

On mardi, 11 mars 2025 12.03:08 h heure normale d’Europe centrale Laurenz Albe 
> Are you trying to make things work or is this a matter of principle?

Ha ha that's just the reverse that should happen.

PGDG is claiming 100% ABI compatibility, which has been proved here that's not 
the case and all this bug is about this.

If you don't care, me neither, we detected that, we reported it, you decide.

As an editor POV we certainly don't want to build from 3rd parties, except 
when customer are paying for that specific.

So for us the situation is clear, before the symbol version was introduced in 
Fedora/Rhel our customer were able to use transparently as the software didn't 
complain pgdg repository at their convenience.

Now that system libraries are build with symbol version, and our lib depend on 
those to be present due the build itself, the pgdg might be usable but without 
any warranties. And we advertise people to better stick to module proposed by 
the OS editors.

I'm not yet sure what kind of impact those symbol check will have for any 
software build against system libs in Fedora/Redhat and then used with pgdg 
lib. I guess the same warning will be emitted each time.

Regards.

---

From: Laurenz Albe <[email-masked]>
Date: Tue, 11 Mar 2025 13:44:55 +0100

On Tue, 2025-03-11 at 13:36 +0100, Bruno Friedmann wrote:
> PGDG is claiming 100% ABI compatibility, which has been proved here
> that's not the case and all this bug is about this.

Are we claiming that?

Let me get that straight: you are requesting from the PostgreSQL
project that the binaries that they build for their own software
should be drop-in replacements for PostgreSQL packages that somebody
else builds.  Interesting.  I thought it should be the other way
around, if anything.

But we seem to have left the grounds of "let's make things work",
so I'll stop here.

Yours,
Laurenz Albe

---

From: Andreas Rogge <[email-masked]>
Date: Tue, 11 Mar 2025 18:25:18 +0100

> distributed by RH itself? If so, why?

That depends on what you call "hitting".
As far as I can tell the warning messsage
"/lib64/libpq.so.5: no version information available (required by ...)"
is emitted by ld.so for everything that was linked at build-time to 
redhat's version of libpq and then run with pgdg's libpq5.

In in a fresh rhel9 ubi container you can do the following:

# dnf install rhel-9-x86_64/pgdg-redhat-repo-42.0-46PGDG.noarch.rpm
# dnf install libpq5
# dnf install postfix-pgsql
# ldd /usr/lib64/postfix/postfix-pgsql.so
(here you'll see the message)

It seems like you will not see the warning message in postfix, because 
postfix-pgsql.so is loaded using dlopen(). When dynamic linking occurs 
during dlopen() ld.so will not write a message to stderr, of course.

It looks like most (if not all) of the things in the rhel repos that 
link to libpq are plugins that will be loaded with dlopen(). At least I 
couldn't quickly find any program that directly links to libpq.

Nevertheless, the problem Bareos hits can be reproduced easily:
1. set up a rhel9 system without PGDG
2. install compiler + libpq-devel
3. build "libpq Example Program 1" [1] and link with RH's libpq
4. move resulting program to a system with libpq5 from PGDG and run it

When libpq is dynamically linked during initial program setup by ld.so, 
you will see the warning message.

Best Regards,
Andreas

[1] https://www.postgresql.org/docs/current/libpq-example.html
-- 
Andreas Rogge                             [email-masked]
   Bareos GmbH & Co. KG                      Phone: +49 221-630693-86
   http://www.bareos.com

   Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
   Komplementär: Bareos Verwaltungs-GmbH
   Geschäftsführer: Stephan Dühr, Jörg Steffens, Philipp Storz

---

From: Andreas Rogge <[email-masked]>
Date: Tue, 11 Mar 2025 18:36:42 +0100

>> that's not the case and all this bug is about this.
I don't know what you claim, but your libpq5 RPM claims that the 
contained libpq.so.5 has versioned symbols for versions RHPG_9.6, 
RHPG_10, [...] and RHPG_15 while the contained library doesn't have these.
When a package says it provides something and then doesn't, I call that 
a broken package.

Best Regards,
Andreas

---

From: Devrim Gündüz <[email-masked]>
Date: Wed, 12 Mar 2025 17:32:00 +0300

Hi,

On Tue, 2025-03-11 at 18:36 +0100, Andreas Rogge wrote:
> When a package says it provides something and then doesn't, I call
> that  a broken package.

We don't provide versioned *symbols*. It is just provides. Why would we
match Red Hat packaging?

Regards,

---

From: Andreas Rogge <[email-masked]>
Date: Wed, 12 Mar 2025 15:55:56 +0100

Am 12.03.25 um 15:32 schrieb Devrim Gündüz:
> We don't provide versioned *symbols*.
That's correct.

 > It is just provides.
Is it also "just dependencies"? We all know that stuff is there for a 
reason.

 > Why would we match Red Hat packaging?
That's exactly what I'm asking: How did you end up with these provides? 
Why did someone manually add these to the SPEC if it was not to match 
the Red Hat package?

Best Regards,
Andreas

---

From: Devrim Gündüz <[email-masked]>
Date: Thu, 13 Mar 2025 13:08:13 +0300

Hi,

> Why did someone manually add these to the SPEC if it was not to match 

Again, provides is something that *I* added so that I can override the
OS packages for the PGDG repo users. It works one way.

Regards,