Need a more recent version (>= 1.5) of libxrandr on linux build machines
Categories
(Release Engineering :: General, task)
Tracking
(Not tracked)
People
(Reporter: bwc, Unassigned)
References
(Blocks 2 open bugs)
Details
When trying to build work in progress on bug 1654112:
Looks like XRRMonitorInfo was added in libxrandr 1.5
https://gitlab.freedesktop.org/xorg/lib/libxrandr/commit/4437436906cbba5121115e552d564262e8b4c784
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Not sure what's going on here. Seems like the only docker image that explicitly installs that is https://searchfox.org/mozilla-central/source/taskcluster/docker/valgrind-build/Dockerfile#51 which seems not related to this. Also, digging in the aforementioned freedesktop - the 1.5 version is like ~6years old. I'd assume that reasonably recent distros have that. Unless this is somehow installed implicitly somewhere, I don't really understand how come is failing now.
Question is, what's on the build machine?
Comment 2•4 years ago
|
||
Looking at the ASAN job, it seems like it's using the docker-image-debian8-amd64-build
image which is defined here and uses at its turn https://searchfox.org/mozilla-central/source/taskcluster/ci/docker-image/kind.yml#54 which uses https://searchfox.org/mozilla-central/source/taskcluster/ci/docker-image/kind.yml#32.
The latest one has:
BASE_IMAGE: debian:jessie-20200422
DIST: jessie
SNAPSHOT: '20200422T205110Z'
This seems like a recent image so unclear what's goingon, unless the version is pinned somewhere under the hood in that docker image
Comment 3•4 years ago
|
||
docker pull debian:jessie-20200422
docker run -it c6e91fa21856
dpkg-query -l | grep libxrandr
> not found
Comment 4•4 years ago
|
||
Hm, wondering whether :glandium has an idea of this?
Comment 5•4 years ago
|
||
(In reply to Mihai Tabara [:mtabara]⌚️GMT from comment #2)
Looking at the ASAN job, it seems like it's using the
docker-image-debian8-amd64-build
image which is defined here and uses at its turn https://searchfox.org/mozilla-central/source/taskcluster/ci/docker-image/kind.yml#54 which uses https://searchfox.org/mozilla-central/source/taskcluster/ci/docker-image/kind.yml#32.The latest one has:
BASE_IMAGE: debian:jessie-20200422 DIST: jessie SNAPSHOT: '20200422T205110Z'
This seems like a recent image so unclear what's goingon, unless the version is pinned somewhere under the hood in that docker image
I downloaded the image from https://firefox-ci-tc.services.mozilla.com/tasks/HTd2uCT1R5-KJz_y7lgVvQ, and found:
root@17b80eb35a31:~# dpkg -l | grep randr
ii libxrandr-dev:amd64 2:1.4.2-1+deb8u1 amd64 X11 RandR extension library (development headers)
ii libxrandr2:amd64 2:1.4.2-1+deb8u1 amd64 X11 RandR extension library
ii x11proto-randr-dev 1.4.0-2 all X11 RandR extension wire protocol
xrandr is not in its parent image though (https://firefox-ci-tc.services.mozilla.com/tasks/DweCY6mQQ5eIuRYnYcA1ZA).
So, this is coming in as an indirect dependency to something being installed, but ultimately the problem is that this is using debian jessie, which only has libxrandr 1.4.2, per https://packages.debian.org/search?suite=jessie§ion=all&arch=any&searchon=names&keywords=libxrandr
We either need a backport of 1.5, or to upgrade the image being used here to a newer version (presumably stretch or buster)
Comment 6•4 years ago
|
||
Before doing anything, we need to survey the currently supported distros to know whether they all have xrandr >= 1.5.
Comment 7•4 years ago
|
||
So, in this specific case, the imported code needs at least one header from a newer version, but actually doesn't look like it requires a new version to link against,because the required symbols are dlsym'ed.
IOW, in this specific case, the better thing to do would be to vendor the one header that defines XRRMonitorInfo, or, probably better, add a sufficient definition of XRRMonitorInfo inline (AFAICT, you don't even need all the fields, only up to height).
Comment 8•4 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #7)
So, in this specific case, the imported code needs at least one header from a newer version, but actually doesn't look like it requires a new version to link against,because the required symbols are dlsym'ed.
IOW, in this specific case, the better thing to do would be to vendor the one header that defines XRRMonitorInfo, or, probably better, add a sufficient definition of XRRMonitorInfo inline (AFAICT, you don't even need all the fields, only up to height).
Just to confirm, are you able to unblock yourself here by adding the header to the webrtc source?
Comment 9•4 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #7)
So, in this specific case, the imported code needs at least one header from a newer version, but actually doesn't look like it requires a new version to link against,because the required symbols are dlsym'ed.
IOW, in this specific case, the better thing to do would be to vendor the one header that defines XRRMonitorInfo, or, probably better, add a sufficient definition of XRRMonitorInfo inline (AFAICT, you don't even need all the fields, only up to height).
Forgot to mention, thanks :glandium for your input!
Reporter | ||
Comment 10•4 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #7)
So, in this specific case, the imported code needs at least one header from a newer version, but actually doesn't look like it requires a new version to link against,because the required symbols are dlsym'ed.
IOW, in this specific case, the better thing to do would be to vendor the one header that defines XRRMonitorInfo, or, probably better, add a sufficient definition of XRRMonitorInfo inline (AFAICT, you don't even need all the fields, only up to height).
Do the tester images have the relevant symbols? If we are dlsym'ing stuff in the wild, I want to make sure we can pull in the same thing on our testers.
Comment 11•4 years ago
|
||
The test images are based on Ubuntu 18.04, which has libxrandr 1.5.1
Reporter | ||
Comment 12•4 years ago
|
||
Ok, I can probably hack in the stuff from the headers, although it would be nice to not need to do that long term (we'd need to re-do this every time we update our import of libwebrtc).
Comment 13•4 years ago
|
||
You can add a wrapper header that defines what you need and does #include_next <original_header.h>
Comment 14•3 years ago
|
||
Hi! Given that Debian Jessie is EOL for a while now, are there any plans to switch t Debian 9 and update the libxandr requirement to 1.5?
I'm asking because:
- libxandr 1.5 would be nice in other areas as well, see e.g. bug 1732436 (which ended up raising the minimum requirement to 1.4)
- having a more up-to-date WebRTC would make several Wayland/Pipewire related developments much easier (bug 1729743 / bug 1724900). Backporting upstream Pipewire features is probably not helping with updating efforts :/
Some additional notes:
- Ubuntu 16.04 is EOL as well, thus moving to Debian 9 (2017) would not break any supported Ubuntu version
- RHEL/CentOS 7 apparently got an update to libxandr 1.5.1 (https://git.centos.org/rpms/libXrandr/releases)
Bug 1726117 added Debian 11 to our toolchain. libxandr
should now be greater than 1.5. I'm closing this bug as a duplicate but feel free to reopen it if you see otherwise.
Comment 16•1 year ago
|
||
At least in building libwebrtc, we're picking up Xrandr.h from .mozbuild/sysroot-x86_64-linux-gnu/usr/include/X11/extensions/Xrandr.h which doesn't seem to have the updated header. I'm going to re-open this bug while waiting for our sysroot to get an update.
Comment 17•1 year ago
|
||
Mike, should our sysroot still have the older version of Xrandr.h?
The Xrandr files I see in my newly re-downloaded sysroot:
./usr/include/X11/extensions/Xrandr.h
./usr/lib/x86_64-linux-gnu/libXrandr.so.2.2.0
./usr/lib/x86_64-linux-gnu/pkgconfig/xrandr.pc
./usr/lib/x86_64-linux-gnu/libXrandr.so
./usr/lib/x86_64-linux-gnu/girepository-1.0/xrandr-1.3.typelib
./usr/lib/x86_64-linux-gnu/libXrandr.so.2
./usr/lib/x86_64-linux-gnu/libXrandr.a
Comment 18•1 year ago
|
||
Our sysroot is still based on Debian 8, and can't be updated to Debian 9 yet, because that would bump e.g. our glibc requirement.
Comment 19•1 year ago
|
||
(In reply to Mike Hommey [:glandium] from comment #18)
Our sysroot is still based on Debian 8, and can't be updated to Debian 9 yet, because that would bump e.g. our glibc requirement.
Is there a bug to track the sysroot update to Debian 9?
Description
•