I'm getting this bug report secondhand but it seems like an easy issue to address. Apparently we still check for X11 headers and libraries when building for Carbon or Cocoa, and in some cases it's a fatal error when they aren't found. We can fix this simply by setting no_x=yes in the appropriate part of configure.in.
Created attachment 144598 [details] [diff] [review] quick fix Just to summarize the problem better: this occurs if you install the X11 SDK. configure decides that you have X installed but it doesn't work correctly, which is incorrectly made a fatal error. Ideally we should be able to simply skip the X11 checks for toolkit=mac|cocoa, but things are in the wrong order in the script and I don't have time to figure out why (the X11 check is before the toolkit option). This patch just makes any X errors non-fatal if building for mac/cocoa.
Attachment #144598 - Flags: review?(cls)
Comment on attachment 144598 [details] [diff] [review] quick fix Ideally, there should be nothing wrong with checking for the presence of a feature. That's the entire philosophy behind autoconf. These hardcoded no_x=yes should be removed. If we're doing an fatal X11 check in the wrong spot then that should be fixed.
Attachment #144598 - Flags: review?(cls) → review-
Created attachment 144865 [details] [diff] [review] only do fatal check when building for MOZ_X11 Btw, this problem isn't caused by the mere presence of the X11 SDK. It has to be present *and* broken to trigger the bustage. You probably want to fix that anyway if you bothered to install it.
Comment on attachment 144865 [details] [diff] [review] only do fatal check when building for MOZ_X11 a=asa (on behalf of drivers) for checkin to 1.7
Attachment #144865 - Flags: approval1.7? → approval1.7+
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.