libepoxy @1.15.10_4+x11+egl: error: use of undeclared identifier 'RTLD_NEXT'

[GwynethLlewelyn (Gwyneth Llewelyn)]

Hi there!

On macOS Tahoe 26.2 on an M1 MacBook Pro, I was trying to install colima, which in turn requires qemu, which at some point needs libepoxy — but with both variants +x11+egl active. So far, other installed ports only required +x11 as a variant. In all cases, libepoxy has to be compiled from scratch.

After cleaning up libepoxy to add the 'missing' variant afterwards, doing a sudo port install libepoxy +x11+egl results in a failed compilation (see attached log). The culprit is the missing dlvsym() function. The libepoxy code contains some wraparound code to deal with these issues, and versions 3 and 4 of the Portfile (e.g., commit 0428ef95 by @Lord-Kalima) already add the required changes (and, as far as I'm able to, they seem to be correctly implemented).

Nevertheless, the generated header files for two of the tests will ignore (?) these changes. These are egl_gles1_without_glx and egl_gles2_without_glx — they will fail with an error on line ±69, dlopen_unwrapped = dlsym(RTLD_NEXT, "dlopen") complaining that RTLD_NEXT does not exist.

Of course it does, and it's supposed to be defined thanks to the mentioned patches on revisions 3 and 4, but the truth is that... it doesn't work.

Please mind that I'm quite unfamiliar with all these tools and how they tie together; my humble origins in programming C/C++ are from a simple era, when all you had was a Makefile 😂. This means that surely there is a more elegant way to 'fix' it, but, as it stands, my 'solution' was simply to remove those two tests, both from the build.ninja and the compile_commands.json file, run sudo ninja again, and sudo ninja installed. This results in a clean compilation (obviously, since the tests don't run...) and 'fixes' the compilation issue, although, of course, if the tests are present, it's because they're important!

Interestingly — and I couldn't exactly duplicate this — you can cleanly compile & install +egl variant by itself (as said, in my case, due to other dependent ports, variant +x11 was already compiled).

What I did was to install libepoxy +x11 first (after uninstalling and cleaning the port, of course). Then I tried to add sudo install libepoxy +egl+x11 which fails. I compiled the dumped code manually as described, ninja-installed it, and then forced the activation with sudo port -f activate libepoxy +x11+egl (heh). Of course, MacPorts correctly flags this error: Error: port activate failed: Registry error: libepoxy not registered as installed. — no surprises here.

So I tried to install +egl on its own. Surprisingly (to me!), this works: sudo port install libepoxy +egl (which I know that will compile by itself).

However, on the last step, MacPorts correctly identifies that there is at least one previous header file which did not come from this package, and aborts:

Error: Failed to activate libepoxy: Image error: /opt/local/include/epoxy/common.h already exists and does not belong to a registered port.  Unable to activate port libepoxy. Use 'port -f activate libepoxy' to force the activation.
[... a Tcl stack trace here ...]

Oh, yes? Well, I forced the activation: sudo port -f activate libepoxy — which gives a lot of warnings about files being moved, etc. And at the end:

$ sudo port installed libepoxy
The following ports are currently installed:
  libepoxy @1.5.10_4+egl+x11 (active)

(qemu needs some attention next, but that shall be the subject of a different ticket!)

[GwynethLlewelyn (Gwyneth Llewelyn)]

port compilation log

[ryandesign (Ryan Carsten Schmidt)]

According to ​the ports web site, libepoxy is the only port that would install /opt/local/include/epoxy/common.h, so either it existed because MacPorts installed it yet libepoxy was for some reason not marked as being installed, or you installed libepoxy into the MacPorts prefix using a method other than MacPorts. Forcing the activation to work around that problem could be fine.

[ryandesign (Ryan Carsten Schmidt)]

Sorry Gwyneth, I only skimmed your report originally and responded to the wrong thing. The thing we're trying to fix it:

Replying to GwynethLlewelyn:

they will fail with an error on line ±69, dlopen_unwrapped = dlsym(RTLD_NEXT, "dlopen") complaining that RTLD_NEXT does not exist.

Specifically:

../libepoxy-1.5.10/test/egl_without_glx.c:69:30: error: use of undeclared identifier 'RTLD_NEXT'
   69 |     dlopen_unwrapped = dlsym(RTLD_NEXT, "dlopen");
      |                              ^
1 error generated.

Has duplicate #73817.

[ryandesign (Ryan Carsten Schmidt)]

In 3631b77a22d22436ffaa72416f7756b269d32e8e/macports-ports (master):

libepoxy +egl: Fix build failure on macOS

Closes: #73483

[GwynethLlewelyn (Gwyneth Llewelyn)]

Nice! Thanks, @ryandesign — as far as I can check it, after a selfupdate & upgrade outdated, everything seems to be working now:

$ port installed libepoxy qemu colima
The following ports are currently installed:
  colima @0.10.1_0 (active)
  libepoxy @1.5.10_4+egl+x11 (active)
  qemu @10.2.1_0+cocoa+curses+spice+spice_protocol+target_arm+target_i386+target_x86_64+usb+vnc
  qemu @10.2.2_0+cocoa+curses+spice+spice_protocol+target_arm+target_i386+target_x86_64+usb+vnc (active)

(so, now qemu also became operational, as pointed out under #73483, and so does colima)

[mohd-akram (Mohamed Akram)]

QEMU does not require libepoxy+egl in the default configuration, only if you enable its +gl variant.