When trying to build work in progress on bug 1654112:

https://treeherder.mozilla.org/jobs?repo=try&revision=0547d4557bb6a1450d38be671ca7d1fab90371a4&selectedTaskRun=NN205MZgQaeOJlKbHH13gw.0

Looks like XRRMonitorInfo was added in libxrandr 1.5

https://gitlab.freedesktop.org/xorg/lib/libxrandr/commit/4437436906cbba5121115e552d564262e8b4c784

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?

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

docker pull debian:jessie-20200422
docker run -it c6e91fa21856
dpkg-query -l | grep libxrandr
> not found

Hm, wondering whether :glandium has an idea of this?

(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&section=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)

Before doing anything, we need to survey the currently supported distros to know whether they all have xrandr >= 1.5.

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

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

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

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

The test images are based on Ubuntu 18.04, which has libxrandr 1.5.1

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

You can add a wrapper header that defines what you need and does #include_next <original_header.h>

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.

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.

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

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.

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

No. It's unlikely to happen soon.