search

davidbannon / libqt6pas

Unoffical repo for hopefully current LibQt6Pas libraries for Linux
16 stars 5 forks source link

libm.so.6(GLIBC_2.35)(64bit) requirement #3

Closed bogen85 closed 1 year ago

bogen85 commented 1 year ago

On Enterprise Linux 9 (RHEL, AlmaLinux, Rocky, etc) GLIBC_2.35 is not available.

$ sudo dnf install ./libqt6pas6-2.0-2.x86_64.rpm 
Last metadata expiration check: 1:14:08 ago on Fri 18 Nov 2022 09:17:14 PM CST.
Error: 
 Problem: conflicting requests
  - nothing provides libm.so.6(GLIBC_2.35)(64bit) needed by libqt6pas6-2.0-2.x86_64
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

EL9 is glibc-2.34, not glibc-2.35

$ rpm -qf /usr/lib64/libm.so.6
glibc-2.34-40.el9.x86_64
bogen85 commented 1 year ago

(In regard to the prebuilt releases)

bogen85 commented 1 year ago

I was able to build and create a usable RPM via alien. Tried it with CudaText.

davidbannon commented 1 year ago

Thats pretty weird. The deb depends on libc6 >= 2.14 and Alien is supposed to preserve such information. But I am finding Alien less and less useful here. I suspect its getting this talk about libc6 2.34 from the machine I am building it on. I already have to patch the spec file in half a dozen places, looks like it cannot even get dependencies right.

I have no idea why that is, going to have to do some research I am afraid. Maybe better to build an RPM from scratch but that means I have to do it on a RPM based machine.....

Hmm, quick google around and it seems alien is becoming abandon ware, some asking if its still being maintained, on its sourceforge page 3.5 years ago, no answer yet ! Not looking good. And I use alien on my project too !

Davo

bogen85 commented 1 year ago

I have no idea why that is, going to have to do some research I am afraid. Maybe better to build an RPM from scratch but that means I have to do it on a RPM based machine.....

I think all the rpm tools are available on Debian based distros.

I've done it in the past (built RPMs from non-RPM distros...), but it has been a while. And yeah, not an ideal approach... would be nice for standard tooling to just produce these.... (for example, qmake output Makefile recipes for deb and rpm...)

https://devops.stackexchange.com/questions/9116/is-it-possible-to-install-rpm-build-on-debian

https://www.unix.com/man-page/debian/8/RPMBUILD/

I was able to build and create a usable RPM via alien.

I just created a tarball based on what was built and converted it with alien into an rpm...

$ rpm -ql libQt6Pas-1-2.x86_64
/usr
/usr/lib/.build-id
/usr/lib/.build-id/69
/usr/lib/.build-id/69/48003522973c506aed1d1d289c622f6f434c06
/usr/lib64
/usr/lib64/libQt6Pas.so
/usr/lib64/libQt6Pas.so.6
/usr/lib64/libQt6Pas.so.6.2
/usr/lib64/libQt6Pas.so.6.2.0

However, I'm not sure why the .build-id stuff got in there.... I've looked at alien's intermediate before and tried to remove that kind of stuff....

Let me try unpacking what you are distributing and seeing if the specific GLIBC requirement indeed exists...

bogen85 commented 1 year ago 
$ fakeroot alien -t ./libqt6pas6-2.0-2.x86_64.rpm 
libqt6pas6-2.0.tgz generated

$ tar zxvf ../libqt6pas6-2.0.tgz 
./
./usr/
./usr/lib64/
./usr/lib64/libQt6Pas.so.6
./usr/lib64/libQt6Pas.so.6.2
./usr/lib64/libQt6Pas.so.6.2.0
./usr/share/
./usr/share/doc/
./usr/share/doc/libqt6pas6/
./usr/share/doc/libqt6pas6/changelog.gz
./usr/share/doc/libqt6pas6/copyright

