Thread: Re: 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] 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

   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