I'm getting the same errors at make install even without compiling i965, with this as my autogen string:

./autogen.sh --enable-texture-float --with-dri-drivers= --disable-gallium-llvm --with-gallium-drivers=nouveau --prefix=/home/bryan/wayland --enable-debug --with-egl-platforms=x11,wayland,drm --enable-gbm

This is just a guess, but maybe it's a problem with non-standard build prefixes?  The XCB libraries in $PREFIX/lib are compiled from the latest git, but the version installed in /usr/lib on my machine is ancient.

All of the missing symbols are coming from libxcb commit 7983bf0fbdc(Add support for receiving fds in replies). Commit is part of libxcb-1.9.2 and libxcb-1.10.

Bryan,
Seems like you're missing the PKG_CONFIG_PATH which leads to the lack to the $PREFIX/include (or similar) -I flags thus the build break.

Juha-Pekka Heikkilä,
Have you build libxcb 1.9.2 or newer in the customer prefix ? If so we'll just need a oneline fix following Keith's confirmation of the following.

Keith

Can you clarify if we need to link against libxcb.so _only_ when building with dri3 or if this requirement has been there for ages ? Current mesa does not check for the package thus it picks up the system include/libs.

This may be the key for the issues you and/or others have noticed (steamos-mesa has all the dri3 patches reverted).

Cheers
Emil

I can make sure once I get home, but I'm fairly sure that my PKG_CONFIG_PATH is set properly.  If it isn't, then it should fail during compilation or linking, but those both succeed.  As it is, the errors don't show up until 'make install' is run and libtool tries to relink libGL.

(In reply to comment #2)

> Can you clarify if we need to link against libxcb.so _only_ when building
> with dri3 or if this requirement has been there for ages ? Current mesa does
> not check for the package thus it picks up the system include/libs.

DRI2 also uses xcb, and the configure.ac script does look for the xcb-dri3 package, along with piles of other xcb packages when building either DRI2 or DRI3

(In reply to comment #4)
> (In reply to comment #2)
> 
> > Can you clarify if we need to link against libxcb.so _only_ when building
> > with dri3 or if this requirement has been there for ages ? Current mesa does
> > not check for the package thus it picks up the system include/libs.
> 
> DRI2 also uses xcb, and the configure.ac script does look for the xcb-dri3
> package, along with piles of other xcb packages when building either DRI2 or
> DRI3

Indeed. Yet I'm talking about a slightly different thing here.

The failing functions rely on core xcb (for lack of better wording of) rather than xcb-*. Obviously we're checking and using xcb-* but now (or since some time) we explicitly depend on libxcb.so.

So after a bit of tinkering with objdump, libxcb.so, libGL.so and mesa's sources the following files use core xcb functions:

src/glx/create_context.c
src/glx/tests/create_context_unittest.cpp
src/glx/dri3_glx.c
src/egl/drivers/dri2/platform_x11.c
src/gallium/auxiliary/vl/vl_winsys_dri.c

So we should be checking/linking against xcb in:

libGL (unconditionally)
libEGL (when building the x11 backend)
libvdpau* (unconditionally)

I'll prep a few patches that correctly link the libraries against libxcb.

Created attachment 102646 [details] [review]
configure: check for core xcb (libxcb.so) and link libGL against it

This patch should resolve the problem. Can you give it a try ?

Juha-Pekka, Bryan

Can you guys test the patch in comment 7 ? I feel slightly reluctant about breaking my system in order to test it myself.

That patch makes no difference for me.

(In reply to comment #9)
> That patch makes no difference for me.

Hmm in that case I would suspect that you're hit by a more elaborate (and different) bug than the one reported by Juha-Pekka. If the original link succeeds and we fail at the re-linking stage, that indicates that the LDFLAGS|LIBS are somewhat bonkers. Which one(s) I'm not sure :\

There was a mildly related issue here [1]. You're building without llvm so I'm not sure it will help, still worth a shot though. *Apply on top of the patch in comment 7.

Cheers,
Emil
[1] https://bugs.gentoo.org/show_bug.cgi?id=501328#c47

Would be great if Juha-Pekka can confirm if the my patch helps in his case or not.

Hi, sorry I've been away from internet for a while. I just tried your patch on top of commit be8bc588b93286dff6a6c1e8594ec40da50658ff "glsl/cs: Add several GLSL compute shader variables" but it did not seem to make a difference. Before applying the patch I did git clean -dfx to avoid any intereference but the errors seem to stay as is.

I did look bit more into this. I notice at linking stage there is no /opt/lib in LIBRARY_PATH nor in "sys_lib_search_path_spec" inside libtool. So PKG_CONFIG_PATH allowed to find correct headers for compile time but not correct libraries for linking time. :/

I fixed this with "PKG_CONFIG_PATH=/opt/lib/pkgconfig CFLAGS=-L/opt/lib CXXFLAGS=-L/opt/lib" on my autogen line and it seemed to work for me, I can compile with dri3 enabled again.

(In reply to comment #12)
> I did look bit more into this. I notice at linking stage there is no
> /opt/lib in LIBRARY_PATH nor in "sys_lib_search_path_spec" inside libtool.
> So PKG_CONFIG_PATH allowed to find correct headers for compile time but not
> correct libraries for linking time. :/
> 
Yes normally one should provide PKG_CONFIG_PATH whenever the new .pc files are not available in the default location. Strange part is that configure.ac should bail when building dri3 with xcb older than 1.9.3.

Can you attach the contents of the system xcb.pc ?

> I fixed this with "PKG_CONFIG_PATH=/opt/lib/pkgconfig CFLAGS=-L/opt/lib
> CXXFLAGS=-L/opt/lib" on my autogen line and it seemed to work for me, I can
> compile with dri3 enabled again.

Hmm does the includedir and Libs flag of /opt/lib/pkgconfig/xcb.pc match the location of the header/library for the new xcb ? It seems like there is either a bug in xcb somewhere or you're using some strange method of building and/or installing xcb.

I paste the contents here for both xcb.pc files as they're short. Directories/files where they point are valid, I don't see anything wrong in these.

/opt/lib/pkgconfig/xcb.pc:
prefix=/opt
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
xcbproto_version=1.10

Name: XCB
Description: X-protocol C Binding
Version: 1.10
Requires.private: pthread-stubs xau >= 0.99.2 xdmcp
Libs: -L${libdir} -lxcb
Libs.private: 
Cflags: -I${includedir}

[EOF]

/usr/local/lib/pkgconfig/xcb.pc:
prefix=/usr/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
xcbproto_version=1.9

Name: XCB
Description: X-protocol C Binding
Version: 1.9
Requires.private: pthread-stubs xau >= 0.99.2 xdmcp
Libs: -L${libdir} -lxcb
Libs.private: 
Cflags: -I${includedir}

[EOF]

Here I see changed just prefix, xcbproto_version and Version. New libxcb is at its given location:

ls /opt/lib/libxcb.*
/opt/lib/libxcb.a  /opt/lib/libxcb.la  /opt/lib/libxcb.so  /opt/lib/libxcb.so.1  /opt/lib/libxcb.so.1.1.0

ls /opt/include/xcb/
bigreq.h     dpms.h  glx.h      record.h  screensaver.h  sync.h    xc_misc.h  xfixes.h    xkb.h     xselinux.h  xvmc.h
composite.h  dri2.h  present.h  render.h  shape.h        xcbext.h  xevie.h    xinerama.h  xprint.h  xtest.h
damage.h     dri3.h  randr.h    res.h     shm.h          xcb.h     xf86dri.h  xinput.h    xproto.h  xv.h

These were installed here with
make
sudo make install

(In reply to comment #14)
> I paste the contents here for both xcb.pc files as they're short.
> Directories/files where they point are valid, I don't see anything wrong in
> these.
> 
AFAICT they look good and you're doing everything correctly, so ... back to square one :\

> /usr/local/lib/pkgconfig/xcb.pc:
Do you have xcb and/or pkgconfig available in /usr/lib (without local) ?

Can you run git clean -nxd before and after building/installing commit 3ecd9e1a938 and attach the resulting src/glx/Makefile(s). It seems rather odd that it causes such behaviour.

Created attachment 103683 [details]
Makefile from src/gxl/ both failing and working makefiles are indentical.

Makefiles for 7ab925a6aafca.. (working) and 3ecd9e1a93817.. (failing) were identical thus attach only one makefile.

I did continue poking at this one today. I notice if I revert 3ecd9e1a93817180fa5b280e5fe11c903cca38ba I can compile with dri3 but don't yet know why is it so. I did try stracing  the problematic libtool line and see libxcb is accessed only from /opt/lib and objdump says my libxcb does have the symbols which are not found here.

If I revert 3ecd9.. problematic libtool line stays the same as well as libtool seems to stay without changes. I think I have to redo these tests tomorrow because nothing seems to change but still after reverting 3ecd9e1a93817180fa5b280e5fe11c903cca38ba I can build with dri3; Makefile in src/glx stay the same, libtool stay the same and libtool parameters seem to stay the same. Maybe I forgot to do git clean as some pass.

Anyhow, 3ecd9e1a93817180fa5b280e5fe11c903cca38ba seems to be the source of this problem. Can you Bryan test if reverting 3ecd9.. fixes the problem for you too?

I had cross-compilation problems on Ubuntu (building 32bit Mesa on 64bit environment) and my problems went away by reverting

3ecd9e1a93817180fa5b280e5fe11c903cca38ba

For some reason otherwise a wrong version (64bit one) of libexpat got included to linking. Patch adds $(EXPAT_LIBS) when linking libloader so that is why I tried the revert. I'll try to see why this happens.

(In reply to comment #18)
> I had cross-compilation problems on Ubuntu (building 32bit Mesa on 64bit
> environment) and my problems went away by reverting
> 
> 3ecd9e1a93817180fa5b280e5fe11c903cca38ba
> 
> For some reason otherwise a wrong version (64bit one) of libexpat got
> included to linking. Patch adds $(EXPAT_LIBS) when linking libloader so that
> is why I tried the revert. I'll try to see why this happens.

whoopsie forgot to paste my build command line:

INTEL_CFLAGS='-I/opt/include -I/opt/include/libdrm' INTEL_LIBS='-L/opt/lib -ldrm_intel' CFLAGS='-m32' CXXFLAGS='-m32' ./autogen.sh --prefix=/opt --enable-gles2 --without-gallium-drivers --enable-32-bit --with-dri-drivers=i965 --with-egl-platforms=x11 --disable-osmesa --disable-vdpau --disable-dri3 --enable-debug --enable-glx-tls --enable-texture-float

(In reply to comment #19)
> (In reply to comment #18)
> > I had cross-compilation problems on Ubuntu (building 32bit Mesa on 64bit
> > environment) and my problems went away by reverting
> > 
> > 3ecd9e1a93817180fa5b280e5fe11c903cca38ba
> > 
> > For some reason otherwise a wrong version (64bit one) of libexpat got
> > included to linking. Patch adds $(EXPAT_LIBS) when linking libloader so that
> > is why I tried the revert. I'll try to see why this happens.
> 
> whoopsie forgot to paste my build command line:
> 
> INTEL_CFLAGS='-I/opt/include -I/opt/include/libdrm' INTEL_LIBS='-L/opt/lib
> -ldrm_intel' CFLAGS='-m32' CXXFLAGS='-m32' ./autogen.sh --prefix=/opt
> --enable-gles2 --without-gallium-drivers --enable-32-bit
> --with-dri-drivers=i965 --with-egl-platforms=x11 --disable-osmesa
> --disable-vdpau --disable-dri3 --enable-debug --enable-glx-tls
> --enable-texture-float

I find something a bit disturbing here - why would you set INTEL_{CFLAGS,LIBS} rather than relying on pkg-config ?

Your native arch is x86-64 thus the lack of PKG_CONFIG_PATH is the one causing you problems - pkgconfig looks for the variable (none set) then goes into the default dir which has a .pc file pointing to a 64bit library.

Or to put things in a different light - please can we avoid shooting mesa in the back by providing any other flags but PKG_CONFIG_PATH, CFLAGS and CXXFLAGS. Thank you

P.S. Things should just work even without C{XX,}FLAGS='-m32' unless we have a bug somewhere :)

(In reply to comment #20)
> (In reply to comment #19)
> > (In reply to comment #18)
> > > I had cross-compilation problems on Ubuntu (building 32bit Mesa on 64bit
> > > environment) and my problems went away by reverting
> > > 
> > > 3ecd9e1a93817180fa5b280e5fe11c903cca38ba
> > > 
> > > For some reason otherwise a wrong version (64bit one) of libexpat got
> > > included to linking. Patch adds $(EXPAT_LIBS) when linking libloader so that
> > > is why I tried the revert. I'll try to see why this happens.
> > 
> > whoopsie forgot to paste my build command line:
> > 
> > INTEL_CFLAGS='-I/opt/include -I/opt/include/libdrm' INTEL_LIBS='-L/opt/lib
> > -ldrm_intel' CFLAGS='-m32' CXXFLAGS='-m32' ./autogen.sh --prefix=/opt
> > --enable-gles2 --without-gallium-drivers --enable-32-bit
> > --with-dri-drivers=i965 --with-egl-platforms=x11 --disable-osmesa
> > --disable-vdpau --disable-dri3 --enable-debug --enable-glx-tls
> > --enable-texture-float
> 
> I find something a bit disturbing here - why would you set
> INTEL_{CFLAGS,LIBS} rather than relying on pkg-config ?

because libdrm is the only library I use from under /opt, rest comes from the system

> Your native arch is x86-64 thus the lack of PKG_CONFIG_PATH is the one
> causing you problems - pkgconfig looks for the variable (none set) then goes
> into the default dir which has a .pc file pointing to a 64bit library.

well, it has been working so far without problems though (and this command line actually still works fine on my fedora machine, but on ubuntu it does not), libtool takes care of pointing to the correct arch directory

> Or to put things in a different light - please can we avoid shooting mesa in
> the back by providing any other flags but PKG_CONFIG_PATH, CFLAGS and
> CXXFLAGS. Thank you
> 
> P.S. Things should just work even without C{XX,}FLAGS='-m32' unless we have
> a bug somewhere :)

Unfortunately we do, giving '-m32' manually is the only way to get working 32bit build because we initialize libtool too early (LT_INIT), here's the bug:

https://bugs.freedesktop.org/show_bug.cgi?id=50754

(In reply to comment #21)
> (In reply to comment #20)
> > (In reply to comment #19)
> > > (In reply to comment #18)
> > > > I had cross-compilation problems on Ubuntu (building 32bit Mesa on 64bit
> > > > environment) and my problems went away by reverting
> > > > 
> > > > 3ecd9e1a93817180fa5b280e5fe11c903cca38ba
> > > > 
> > > > For some reason otherwise a wrong version (64bit one) of libexpat got
> > > > included to linking. Patch adds $(EXPAT_LIBS) when linking libloader so that
> > > > is why I tried the revert. I'll try to see why this happens.
> > > 
> > > whoopsie forgot to paste my build command line:
> > > 
> > > INTEL_CFLAGS='-I/opt/include -I/opt/include/libdrm' INTEL_LIBS='-L/opt/lib
> > > -ldrm_intel' CFLAGS='-m32' CXXFLAGS='-m32' ./autogen.sh --prefix=/opt
> > > --enable-gles2 --without-gallium-drivers --enable-32-bit
> > > --with-dri-drivers=i965 --with-egl-platforms=x11 --disable-osmesa
> > > --disable-vdpau --disable-dri3 --enable-debug --enable-glx-tls
> > > --enable-texture-float
> > 
> > I find something a bit disturbing here - why would you set
> > INTEL_{CFLAGS,LIBS} rather than relying on pkg-config ?
> 
> because libdrm is the only library I use from under /opt, rest comes from
> the system
> 
> > Your native arch is x86-64 thus the lack of PKG_CONFIG_PATH is the one
> > causing you problems - pkgconfig looks for the variable (none set) then goes
> > into the default dir which has a .pc file pointing to a 64bit library.
> 
> well, it has been working so far without problems though (and this command
> line actually still works fine on my fedora machine, but on ubuntu it does
> not), libtool takes care of pointing to the correct arch directory
> 
Just because it works (sometimes) it doesn't mean it's a good idea :) Please migrate to using PKG_CONFIG_PATH which should work consistently for every platform. It also scales nicely if more things are available in the custom prefix.

Snippet from the pkg-config man page:
"pkg-config retrieves information about packages from special metadata files. These files are named after the package, and has a .pc extension. On most systems,  pkg-config looks in /usr/lib/pkgconfig, /usr/share/pkgconfig,  /usr/local/lib/pkgconfig and /usr/local/share/pkgconfig for these files. It will additionally look in the colon-separated (on Windows, semicolon-separated) list of directories specified by the PKG_CONFIG_PATH environment variable."

> > Or to put things in a different light - please can we avoid shooting mesa in
> > the back by providing any other flags but PKG_CONFIG_PATH, CFLAGS and
> > CXXFLAGS. Thank you
> > 
> > P.S. Things should just work even without C{XX,}FLAGS='-m32' unless we have
> > a bug somewhere :)
> 
> Unfortunately we do, giving '-m32' manually is the only way to get working
> 32bit build because we initialize libtool too early (LT_INIT), here's the
> bug:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=50754
Thanks I'll look into it.

(In reply to comment #22)
> > https://bugs.freedesktop.org/show_bug.cgi?id=50754
> Thanks I'll look into it.

Thanks, it's pretty embarrasing how long it's been unfixed.

Gents just pushed a few commits which explicitly checks for xcb and links the relevant libraries against it. This is required as soon (tm) libxcb will remote it's Requires to Requires.private, thus libraries that link against libxcb-* will not implicitly link against core xcb.

Can anyone check the Makefiles and/or strace of the issue for a clean tree? I'm suspecting that autohell may be optimising something leading to the strange experience in comment 16 and 17

I think I may have cracked this :P

So as we link libGL.so, we use -L (when libs are located in custom location) and -rpath for glapi.

As those two are seen the linker (gcc) seemingly ignores the -L directive and does not add it to the DT_RPATH of the final library. Only the rpath that is explicitly provided ends up in there.

Now the million dollar question is - is this a bug or a feature. If the latter how to we handle things correctly ?

Scratch-out comment 25. Seems like I've got a bit confused there :)

Guys if you're still having fun with this can attach the output with the following patch ? It should make ld a bit more chatty on the topic :)

diff --git a/src/glx/Makefile.am b/src/glx/Makefile.am
index 4515312..5ed7b81 100644
--- a/src/glx/Makefile.am
+++ b/src/glx/Makefile.am
@@ -130,6 +130,7 @@ GL_LIBS = \
 GL_LDFLAGS = \
        -no-undefined \
        -version-number 1:2 \
+       -Wl,--verbose \
        $(BSYMBOLIC) \
        $(GC_SECTIONS) \
        $(LD_NO_UNDEFINED)

Created attachment 110039 [details]
log of failed dri3 build with Emil's patch included

Here is the log with Emil's patch included. Log contain everything "make install" produced. My mesa head was at 60f011af1a370004333cbc3fee7fec137ebd9d6a

OK so it seems that, on relink, libtool prepends an extra -L or two prior to -L/opt/lib thus gcc/ld might end up finding the system library thus never bothers searching in /opt/lib. The extra -L can be seen when one invokes $ make V=1 ..

It smells like a bug in libtool, despite the response I got on IRC (va at #autotools) that libtool is correct here. Cannot find any hints, neither did he/she mention anything to support that statement :'( The search continues...

Guys can you attach the glx hunk of $ make V=1 && make V=1 install, with the patch in comment 27.
Additionally can you add the last ~15 lines of libtool --help

Thanks
Emil

Created attachment 110402 [details]
requested logs

Here are the logs. Sorry for the delay, my build system was confused for a while and needed to fix it.

Closing this autotools issue, as autotools has now been deleted (see https://gitlab.freedesktop.org/mesa/mesa/merge_requests/601).

If you think I may have made a mistake and this issue still needs fixing, feel free to reopen it :)