$ ldd ./usr/lib64/libQt6Pas.so.6.2.0
ldd: warning: you do not have execution permission for `./usr/lib64/libQt6Pas.so.6.2.0'
./usr/lib64/libQt6Pas.so.6.2.0: /lib64/libm.so.6: version `GLIBC_2.35' not found (required by ./usr/lib64/libQt6Pas.so.6.2.0)
    linux-vdso.so.1 (0x00007ffcae38a000)
...

Yours does not have the extraneous build-id files, but it does have the GLIBC_2.35 requirement.

Enterprise Linux 8 won't be end of life until May 2029, and it is using GLIBC_2.28.

So, I don't think this is an alien per-se, it is the level of GLIBC being required.

GLIBC_2.35 is not even on the following page:

https://abi-laboratory.pro/?view=timeline&l=glibc

It seems to not have been updated this year... https://abi-laboratory.pro/

image

https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-library-handles-backward-compatibility

bogen85 commented 1 year ago

Debian 11 Buster (which I also sometimes run) was just released last year, and it is at 2.31

https://packages.debian.org/search?keywords=glibc&searchon=names&suite=bullseye&section=all https://packages.debian.org/search?keywords=glibc&searchon=names&suite=bullseye-updates&section=all

So the GLIBC_2.35 requirement won't affect only current RHEL based distros this decade, it will affect current Debian based distros this decade as well.

Like I said, I can rebuild and work around it, just as others will be able to do.

But that makes it more difficult for some in trying to run Lazarus apps with a qt6 dependency on their own installs...

Not everyone is running the latest Ubuntu or Fedora...

bogen85 commented 1 year ago

https://endoflife.software/operating-systems/linux/ubuntu image

So, the viable Ubuntu distros this decade are currently:

https://packages.ubuntu.com/search?keywords=glibc&searchon=names&suite=focal&section=all Ubuntu 22.04 is GLIBC_2.35 Ubuntu 20.04LTS is GLIBC_2.31 Ubuntu 18.04LTS is GLIBC_2.27

Ubuntu 18.04 LTS is not going to be viable for most all that much longer, but doing your current builds on that would target the most platforms. (if libqt6pas even builds on 18.04LTS...)

Building on Ubuntu 20.04LTS would likely produce viable DEBs for for Buster and viable RPMs for EL9 (but not EL8).

I assume you are building on Ubuntu 22.04? And that /usr/lib64/libQt6Pas.so.6.2.0 is getting its GLIBC_2.35 requirement from that?

bogen85 commented 1 year ago

Interesting... The libQt6Pas.so.6 I built via this project only depends on 2.14... (even though I have 2.34)

$ objdump -T /usr/lib64/libQt6Pas.so.6 | fgrep GLIBC | sed 's/.*GLIBC/GLIBC/' | sed -e 's/).*//' | cut -d' ' -f1 | sort -u
GLIBC_2.14
GLIBC_2.2.5
GLIBCXX_3.4

Where as the one you built depends on 2.35.

$ objdump -T ./usr/lib64/libQt6Pas.so.6 | fgrep GLIBC | sed 's/.*GLIBC/GLIBC/' | sed -e 's/).*//' | cut -d' ' -f1 | sort -u
GLIBC_2.14
GLIBC_2.2.5
GLIBC_2.35
GLIBC_2.4
GLIBCXX_3.4

I did not configure anything... I just cloned and ran the instructions from here: https://github.com/davidbannon/libqt6pas/tree/master/cbindings

qmake
make

And when the next steps failed, I just make a tarball of the library and symlinks and used alien to make an rpm from that...

bogen85 commented 1 year ago

So I extracted my tarball to an EL 8 machine: (The Qt6 libraries not available for EL 8 yet)

$ ldd ./usr/lib64/libQt6Pas.so.6.2.0 
    linux-vdso.so.1 (0x00007ffff11ea000)
    libQt6PrintSupport.so.6 => not found
    libQt6Widgets.so.6 => not found
    libQt6Gui.so.6 => not found
    libQt6Core.so.6 => not found
    libGLX.so.0 => /lib64/libGLX.so.0 (0x00007fcc8ae00000)
    libOpenGL.so.0 => /lib64/libOpenGL.so.0 (0x00007fcc8aa00000)
    libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fcc8a600000)
    libm.so.6 => /lib64/libm.so.6 (0x00007fcc8a200000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fcc89e00000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fcc89a00000)
    libX11.so.6 => /lib64/libX11.so.6 (0x00007fcc89600000)
    libXext.so.6 => /lib64/libXext.so.6 (0x00007fcc89200000)
    libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007fcc88e00000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007fcc88a00000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fcc88600000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fcc8b600000)
    libxcb.so.1 => /lib64/libxcb.so.1 (0x00007fcc88200000)
    libXau.so.6 => /lib64/libXau.so.6 (0x00007fcc87e00000)

Where as for yours I got the GLIBC version issue on EL9:

ldd ./usr/lib64/libQt6Pas.so.6.2.0 
ldd: warning: you do not have execution permission for `./usr/lib64/libQt6Pas.so.6.2.0'
./usr/lib64/libQt6Pas.so.6.2.0: /lib64/libm.so.6: version `GLIBC_2.35' not found (required by ./usr/lib64/libQt6Pas.so.6.2.0)
    linux-vdso.so.1 (0x00007ffc64eb2000)
    libQt6PrintSupport.so.6 => /lib64/libQt6PrintSupport.so.6 (0x00007fc1ee8cc000)
    libQt6Widgets.so.6 => /lib64/libQt6Widgets.so.6 (0x00007fc1ede00000)
    libQt6Gui.so.6 => /lib64/libQt6Gui.so.6 (0x00007fc1ed400000)
    libQt6Core.so.6 => /lib64/libQt6Core.so.6 (0x00007fc1ecc00000)
    libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fc1ec800000)
    libm.so.6 => /lib64/libm.so.6 (0x00007fc1edd25000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc1ee5e5000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fc1ec400000)
    libEGL.so.1 => /lib64/libEGL.so.1 (0x00007fc1ee5d3000)
    libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007fc1ed3b1000)
    libX11.so.6 => /lib64/libX11.so.6 (0x00007fc1ed269000)
    libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007fc1ecac6000)
    libQt6DBus.so.6 => /lib64/libQt6DBus.so.6 (0x00007fc1ec724000)
    libxkbcommon.so.0 => /lib64/libxkbcommon.so.0 (0x00007fc1ed224000)
    libGLX.so.0 => /lib64/libGLX.so.0 (0x00007fc1eca94000)
    libOpenGL.so.0 => /lib64/libOpenGL.so.0 (0x00007fc1edcfa000)
    libpng16.so.16 => /lib64/libpng16.so.16 (0x00007fc1eca5d000)
    libharfbuzz.so.0 => /lib64/libharfbuzz.so.0 (0x00007fc1ec655000)
    libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007fc1ec33c000)
    libz.so.1 => /lib64/libz.so.1 (0x00007fc1ee5b9000)
    libicui18n.so.67 => /lib64/libicui18n.so.67 (0x00007fc1ec000000)
    libicuuc.so.67 => /lib64/libicuuc.so.67 (0x00007fc1ebe15000)
    libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007fc1ebd37000)
    libdouble-conversion.so.3 => /lib64/libdouble-conversion.so.3 (0x00007fc1eca47000)
    libb2.so.1 => /lib64/libb2.so.1 (0x00007fc1ee5b0000)
    libpcre2-16.so.0 => /lib64/libpcre2-16.so.0 (0x00007fc1ebca8000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fc1ee95f000)
    libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007fc1ebbf0000)
    libxml2.so.2 => /lib64/libxml2.so.2 (0x00007fc1eba67000)
    libxcb.so.1 => /lib64/libxcb.so.1 (0x00007fc1ec62a000)
    libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fc1eb9ef000)
    libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007fc1eb99d000)
    libXext.so.6 => /lib64/libXext.so.6 (0x00007fc1eca32000)
    libgraphite2.so.3 => /lib64/libgraphite2.so.3 (0x00007fc1ec609000)
    libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fc1ec329000)
    libbrotlidec.so.1 => /lib64/libbrotlidec.so.1 (0x00007fc1ec31b000)
    libicudata.so.67 => /lib64/libicudata.so.67 (0x00007fc1e9e00000)
    liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fc1eb971000)
    libzstd.so.1 => /lib64/libzstd.so.1 (0x00007fc1e9d29000)
    liblz4.so.1 => /lib64/liblz4.so.1 (0x00007fc1eb94d000)
    libcap.so.2 => /lib64/libcap.so.2 (0x00007fc1eca28000)
    libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007fc1e9bec000)
    libgomp.so.1 => /lib64/libgomp.so.1 (0x00007fc1e9ba5000)
    libXau.so.6 => /lib64/libXau.so.6 (0x00007fc1ec315000)
    libbrotlicommon.so.1 => /lib64/libbrotlicommon.so.1 (0x00007fc1eb92a000)
    libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007fc1e9b7f000)

