Seems like I might need to eat my own words :-)

* Can you make sure that you do not have any local changes and/or danglin' files - git reset --hard origin/master && git clean -fxd

* What platform/distribution are you using ?

* Can you complete the build if you explicitly define __GNU__ (see bug 67740) ?

(In reply to comment #1)
> Seems like I might need to eat my own words :-)
> 
> * Can you make sure that you do not have any local changes and/or danglin'
> files - git reset --hard origin/master && git clean -fxd
> 
> * What platform/distribution are you using ?
> 
> * Can you complete the build if you explicitly define __GNU__ (see bug
> 67740) ?

Hi Emil ;) I did the git reset and clean and it didn't work. I'm using Linux (x86_64) with a installation similar to Linux from scratch. I compile everything. Just Mesa is causing problems.

I tried the CFLAGS=-D__GNU__ and it solved the above errors, but now I got another error:

make[3]: Entering directory '/usr/local/src/git/modular/x/mesa/mesa/src/glx'
  CCLD     libGL.la
./.libs/libglx.a(glxcmds.o): In function `glXGetProcAddressARB':
glxcmds.c:(.text+0x9b8): undefined reference to `__indirect_get_proc_address'
./.libs/libglx.a(indirect_init.o): In function `__glXNewIndirectAPI':
indirect_init.c:(.text+0x124): undefined reference to `__indirect_glAccum'
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../x86_64-unknown-linux-gnu/bin/ld: ./.libs/libglx.a(indirect_init.o): relocation R_X86_64_PC32 against undefined hidden symbol `__indirect_glAccum' can not be used when making a shared object
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../x86_64-unknown-linux-gnu/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
Makefile:692: recipe for target 'libGL.la' failed
make[3]: *** [libGL.la] Error 1
make[3]: Leaving directory '/usr/local/src/git/modular/x/mesa/mesa/src/glx'
Makefile:779: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/usr/local/src/git/modular/x/mesa/mesa/src/glx'
Makefile:528: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/usr/local/src/git/modular/x/mesa/mesa/src'
Makefile:579: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

Any hints?

(In reply to comment #2)
[...]
> Hi Emil ;) I did the git reset and clean and it didn't work. I'm using Linux
> (x86_64) with a installation similar to Linux from scratch. I compile
> everything. Just Mesa is causing problems.
> 
Hmmm, are you following the official instructions [1] ? The website indicates zero problems with mesa 10.0 and 9.2. Would you consider this a regression in mesa, or is it the first time you're doing such a build ?

> I tried the CFLAGS=-D__GNU__ and it solved the above errors, but now I got
> another error:
> 
I'm not sure if you applied to only for the specific folder or for the whole of mesa. I'm suspecting that this is biting you below.

> make[3]: Entering directory '/usr/local/src/git/modular/x/mesa/mesa/src/glx'
>   CCLD     libGL.la
> ./.libs/libglx.a(glxcmds.o): In function `glXGetProcAddressARB':
> glxcmds.c:(.text+0x9b8): undefined reference to `__indirect_get_proc_address'
> ./.libs/libglx.a(indirect_init.o): In function `__glXNewIndirectAPI':
> indirect_init.c:(.text+0x124): undefined reference to `__indirect_glAccum'
> /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../x86_64-unknown-
> linux-gnu/bin/ld: ./.libs/libglx.a(indirect_init.o): relocation
> R_X86_64_PC32 against undefined hidden symbol `__indirect_glAccum' can not
> be used when making a shared object
> /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../x86_64-unknown-
> linux-gnu/bin/ld: final link failed: Bad value
> collect2: error: ld returned 1 exit status
> Makefile:692: recipe for target 'libGL.la' failed
> make[3]: *** [libGL.la] Error 1
> make[3]: Leaving directory '/usr/local/src/git/modular/x/mesa/mesa/src/glx'
> Makefile:779: recipe for target 'all-recursive' failed
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory '/usr/local/src/git/modular/x/mesa/mesa/src/glx'
> Makefile:528: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory '/usr/local/src/git/modular/x/mesa/mesa/src'
> Makefile:579: recipe for target 'all-recursive' failed
> make: *** [all-recursive] Error 1
> 
> Any hints?

Ideally you can grab a upstream distro and compare the pre-processed source with the one you're getting. Based on the differences we can stablish easier where the problem is.

[1] www.linuxfromscratch.org

(In reply to comment #3)

> Hmmm, are you following the official instructions [1] ? The website
> indicates zero problems with mesa 10.0 and 9.2. Would you consider this a
> regression in mesa, or is it the first time you're doing such a build ?

No, because it's not Linux from scratch. It's like LFS, but not exactly like they do. Anyway, I compile all software I use. Mesa seems the most problematic. I compiled Mesa up to 8.0.5. Starting with vesion 9 I get all these problems,
so yes, it is a regression (first detect in Mesa 9).

> I'm not sure if you applied to only for the specific folder or for the whole
> of mesa. I'm suspecting that this is biting you below.

I get the same result in both cases.

> > make[3]: Entering directory '/usr/local/src/git/modular/x/mesa/mesa/src/glx'
> >   CCLD     libGL.la
> > ./.libs/libglx.a(glxcmds.o): In function `glXGetProcAddressARB':
> > glxcmds.c:(.text+0x9b8): undefined reference to `__indirect_get_proc_address'

> Ideally you can grab a upstream distro and compare the pre-processed source
> with the one you're getting. Based on the differences we can stablish easier
> where the problem is.

Ok, how exactly I do that? Can you please describe with more details? 

Thank you.

(In reply to comment #4)
[...]
> No, because it's not Linux from scratch. It's like LFS, but not exactly like
> they do. Anyway, I compile all software I use. Mesa seems the most
Great you feel like going through all the mayhem with zero assistance, good luck :P

> problematic. I compiled Mesa up to 8.0.5. Starting with vesion 9 I get all
> these problems,
> so yes, it is a regression (first detect in Mesa 9).
> 
[...]

> I get the same result in both cases.
Not cool.

[...]
> Ok, how exactly I do that? Can you please describe with more details? 
> 
gcc -E will help you out. Note that I'm not passionate at looking through and comparing the mile long preprocessed sources so I'd leave that pleasure to you :)

(In reply to comment #5)
> gcc -E will help you out. Note that I'm not passionate at looking through
> and comparing the mile long preprocessed sources so I'd leave that pleasure
> to you :)

No problem! ;) I do the hard work. But I need at least a little help to figure out it. As far as I understand, the problem is with the indirect_init.c file. So I need to generate the preprocessed source with "gcc -E indirect_init.c" right?
I did it including the needed -I parameters. I'll attach the result file.

Does it help?

Created attachment 96313 [details]
Preprocessed source (indirect_init.c)

SOLVED! Can you believe the problem was caused by an old version of "indent" lying around? 

Now I got one last compilation error, but it would be better to report in another bug report, so I'm marking this as invalid.

Thanks!

(In reply to comment #8)
> SOLVED! Can you believe the problem was caused by an old version of "indent"
> lying around? 
> 
Do you recall which version of indent was causing the problem, which one works correctly ? We can check in configure.ac and fall-back to using cat rather than causing such nuisance.

Did you still need to use -D__GNU__ ?

(In reply to comment #9)
> Do you recall which version of indent was causing the problem, which one
> works correctly ? We can check in configure.ac and fall-back to using cat
> rather than causing such nuisance.
> 
> Did you still need to use -D__GNU__ ?

The indent version was so old (from 2003) it doesn't even give a version number with --version parameter. But since even the latest version of GNU indent (2.2.10) is old (from 2009) I think you can require it during configure without problems since everyone should be using the latest version by now.

And I don't need to use -D__GNU__ anymore. ;)

(In reply to comment #10)
> The indent version was so old (from 2003) it doesn't even give a version
> number with --version parameter. But since even the latest version of GNU
> indent (2.2.10) is old (from 2009) I think you can require it during
> configure without problems since everyone should be using the latest version
> by now.
> 
A few interesting bits
 - indent returns 1, on --version and --any-unknown-switch
 - the changelog/news file does not indicate when --version was introduced
 - some distros ship a version 2.2.11 which according to the gnu website does not exist

With those said I'm going to close this as won't fix. If anyone is willing to have fun with this dinosaur, feel free to reopen and send us a patch.

> And I don't need to use -D__GNU__ anymore. ;)
Glad to hear, thanks.

There is no need to require GNU indent.  Unless something has changed here in Mesa very recently the versions of indent in OpenBSD and FreeBSD support all of the flags Mesa uses.  None of which are the getopt_long style options only supported by the GNU version.

(In reply to comment #12)
> There is no need to require GNU indent.  Unless something has changed here
> in Mesa very recently the versions of indent in OpenBSD and FreeBSD support
> all of the flags Mesa uses.  None of which are the getopt_long style options
> only supported by the GNU version.

That wasn't my understanding, but feel free to take a look. See https://bugs.gentoo.org/show_bug.cgi?id=428112

Mesa git does not use -bls on indent like that bug report mentions.  It uses -i4 -nut -br -brs -npcs -ce -TGLubyte -TGLbyte -TBool.  In the middle of last year I modified the OpenBSD indent to add changes from FreeBSD indent so it would work with Mesa.  Specifically adding -ut/-nut flags and defaulting to stdin/stdout if no input files are specified.