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

On 2025-Mar-06, PG Bug reporting form wrote:

The following bug has been logged on the website:

Bug reference: 18833
Logged by: Bruno Friedmann
Email address: bruno@ioda-net.ch
PostgreSQL version: 17.4
Operating system: rhel 9.5
Description:

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

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
```

--
Á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)

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

On mardi, 11 mars 2025 03.21:13 h heure normale d’Europe centrale Devrim
Gündüz wrote:

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-ve
rsioning.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,

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)

On 2025-Mar-11, Bruno Friedmann wrote:

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.

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

Re: Bruno Friedmann

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.

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

Christoph

On mardi, 11 mars 2025 10.11:27 h heure normale d’Europe centrale Álvaro
Herrera wrote:

On 2025-Mar-11, Bruno Friedmann wrote:

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.

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.

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.

--
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

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:

On 2025-Mar-11, Bruno Friedmann wrote:

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.

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.

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.

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

On mardi, 11 mars 2025 12.03:08 h heure normale d’Europe centrale Laurenz Albe
wrote:

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:

On 2025-Mar-11, Bruno Friedmann wrote:

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.

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.

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.

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

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.

--
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

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

Am 11.03.25 um 11:13 schrieb Christoph Berg:

Is this only hitting Bareos and not every other application
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]https://www.postgresql.org/docs/current/libpq-example.html -- Andreas Rogge andreas.rogge@bareos.com Bareos GmbH & Co. KG Phone: +49 221-630693-86 http://www.bareos.com 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 andreas.rogge@bareos.com Bareos GmbH & Co. KG Phone: +49 221-630693-86 http://www.bareos.com
--
Andreas Rogge andreas.rogge@bareos.com
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

Am 11.03.25 um 13:44 schrieb Laurenz Albe:

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?

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
--
Andreas Rogge andreas.rogge@bareos.com
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

Hi,

On Tue, 2025-03-11 at 18:36 +0100, Andreas Rogge wrote:

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.

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

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

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
--
Andreas Rogge andreas.rogge@bareos.com
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

Hi,

On Wed, 2025-03-12 at 15:55 +0100, Andreas Rogge wrote:

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?

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,
--
Devrim Gündüz
Open Source Solution Architect, PostgreSQL Major Contributor
Twitter: @DevrimGunduz , @DevrimGunduzTR