So it is being built different on my setup, and not requiring as high of a GLIBC version...

davidbannon commented 1 year ago

OK, sorry to slow you down bogen, I cannot keep up ! Here are a few observations, in no particular order. Maybe more "discussion".....

Davo

davidbannon commented 1 year ago

OK, some, inconclusive conclusions.

The spec file Alien makes does not include the dependencies list from the deb package. Probably a good thing, its wrong! So, calling rpmbuild must somehow trigger a scan of the contents and that determines what goes on that list for the rpm.

I have to assume its all determined by the machine its built on.

To support GLIBC 2.34, that means Ubuntu 21.10 (EOL), Fedora 35 (EOL in a month)

Sigh, I am downloading Fedora as we speak.

If you don't mind, I would like you to test what ever I make with you RH EL9 please ?

Davo

bogen85 commented 1 year ago

Oh, I'm not making any presumptions that this project support EL. :) I was mostly focusing on if this project (libqt6pas) could support older GlibC flavors, and my research into that kind of snowballed.... (I apologize for that, as this libqt6pas is your project).

I don't pay for RHEL support myself, I use the free clones, specially AlmaLinux. If need be until libqt6pas becomes supported in EPEL8/EPEL9 I'll fork this repo for that support.

But whatever general older GLIBC support this project can support, I'd really appreciate it.

I do use Fedora in some cases, and every 6 months if the particular install is still needed (if it was not short term test case) then I upgrade to the next release. (As fedora can be treated as semi rolling).

Yes, I will be happy to test whatever you make for RH EL9! Thanks for offering to support it!

davidbannon commented 1 year ago

Sorry, github auto closed because of a commit comment.

Davo

davidbannon commented 1 year ago

OK, repackaged versions there now ....

Davo

bogen85 commented 1 year ago

Thanks, this works with EL9! Which was really the reason for this issue report. I verified that this works with CudaText-qt6.

It has an older glibc requirement now. If qt6 were available on EPEL8 it would likely work. But since no qt6 for EPEL8, that is a moot point.

Now only a dependency on GLIBC_2.14 and older. Thanks!

$ objdump -T /usr/lib64/libQt6Pas.so.6.2 | fgrep GLIBC | sed 's/.*GLIBC/GLIBC/' | sed -e 's/).*//' | cut -d' ' -f1 | sort -u
GLIBC_2.14
GLIBC_2.2.5
GLIBCXX_3.4

I don't see any reason to keep this issue open now, so I'm closing it. Once again, thanks!

bogen85 commented 1 year ago

I installed fedora 37 in a VM and alien'ed the lintian package from Debian 11 Buster to an rpm and installed it.

I was able to build libqt6pas and run deb-package to create the RPMs needed for fedora 37.

I tried the same for AlmaLinux 9 (alien'ed the lintian package from Debian 11 Buster to an rpm and installed it). I was also able to build libqt6pas and run deb-package to create the RPMs needed for AlmaLinux 9.

When/If qt6 is available for AlmaLinux 8, I should be able to do the same.

Thanks for your support on this!

bogen85 commented 1 year ago

EL - I don't support EL, people pay a lot of money (I used to) to get EL and its support from Red Hat. Its not a case of I don't care, its just that I don't have EL, I cannot test it, if they have such old glibc, I am surprised they have Qt6 ! For people needing the Libary but unable to use the debs or rpms there, there is a plain tarball as part of the release, detailed instructions on how to manually install it. Should work on most current free Linuxes. But I cannot test on, eg, EL because I don't have it here. There was a time when I could make a valid test of EL suitability on CentOS but RedHat put an end to that.

As far as CentOS being dead, does not matter. The AlmaLinux and RockyLinux projects (and a few others) were created to replace the now dead CentOS, and those projects are doing very well. Additionally, CentOS stream, rolling upstream of RHEL, is still free. (current RHEL for less than 16 seats is free, even for commercial use).

I have no desire to use the paid for EL. Where I currently current work, RHEL is not required, so I've been using AlmaLinux.

davidbannon commented 1 year ago

bogen85, I am unsure what you are doing with Fedora 37, as I understand it, the rpms in the repo here 'should' work fine on F37. Are you finding that that is not the case ?

CentOS ? What was good about CentOS is that you test something on CentOS and then be sure it would work on EL. I would not feel so confident with startups like Alma and Rocky, maybe some time in the future ?

On one occasion, we actually built up quite a lot of large scale infrastructure on CentOS, then took out the extra RH licenses but never got around to "upgrading" those particular systems from CentOS to EL.

I consider RH's initial purchase of CentOS (some years ago) was a bit ingenuous. And the long term result inevitable. But there you go.

Anyway, thanks for your efforts here. Great example of how open source works to improve things !

Davo

salvadorbs commented 1 year ago

Sorry to enter this topic like this, but why not use rpm directly and not alien? https://stackoverflow.com/questions/59248180/how-to-install-rpmdev-tools-on-ubuntu

Edit: We can use libqt5pas spec file (http://packman.links2linux.org/package/lazarus/1032012) and adapt for libqt6pas. I haven't fedora to try it. http://wiki.links2linux.de/packman:faq_en#what_do_i_do_if_a_package_is_missing_a_feature_or_a_patch

bogen85 commented 1 year ago

@salvadorbs no need to apologize. Yeah, we should do that. Alien has lots of issues.

bogen85 commented 1 year ago

bogen85, I am unsure what you are doing with Fedora 37, as I understand it, the rpms in the repo here 'should' work fine on F37. Are you finding that that is not the case ?

@davidbannon Your RPMs are fine. When you had mentioned F35 I though you were running the deb-package from it... Had not read you updated instructions...

bogen85 commented 1 year ago

@salvadorbs

Sorry to enter this topic like this, but why not use rpm directly and not alien? https://stackoverflow.com/questions/59248180/how-to-install-rpmdev-tools-on-ubuntu

Agreed.

Edit: We can use libqt5pas spec file (http://packman.links2linux.org/package/lazarus/1032012) and adapt for libqt6pas. I haven't fedora to try it. http://wiki.links2linux.de/packman:faq_en#what_do_i_do_if_a_package_is_missing_a_feature_or_a_patch

Yes, we need to come up with cross distro ways of doing this, both for what is "released" in places like this project, but for others to make their own releases for their distros (if not 100% supported in projects like this)

bogen85 commented 1 year ago

@davidbannon

Anyway, thanks for your efforts here. Great example of how open source works to improve things !

Thank you for all your work on this! Although I feel I need to bit more proactive on this myself... (And set up some GH actions and runners to auto build various FPC/Lazrarus related RPMs)

I really appreciate your stepping up to plate to make these Qt6 Pascal packages available!

davidbannon commented 1 year ago

Salvador, the spec file is trivial, if you look in the script I use to package, (misnamed) deb_package, you will see I pull apart a deb with Alien, all that does is build a BUILD dir with three or four files in place and generates a spec file. Then I do a lot of editing of that spec file and rebuild with rpmbuild.

Put a exit in my script just after the alien call and you will see all the rpm content, ready to fiddle with. Or if you jus want to see the spec file, uncomment lines 168 and 176 ....

After fixing up the spec file, its all rebuilt with rpmbuild.

I am planning, with my own project, to grab that spec file, setup some replaceable vars (for sed to play with, arch, bitness etc) and use that approach directly. It will reduce the dependency (and vagueness) on Alien.

But I am not all that sure that libqt6pas will need to be rebuilt so many times that its worth the effort however. Based on libQt5pas, Z only changed that twice in the time I have had libqt5pas here ....

Davo

salvadorbs commented 1 year ago

Anyway, I want to try building and package libqt6pas on Ubuntu 20.04 in github actions. In ubuntu 20.04 there is no qt6 packages, so I added a qt6 backports repo.

Building is ok (I guess), but rpm process no. If you want, logs are here.

davidbannon commented 1 year ago

Hmm, it turns out that it needs to be packaged on (eg) U20.04 ! U22.04 has a new dpkg and it uses a compression scheme, zstd, that all Debian dpkg refuse to use !

I am up to the fifth repackage !

Note, you do not need Qt6 installed to package the library, just to build it.

Davo

salvadorbs commented 1 year ago

Note, you do not need Qt6 installed to package the library, just to build it.

Really? Ops... Thanks!

Hmm, it turns out that it needs to be packaged on (eg) U20.04 ! U22.04 has a new dpkg and it uses a compression scheme, zstd, that all Debian dpkg refuse to use !

Great! 😞

davidbannon commented 1 year ago

OK Salvador, I think we are looking at this the wrong way. Its silly trying to automate the build - package workflow because it needs to be manually synced with the main in gitlab first. When I do that, manually, its not that hard to generate the binary and dead easy to package. The problem that we are ignoring is, Z is changing the interface, twice in the last few days and I am not spotting that.

A far better approach, IMHO, would be for your workflow to generate a new binary, ie the library, every time he makes a change to the Qt6Pas.Pro file. Now, people who must have the latest can get the library themselves, its the output of your workflow. If they are playing at the cutting edge, its not that hard to manually install the library, I have detailed instructions on the site here. So, thats useful right away.

And, maybe your workflow, at the end, sends me an email saying, "Salvador's workflow has generated a new binary" and I'd either do the packaging manually or, we'd trigger a separate, different workflow that can build the packages.

Sounds like you can make the binary already, all we need to do is figure out how to get your workflow access to the necessary files and know when it needs to do its stuff. In the old days, I'd just wget Qt6Pas.Pro to my server, check its checksum and if its changed, download just the cbindings directory and compile away.

Easy to script, is it easy for you to turn into a github workflow ? Maybe run every 2 hours ?

RE your problems with the RPM packaging, I think I need to rewrite that and remove the dependency on alien. Its days are over. Should be easy but right now, we should concentrate on the other end of the process.

Davo

davidbannon commented 1 year ago

this thread is far to useful to leave closed .....

davidbannon commented 1 year ago

Actually, sorry, I should not have reopened this ticket, bogan is probably not interested and title is misleading. I'll close it again, and repost my above missive in a new thread. Davo