View previous topic :: View next topic |
Author |
Message |
paulfxh n00b
Joined: 28 Oct 2012 Posts: 8 Location: Castletroy, Ireland
|
Posted: Fri Jan 18, 2013 5:16 pm Post subject: Gentoo on Raspberry Pi: Mesa upgrade fails to compile |
|
|
Gentoo (3.6.11+ kernel) works well on my 512 MB RPi other than the very long times required for software compiling on this little machine.
I recently carried out a 'emerge --sync' followed by 'emerge -Duv world' and this went well until it became time to upgrade mesa from 8.0.4 to 9.0.1
However, mesa would not compile even when I tried to emerge it separately from the world upgrade.
The most relevant part of the terminal output regarding the error is as follows:
Quote: | In file included from /usr/include/xorg/xf86Crtc.h:26:0,
from xorg_tracker.h:42,
from xorg_exa.h:4,
from xorg_composite.h:4,
from xorg_composite.c:1:
/usr/include/xorg/edid.h:619:6: warning: declaration does not declare anything
In file included from /usr/include/xorg/exa.h:39:0,
from xorg_tracker.h:43,
from xorg_exa.h:4,
from xorg_composite.h:4,
from xorg_composite.c:1:
/usr/include/xorg/fb.h:95:2: error: #error "GLYPHPADBYTES must be 4" |
I have saved all the relevant files regarding the attempted build if anybody believes they can clarify what the problem is.
I also have Gentoo installed on my Desktop and here the world upgrade proceeded to completion without any problems.
I have even copied the file /usr/include/xorg/fb.h from the Desktop Gentoo to Gentoo on my RPi.
However, even then the upgraded mesa failed to compile.
Any clues what's wrong here? |
|
Back to top |
|
|
limn l33t
Joined: 13 May 2005 Posts: 997
|
Posted: Fri Jan 18, 2013 7:02 pm Post subject: |
|
|
/usr/include/xorg/fb.h only tests whether GLYPHPADBYTES is 4 which is why swapping the other copy had no effect.
It appears that GLYPHPADBYTES is set in /usr/include/xorg/servermd.h and my guess is it is not getting set.
Then /usr/include/xorg/dixfontstr.h checks to see if it is set, and if not sets it to -1, and then fb.h complains.
Looks like you should file a bug.
A possible workaroud would be to make a copy of /usr/include/xorg/servermd.h and then change the original from
Code: | #ifdef __arm32__
#define IMAGE_BYTE_ORDER LSBFirst
#define BITMAP_BIT_ORDER LSBFirst
#define GLYPHPADBYTES 4
#endif /* __arm32__ */
|
to
Code: | #define IMAGE_BYTE_ORDER LSBFirst
#define BITMAP_BIT_ORDER LSBFirst
#define GLYPHPADBYTES 4
|
to force the setting and try emerging mesa again. |
|
Back to top |
|
|
paulfxh n00b
Joined: 28 Oct 2012 Posts: 8 Location: Castletroy, Ireland
|
Posted: Sat Jan 19, 2013 4:34 pm Post subject: |
|
|
limn wrote: |
A possible workaroud would be to make a copy of /usr/include/xorg/servermd.h and then change the original from
Code: | #ifdef __arm32__
#define IMAGE_BYTE_ORDER LSBFirst
#define BITMAP_BIT_ORDER LSBFirst
#define GLYPHPADBYTES 4
#endif /* __arm32__ */
|
to
Code: | #define IMAGE_BYTE_ORDER LSBFirst
#define BITMAP_BIT_ORDER LSBFirst
#define GLYPHPADBYTES 4
|
to force the setting and try emerging mesa again. |
Thank you very much.
Your suggested workaround worked perfectly.
However, I'm a little puzzled as to why this worked.
The 'if' statement that was taken out asked if the CPU has a 32-bit arm architecture.
As it does, shouldn't the line
Code: | #define GLYPHPADBYTES 4 |
have been read anyway?
Obviously, it wasn't but it's just not clear to me why. |
|
Back to top |
|
|
limn l33t
Joined: 13 May 2005 Posts: 997
|
Posted: Sat Jan 19, 2013 8:27 pm Post subject: |
|
|
I would have expected that also, which makes me think this is a bug.
I'm not sure where __arm32__ is set - maybe in the kernel - I didn't trace it back further. I do not have Gentoo on my Pi so I can not do testing on that architecture. |
|
Back to top |
|
|
|