libglvnd fails to build on 32bit x86

[kwizart]

I've attempted to fix this issue adding a missing include for the undefined MAPI_TABLE_NUM_STATIC but I failed to see that the header was included by other means.
So the previous patch didn't actually fix anything, and the software still fail to build for me on x86. (built fine on armv7hl and x86_64).

In file included from ../../../src/GLdispatch/vnd-glapi/mapi/entry.c:39:0:
../../../src/GLdispatch/vnd-glapi/mapi/entry_x86_tls.h: In function 'entry_init_public':
../../../src/GLdispatch/vnd-glapi/mapi/entry_x86_tls.h:109:27: error: 'MAPI_TABLE_NUM_STATIC' undeclared (first use in this function)
     for (slot = 0; slot < MAPI_TABLE_NUM_STATIC; i++)
                           ^
../../../src/GLdispatch/vnd-glapi/mapi/entry_x86_tls.h:109:27: note: each undeclared identifier is reported only once for each function it appears in
../../../src/GLdispatch/vnd-glapi/mapi/entry_x86_tls.h:109:50: error: 'i' undeclared (first use in this function)
     for (slot = 0; slot < MAPI_TABLE_NUM_STATIC; i++)
                                                  ^
../../../src/GLdispatch/vnd-glapi/mapi/entry_x86_tls.h:110:36: error: 'entry' undeclared (first use in this function)
        entry_generate_default_code(entry, slot);
                                    ^
../../../src/GLdispatch/vnd-glapi/mapi/entry_x86_tls.h: In function 'entry_generate':
../../../src/GLdispatch/vnd-glapi/mapi/entry_x86_tls.h:137:11: error: 'entry' undeclared (first use in this function)
    return entry;
           ^
../../../src/GLdispatch/vnd-glapi/mapi/entry_x86_tls.h:138:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
cc1: all warnings being treated as errors

[aaronp24]

Interesting. It looks like this happens because entry_init_public() is empty in entry_x86-64_tls.h but contains a loop over MAPI_TABLE_NUM_STATIC in entry_x86_tls.h. MAPI_TABLE_NUM_STATIC is only defined if MAPI_TMP_TABLE is defined when glapi_mapi_tmp.h is included, and it's not when entry_x86-64_tls.h includes mapi_tmp.h.

[kbrenneman]

Adding the MAPI_TMP_TABLE define and fixing a couple of typos lets it build and partially work.

I'm running into problems with the function pointers returned by glXGetProcAddress, but I'm still trying to determine if it's a problem in the dispatch layer or in the driver.

The TSD version (compiled without GLX_USE_TLS defined) does seem to work, though.

[kbrenneman]

It at least compiles now, but I'm still trying to figure out why the dispatch functions don't work.

[kbrenneman]

I've disabled the x86 TLS version for now. The x86 TSD version should work until the TLS version is fixed.

[kwizart]

Hello, is the TLS version stil broken ? seems like it will break any 32bit applications on fedora (even on from host x86_64 kernel).

checking for entrypoint stub type... x86_tsd, TLS=no

[kbrenneman]

The x86 TLS version is still broken, but the x86 TSD stubs work. The TSD stubs are good enough to be functionally correct, they just aren't as efficient for multi-threaded apps.

[kwizart]

Thx for the answear, but as I understand the version of mesa compiled in fedora has TLS by default.
So I expect fedora's mesa will not work with libglvnd on 32bit.

[kbrenneman]

Mesa's dispatch table is completely independent from libglvnd's. It doesn't matter if they match or not.

Libglvnd just forwards a function call from the application to whatever function the vendor library provides. It doesn't know or care how the vendor library deals with that function.

Likewise, the vendor library just gets a call to the function pointer that it provided to libglvnd. The vendor library doesn't have to know or care how libglvnd looked up the function.