Thanks for the PR. I've started testing the update in my COPR [1], and due to the SONAME change, I also have to check that the packages depending on libpqxx also build. As far as I'm aware, this is only vfrnav, but this is currently failing [2] with the following libtool error messages:

../libtool: line 6000: cd: lib64: No such file or directory
libtool: link: cannot determine absolute directory name of `lib64'

I'm not yet sure if this is an issue with vfrnav or something else, but it looks like perhaps there is an -Llib64 link argument which shouldn't be there when linking vfrdbsrtmwatermask.

[1] https://copr.fedorainfracloud.org/coprs/mkrupcale/libpqxx/
[2] https://copr.fedorainfracloud.org/coprs/mkrupcale/libpqxx/build/2332920/

I believe I found the issue. The -Llib64 is coming from the minizip pkg-config file, which is a dependency of zfstream. I've sent upstream a PR [1]. This patch could be applied downstream in Fedora provided/until upstream resolves the issue. Once that happens, libpqxx and vfrnav can be built together in a side tag and then merged into rawhide.

[1] https://github.com/zlib-ng/minizip-ng/pull/584

Thanks for the PR. I've started testing the update in my COPR [1], and due to the SONAME change, I also have to check that the packages depending on libpqxx also build. As far as I'm aware, this is only vfrnav, but this is currently failing [2] with the following libtool error messages:

../libtool: line 6000: cd: lib64: No such file or directory libtool: link: cannot determine absolute directory name of `lib64'

I'm not yet sure if this is an issue with vfrnav or something else, but it looks like perhaps there is an -Llib64 link argument which shouldn't be there when linking vfrdbsrtmwatermask.

This has been fixed by minizip-3.0.2-4 in F34+.

Merged with https://src.fedoraproject.org/rpms/libpqxx/c/db6624aa7099077a9f61ec882c6dd93296406f3e?branch=rawhide

Thanks @besser82 for applying the patch to minizip. Unfortunately, this PR is already outdated because upstream has released v7.6.0[1]. So I'll have to test that before doing any official builds.

[1] https://github.com/jtv/libpqxx/releases/tag/7.6.0

@mkrupcale I've already triggered chain-builds for v7.5.2, FYI.

The build for F35 fails for some problems with macros in redhat-rpm-config, but should be fine once that has been fixed.

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=74014153
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=74014149

I'm currently running a test build with v7.6.0 in COPR:

https://copr.fedorainfracloud.org/coprs/besser82/libpqxx_test/

@besser82 Okay, thanks. I'll take a look at v7.6.0 hopefully this week or weekend, and hopefully the redhat-rpm-config macros get fixed in the mean time.

The comparision of 7.5.2 to 7.6.0 doesn't show any obvious incompatible or troublesome changes: https://github.com/jtv/libpqxx/compare/7.5.2...7.6.0

Besides the API change for the removed conversion routine of course.

Looks like vfrnav fails for some changes in libftdi now. Anyways, updating libpqxx to v7.6.0 should be safe. I'll take care of it as soon as I get vfrnav to build successfully again.

Okay, thanks for looking into that :smile:

Successful rebuilds of vfrnav against libpqxx-7.6.0.

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=74022196
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=74023912

Great, thank you for working on this. Are you interested in being a co-maintainer of libpqxx? Or did you just happen to see this issue?

Sure, I'd like to co-maintain libpqxx.

Cool, just added you as an admin.

Thank you! =)

Certainly, thank you for helping!