Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libglvnd fails to build on 32bit x86 #18

Closed
kwizart opened this issue Feb 15, 2015 · 8 comments
Closed

libglvnd fails to build on 32bit x86 #18

kwizart opened this issue Feb 15, 2015 · 8 comments
Assignees
Labels

Comments

@kwizart
Copy link
Contributor

kwizart commented Feb 15, 2015

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
Copy link
Member

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
Copy link
Collaborator

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 kbrenneman self-assigned this Mar 17, 2015
@kbrenneman kbrenneman reopened this Mar 19, 2015
@kbrenneman
Copy link
Collaborator

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

kbrenneman added a commit that referenced this issue Mar 25, 2015
The x86 TLS versions of the entrypoints don't work yet. Until they do, use the
x86 TSD version instead.

Workaround for issue #18.
@kbrenneman
Copy link
Collaborator

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

@aaronp24 aaronp24 added the bug label Feb 18, 2016
@kwizart
Copy link
Contributor Author

kwizart commented Sep 15, 2016

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
Copy link
Collaborator

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
Copy link
Contributor Author

kwizart commented Sep 15, 2016

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
Copy link
Collaborator

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.

kbrenneman added a commit to kbrenneman/libglvnd that referenced this issue Sep 28, 2016
Fix the generated code for the x86 TLS dispatch stubs.

Update the x86 TLS stubs to use the same common code as the rest of the x86 and
x86-64 entrypoints.

Fixes NVIDIA#18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants