Bug 76489

Summary: Mesa git (011569b5b7) compilation issue: render2.c:49:4: error: implicit declaration of function '__glMap1d_size' [-Werror=implicit-function-declaration]
Product: Mesa Reporter: Dâniel Fraga <fragabr>
Component: GLXAssignee: mesa-dev
Status: RESOLVED WONTFIX QA Contact:
Severity: trivial    
Priority: medium CC: fragabr
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
See Also: https://bugs.freedesktop.org/show_bug.cgi?id=67740
Whiteboard:
i915 platform: i915 features:
Attachments: configure log
Preprocessed source (indirect_init.c)

Description Dâniel Fraga 2014-03-22 22:59:04 UTC
Created attachment 96216 [details]
configure log

I'm trying to compile the latest git Mesa ( currently 011569b5b74d878fedf3ab07b18a730493468e8f ) and I get these errors:

Making all in glx
make[2]: Entering directory '/usr/local/src/git/modular/x/mesa/mesa/src/glx'
Making all in .
make[3]: Entering directory '/usr/local/src/git/modular/x/mesa/mesa/src/glx'
  CC       render2.lo
render2.c: In function '__indirect_glMap1d':
render2.c:49:4: error: implicit declaration of function '__glMap1d_size' [-Werror=implicit-function-declaration]
    k = __glMap1d_size(target);
    ^
render2.c: In function '__indirect_glMap1f':
render2.c:116:4: error: implicit declaration of function '__glMap1f_size' [-Werror=implicit-function-declaration]
    k = __glMap1f_size(target);
    ^
render2.c: In function '__indirect_glMap2d':
render2.c:180:4: error: implicit declaration of function '__glMap2d_size' [-Werror=implicit-function-declaration]
    k = __glMap2d_size(target);
    ^
render2.c: In function '__indirect_glMap2f':
render2.c:258:4: error: implicit declaration of function '__glMap2f_size' [-Werror=implicit-function-declaration]
    k = __glMap2f_size(target);
    ^
cc1: some warnings being treated as errors
Makefile:760: recipe for target 'render2.lo' failed
make[3]: *** [render2.lo] 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

***

I'm using gcc 4.8.2. I attached config.log.

./configure --prefix=/usr/xorg --libdir=/usr/xorg/lib64 --with-dri-drivers=i965 --with-gallium-drivers= --enable-texture-float
Comment 1 Emil Velikov 2014-03-23 16:34:09 UTC
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) ?
Comment 2 Dâniel Fraga 2014-03-23 18:19:38 UTC
(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?
Comment 3 Emil Velikov 2014-03-23 22:32:40 UTC
(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
Comment 4 Dâniel Fraga 2014-03-23 23:34:18 UTC
(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.
Comment 5 Emil Velikov 2014-03-23 23:58:14 UTC
(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 :)
Comment 6 Dâniel Fraga 2014-03-24 19:54:11 UTC
(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?
Comment 7 Dâniel Fraga 2014-03-24 19:55:11 UTC
Created attachment 96313 [details]
Preprocessed source (indirect_init.c)
Comment 8 Dâniel Fraga 2014-03-25 00:15:44 UTC
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!
Comment 9 Emil Velikov 2014-03-25 12:09:36 UTC
(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__ ?
Comment 10 Dâniel Fraga 2014-03-25 14:35:09 UTC
(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. ;)
Comment 11 Emil Velikov 2014-03-25 15:32:35 UTC
(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.
Comment 12 Jonathan Gray 2014-03-27 12:28:39 UTC
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.
Comment 13 Matt Turner 2014-03-28 00:43:45 UTC
(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
Comment 14 Jonathan Gray 2014-03-28 03:51:29 UTC
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.

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.