The current git repository as of this date is missing at least two header files referenced by src/mesa/drivers/dri/nouveau/nouveau_driver.h The file nouveau_device.h is missing and when I just experimentally commented that out then nouveau_gobj.h cropped up missing so I stopped. All the other header files in the same block of includes that I could locate are all apparently local to this directory. They are also all local includes (e.g. in "" not <> quotes) so I figure they are all from here. spot checking I think nouveau_device.h, nouveau_grobj.h, nouveau_channel.h, and nouveau_notifier.h and any .c files they front for are suspiciously missing or live somewhere inobvious to me. This was first observed about two weeks ago but I didn't realize this was the right place to report it. /doh.
Created attachment 44629 [details] [review] a suitable patch In file `src/mesa/drivers/dri/nouveau/Makefile.am' use `LIBDRM_CFLAGS' instead of just `CFLAGS': the pkg-config flags from `libdrm_nouveau.pc' (installed by `libdrm') must yield its `-I/usr/include/nouveau' where you find all these "missing" header files. (`INCLUDES' variable instead does not seem to work). c.
Created attachment 44779 [details] [review] just nouveau *.pc no need to for libdrm, see configs/linux-dri (it was `../Makefile' not `../Makefile.am')
*** Bug 35609 has been marked as a duplicate of this bug. ***
Apparently the problem is just that CFLAGS is not taken into account during the DRI driver compilation when using "--enable-shared-dricore". Christopher, was that the intended behavior of that option?
Created attachment 44812 [details] [review] use pkgconfig in configure.ac and INCLUDES in Makefiles - moved `+=' stuff after "include ../Makefile.template" - placing stuff in configure.ac shortcoming: should consider for nouveau also nv50 etc. like for radeon r300 r600 ... proposal: split `Makefile.template' into `Makefile.common' and `Makefile.targets'
Created attachment 44813 [details] [review] uses pkgconfig in configure.ac and configure and INCLUDES in Makefiles same patch but added stuff also for `configure' script
Comment on attachment 44813 [details] [review] uses pkgconfig in configure.ac and configure and INCLUDES in Makefiles Emm, why rename the radeon variable? -RADEON_LIBS = `pkg-config --libs libdrm_radeon` +NOUVEAU_LIBS = `shell pkg-config libdrm_nouveau --libs` +NOUVEAU_CFLAGS = `shell pkg-config libdrm_nouveau --cflags` + +RADEON_LDFLAGS = `pkg-config --libs libdrm_radeon`
(In reply to comment #7) > (From update of attachment 44813 [details] [review]) > Emm, why rename the radeon variable? > > > -RADEON_LIBS = `pkg-config --libs libdrm_radeon` > +NOUVEAU_LIBS = `shell pkg-config libdrm_nouveau --libs` > +NOUVEAU_CFLAGS = `shell pkg-config libdrm_nouveau --cflags` > + > +RADEON_LDFLAGS = `pkg-config --libs libdrm_radeon` It seemed as a bug w.r.t. uninformed use in all Makefiles. RADEON_LIBS looks like gone (not LIBDRM_RADEON_LIBS though with one occurence in `configure.ac':1053); it's not coming from normal PKG_CHECK_MODULES m4 macro: LIBDRM_RADEON_* do in lines 870-873, and then are read in lines 1052-1053. Is this better? -RADEON_LIBS = `pkg-config --libs libdrm_radeon` -RADEON_CFLAGS = `pkg-config --cflags libdrm_radeon` +LIBDRM_RADEON_LIBS = `pkg-config --libs libdrm_radeon` +LIBDRM_RADEON_CFLAGS = `pkg-config --cflags libdrm_radeon` +RADEON_CFLAGS = "-DHAVE_LIBDRM_RADEON=1 $LIBDRM_RADEON_CFLAGS" +RADEON_LDFLAGS = "$LIBDRM_RADEON_LIBS"
Created attachment 45008 [details] [review] use pkgconfig in configure.ac and INCLUDES in Makefiles configs/linux-dri is a makefile
Created attachment 45009 [details] [review] uses pkgconfig in configure.ac and configure and INCLUDES in Makefiles configs/linux-dri is a makefile
Created attachment 45037 [details] [review] split Makefile.template and use pkgconfig in configure.ac and INCLUDES in Makefiles split `Makefile.template' into `Makefile.defines' and `Makefile.targets'
Created attachment 45038 [details] [review] split Makefile.template and use pkgconfig in configure.ac and configure and INCLUDES in Makefiles split `Makefile.template' into `Makefile.defines' and `Makefile.targets'
*** Bug 37147 has been marked as a duplicate of this bug. ***
Created attachment 46722 [details] [review] Final fix! This patches fixes whole compiling. Tested on openSUSE (with and without --enable-shared-dricore). https://build.opensuse.org/package/show?package=Mesa&project=home%3Ajobermayr (with --enable-shared-dricore)
Set 'Component: Mesa core' since the patch touches core parts.
Created attachment 46984 [details] [review] Final fix #2 Thanks to Chris Bandy for the hint that line 48 missed a trailing double quote. But I am still wondering that it needs ~ 1 week and a further hint by me on IRC until somebody had a (first?) look on it ... Because some gave me hints on IRC that my (hard) wording sometimes is not reasonable I am referring to: http://tsdgeos.blogspot.com/2010/10/qt-gitorious-merge-requests-and-open.html (My worry is that this fix also will pushed someday after a couple of releases or even forgotten ...) Btw. somebody told me that quality is: Away from accident. Another one told me that source code should always be in a compileable state (indifferent whether you use [supported] configure switches) ... Some other projects (e.g. Gnash or Lightspark or Gluon) are happy if they get hints for compile errors or compiler warnings on specific distributions/configure switches (and there the main/core developers are also reachable on their IRC channels ...)
Set RESOLVED -> WONTFIX since nobody is man enough to push or comment on the patch which solves the issue within more than two weeks ...
(In reply to comment #17) > Set RESOLVED -> WONTFIX since nobody is man enough to push or comment on the > patch which solves the issue within more than two weeks ... Hi Johannes, It seems clear that you're frustrated that you're not getting a faster response to your contribution. However, WONTFIX is not the correct resolution for a bug that simply hasn't been examined closely enough yet. (I'm not personally in a position to evalutate a change to Mesa's build system, but I would prefer to see a bug like this left open so that someone who is in such a position could find it.) -Carl
I don't think anyone's actively working on the old nouveau driver any more (changes to such drivers tend to get ignored). I applied the patch here and it seems OK (though I can't test nouveau). I'll commit it in a minute. It can always be reverted if anyone has problems.
Just to clarify when and why I am getting angry: 1. Who is the person I must call? Usually I do not know it exactly: https://bugs.freedesktop.org/show_bug.cgi?id=37471 ; http://people.freedesktop.org/~cbrill/dri-log/index.php?date=2011-05-18&channel=dri-devel&highlight_names=&update=Update&date=2011-05-19 (at 10:50, 11:15 and ) 2. Here I am lucky to know the person who is responsible for nouveau_vieux.so but assigned it to Mesa core (as a matter of prudence ...) 3. Write to the maintainer on IRC (at 17:03): http://people.freedesktop.org/~cbrill/dri-log/index.php?date=2011-05-14&channel=nouveau&highlight_names=&update=Update&date=2011-05-14 4. Waiting a week to get answer from Mesa core developers -> no response ... 5. Reminder (at 09:07): http://people.freedesktop.org/~cbrill/dri-log/index.php?date=2011-05-21&channel=dri-devel&highlight_names=&update=Update&date=2011-05-21 6. Packed developers on their honor (comment #17) after ~ 3 weeks 7. The patch got applied ... 8. I know it is not the correct way but it was not the first time developers/maintainers make a decision only after I packed them on their honor (also on other projects) ... So my suggestion: Overthink the development process and provide information about maintainers and people with permission to commit (I have not known who is part of Mesa core team ...).
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.