Bug 92138 - Configuratin define "HAVE_LIBDRM" must not used in installed header
Summary: Configuratin define "HAVE_LIBDRM" must not used in installed header
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: 11.0
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-27 08:04 UTC by OBATA Akio
Modified: 2019-09-18 20:24 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description OBATA Akio 2015-09-27 08:04:22 UTC
After commit#0efd773f719dd2deddb4b6703edf022b294cd349

#ifdef HAVE_LIBDRM

is used in include/GL/internal/dri_interface.h.

"HAVE_LIBDRM" macro is defined in configure script and used
in build of Mesa itself, OK, works fine.

It is a part of installed header files, but HAVE_LIBDRM is not
defined anywhere in installed files, NG, because it may cause
build failure with "redefinition of typedef" for the case
source code includes both "include/GL/internal/dri_interface.h"
and "libdrm/drm.h".
Comment 1 Albert Freeman 2015-09-27 08:45:41 UTC
Where in particular is this an issue? Can't such software #define or #undef HAVE_DRM as required before including the header (and perhaps revert HAVE_DRM to the state it was in originally)?
Comment 2 Albert Freeman 2015-09-27 08:46:08 UTC
Oops, I meant HAVE_LIBDRM
Comment 3 OBATA Akio 2015-09-27 08:57:07 UTC
It's xorg-server/glx/glxdri2.c.
Comment 4 Albert Freeman 2015-09-27 09:03:45 UTC
(In reply to OBATA Akio from comment #3)
> It's xorg-server/glx/glxdri2.c.

Oh
Comment 5 Emil Velikov 2015-09-27 10:58:42 UTC
Hi OBATA,

Can you give a specific example (failing config/build log, platform info) of the issue. I recall giving the last 4 xserver branches a try and did not notice anything wrong.
Comment 6 Albert Freeman 2015-09-27 11:05:43 UTC
I can not reproduce this. Which platform and which version of the X server?
Comment 7 OBATA Akio 2015-09-27 11:12:16 UTC
Maybe, depend on compiler (I'm using gcc-4.5.3).
related changes in GCC?
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ce3765bf44e49ef0568a1ad4a0b7f807591d6412
Comment 8 Albert Freeman 2015-09-27 11:18:37 UTC
Which binutils?
Comment 9 OBATA Akio 2015-09-27 11:35:15 UTC
With gcc-4.6 and later, you can reproduce such error with "-pedantic-errors".
Comment 10 Albert Freeman 2015-09-27 11:36:51 UTC
nah, I want to build gcc anyway
Comment 11 Albert Freeman 2015-09-27 13:21:46 UTC
I guess building a really old gcc toolchain with a recent gcc compiler is an incredibly stupid thing to do (i.e. those old libraries are incredibly buggy).

I really should have just grabbed a distro with gcc 4.5.3 preinstalled.

"-pedantic-errors" does not seem to break anything (that is a bad thing).

Really tired...
Comment 12 Albert Freeman 2015-09-27 13:25:45 UTC
Maybe try and find a way to suppress compiler warnings (although I am guessing you have done that), also it would be nice if you tried to compile the git://anongit.freedesktop.org/xorg/xserver if at all possible.
Comment 13 Emil Velikov 2015-09-27 13:41:42 UTC
Ouch... seems that typedef redefinitions are a C11 thing, which obviously we cannot force onto others.

Rather than reintroducing the double-negative (esp. since the meaning varies, in one's native language), how about we do s/WITH_LIBDRM/HAVE_LIBDRM/ in xserver ? There is a insane permutation of xserver builds, so we might need something extra for the corner cases, but otherwise things should just work.
Comment 14 GitLab Migration User 2019-09-18 20:24:17 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/993.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.