589088 - configure check for GL/glx.h does not respect --x-includes on OpenBSD

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[hhaamu]

User-Agent:       Mozilla/5.0 (X11; U; OpenBSD amd64; en-us) AppleWebKit/531.2+ (KHTML, like Gecko) Safari/531.2+ Epiphany/2.30.2
Build Identifier: 

checking for GL/glx.h... no
configure: error: Can't find header GL/glx.h for WebGL (install mesa-common-dev (Ubuntu), mesa-libGL-devel (Fedora), or Mesa (SuSE))

.mozconfig:
[...]
ac_add_options --x-includes=/usr/X11R6/include
ac_add_options --x-libraries=/usr/X11R6/lib
[...]


% ls -l /usr/X11R6/include/GL/glx.h
-r--r--r--  1 root  bin  17913 Aug  9 09:06 /usr/X11R6/include/GL/glx.h

Reproducible: Always

Comment 1

[hhaamu]

Relevant part from config.log:

configure:24434: checking for GL/glx.h
configure:24444: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:24440:20: error: GL/glx.h: No such file or directory
configure: failed program was:
#line 24439 "configure"
#include "confdefs.h"
#include <GL/glx.h>

Comment 2

[hhaamu]

Attachment: patch

I'm not sure this is correct, but I copypasted this from the MOZ_X11 check right above.

Comment 3

[Landry Breuil (:gaston)]

I can confirm this bug, it works in OpenBSD when you build from the ports tree as autoconf cache in config.site contains ac_cv_header_GL_gl_h=${ac_cv_header_GL_gl_h=yes}, but it will fail for builds from a regular mozilla source tree.

Comment 4

[Landry Breuil (:gaston)]

Attachment: Append X_CFLAGS on OpenBSD too

I think this patch is better. At least it helps detecting X11/XKBlib.h too, though i'm still having issues with X11/extensions/XShm.h which fails at configure time because Xlib.h should be include before it. Kyle, care to cc someone knowledgeable in autotools-fu to help ? I tried fiddling with MOZ_CHECK_HEADERS args, but i didn't find an example on how to add another include file..
I think this exact same configure test should fail on linux too.
Atm my workaround is adding export ac_cv_header_X11_extensions_XShm_h=yes to .mozconfig.

Exact failure is :

configure:10533: checking for X11/extensions/XShm.h
configure:10545: gcc -c  -fno-strict-aliasing   -I/usr/X11R6/include conftest.c 1>&5
In file included from configure:10539:
/usr/X11R6/include/X11/extensions/XShm.h:41: error: expected specifier-qualifier-list before 'Bool'
/usr/X11R6/include/X11/extensions/XShm.h:54: error: expected specifier-qualifier-list before 'Bool'
/usr/X11R6/include/X11/extensions/XShm.h:59: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'XShmQueryExtension'
/usr/X11R6/include/X11/extensions/XShm.h:64: error: expected ')' before '*' token
/usr/X11R6/include/X11/extensions/XShm.h:67: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'XShmQueryVersion'
/usr/X11R6/include/X11/extensions/XShm.h:75: error: expected ')' before '*' token
/usr/X11R6/include/X11/extensions/XShm.h:78: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'XShmAttach'
/usr/X11R6/include/X11/extensions/XShm.h:83: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'XShmDetach'
/usr/X11R6/include/X11/extensions/XShm.h:88: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'XShmPutImage'
/usr/X11R6/include/X11/extensions/XShm.h:102: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'XShmGetImage'
/usr/X11R6/include/X11/extensions/XShm.h:111: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
/usr/X11R6/include/X11/extensions/XShm.h:122: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'XShmCreatePixmap'
configure: failed program was:
#line 10538 "configure"
#include "confdefs.h"
#include <X11/extensions/XShm.h>
int main() {

; return 0; }

Comment 5

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Your best bet is probably to add XShm.h into http://mxr.mozilla.org/mozilla-central/source/configure.in#9020 and remove the existing single header check.

Comment 6

[Landry Breuil (:gaston)]

Hmm... just to be sure, if i do this how will HAVE_XSHM or ac_cv_header_X11_extensions_XShm_h be set ? Or it's not used at all.. ? Looking for HAVE_XSHM in mxr under m-c doesn't show occurences outside of configure.in, so that means we can safely drop that check, and assume that it's included/available if MOZ_X11 is 1 ?

Comment 7

[Landry Breuil (:gaston)]

Attachment: Append X_CFLAGS on OpenBSD too, dont check for XShm.h alone

And if that was what you meant, here's the corresponding diff. If HAVE_XSHM can go of course..

I'm not yet at a fully working configure with m-c (tripping on nanojit arch detection), but it looks good here.

Comment 8

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Comment on attachment 527209 [details] [diff] [review]
Append X_CFLAGS on OpenBSD too, dont check for XShm.h alone

As far as I can tell, we don't actually use HAVE_XSHM.  r=me, provided this passes tryserver.

Comment 9

[Landry Breuil (:gaston)]

http://tbpl.mozilla.org/?tree=Try&rev=f334d5d2b72d

Comment 10

[Landry Breuil (:gaston)]

From the results, it looks like the patch itself doesn't break the build, but i have no idea if the various test failures are related or not.

Comment 11

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I think those are all known failures.

Comment 12

[Boris Zbarsky [:bzbarsky]]

http://hg.mozilla.org/projects/cedar/rev/4e5abe9e5e8d

Comment 13

[Landry Breuil (:gaston)]

http://hg.mozilla.org/mozilla-central/rev/4e5abe9e5e8d

Comment 14

[hhaamu]

May I point out that the bug title and the fix don't match? You've worked around this specific issue for OBSD, but systems holding X11 in non-standard locations may still break.

Comment 15

[Landry Breuil (:gaston)]

That was implied by the bug target field, but sure. Adjusting title, feel free to open an issue for a 'generic' way to fix that. Maybe X_CFLAGS could be inconditionally saved in CPPFLAGS...

Comment 16

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

You should probably file a new bug for what this bug isn't now.