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

RESOLVED FIXED in mozilla6


9 years ago
a year ago


(Reporter: hhaamu, Assigned: gaston)



Firefox Tracking Flags

(Not tracked)



(3 attachments)



9 years ago
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))

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

9 years ago
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

9 years ago
Posted patch patchSplinter Review
I'm not sure this is correct, but I copypasted this from the MOZ_X11 check right above.

Comment 3

8 years ago
I can confirm this bug, it works in OpenBSD when you build from the ports tree as autoconf cache in 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.
Ever confirmed: true

Comment 4

8 years ago
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; }
Attachment #527121 - Flags: review?(khuey)
Your best bet is probably to add XShm.h into and remove the existing single header check.

Comment 6

8 years ago
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, so that means we can safely drop that check, and assume that it's included/available if MOZ_X11 is 1 ?

Comment 7

8 years ago
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.
Attachment #527209 - Flags: review?
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.
Attachment #527209 - Flags: review? → review+

Comment 10

8 years ago
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.
I think those are all known failures.


8 years ago
Keywords: checkin-needed
Assignee: nobody → landry
Flags: in-testsuite-
Keywords: checkin-needed
Whiteboard: [fixed-in-cedar]

Comment 13

8 years ago
Last Resolved: 8 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-cedar]
Target Milestone: --- → mozilla6

Comment 14

8 years ago
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

8 years ago
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...
Summary: configure check for GL/glx.h does not respect --x-includes → configure check for GL/glx.h does not respect --x-includes on OpenBSD
You should probably file a new bug for what this bug isn't now.


a year ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.