Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Gentoo on Raspberry Pi: Mesa upgrade fails to compile
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
paulfxh
n00b
n00b


Joined: 28 Oct 2012
Posts: 8
Location: Castletroy, Ireland

PostPosted: Fri Jan 18, 2013 5:16 pm    Post subject: Gentoo on Raspberry Pi: Mesa upgrade fails to compile Reply with quote

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
View user's profile Send private message
limn
l33t
l33t


Joined: 13 May 2005
Posts: 906

PostPosted: Fri Jan 18, 2013 7:02 pm    Post subject: Reply with quote

/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
View user's profile Send private message
paulfxh
n00b
n00b


Joined: 28 Oct 2012
Posts: 8
Location: Castletroy, Ireland

PostPosted: Sat Jan 19, 2013 4:34 pm    Post subject: Reply with quote

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
View user's profile Send private message
limn
l33t
l33t


Joined: 13 May 2005
Posts: 906

PostPosted: Sat Jan 19, 2013 8:27 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum