Building XFree86 for Raspberry Pi Zero - Problem with Includes

First, yes I have heard of X.Org. Unfortunately its changelog shows that they removed the XAA subsystem, saying that it had been broken for some unspecified period of time before that as well. I specifically want to use/hack XAA, so I want to start with code where it's working from the outset, hence XFree86.

As XFree86 supports building on 32bit ARM, I thought building on a Pi Zero running RPi OS 10 would be... Well not easy, but I wasn't expecting this. So far I haven't got past the makedepend stage.

The main problem is that I haven't been able to find a good place for setting extra system include directories to be checked by makedepend (more "-I" options). I tried adding PreIncDir and ExtraIncDir defines in config/cf/linux.cf, based on other config/cf/*.cf files, but that did nothing. So it fails to find a whole heap of header files that _aren't_ in /usr/include (or the right position therein).

I'm also a bit unclear about which directories should be looked in for those headers. I've found various headers (often multiple files with the same name) that it complains are missing in: /usr/include/arm-linux-gnueabihf /usr/src/linux-headers-5.4.51+ /usr/lib/gcc/arm-linux-gnueabihf/8/include

But there's also issues with it looking for includes such as "asm/mmiowb.h" which actually are only found in eg. "asm-generic/mmiowb.h" or "generated/asm/mmiowb.h" (which just includes "asm-generic/mmiowb.h").

I've been having some apparent success by adding symlinks to other system include directories in xc/exports/include, then running "make Everything" (the links there all get deleted when you do a "make World"). But the problems I'm having now are screaming that I'm doing it the wrong way, with "conflicting type" errors and an apparantly broken macro, etc.

So my key questions are:

  1. Where do I specifiy additional include paths to be passed to imake/makedepend when I do a "make World" for XFree86?

  1. Am I including headers from the right directories? Or is there another kernel header package that I need to install (currently I've just got raspberrypi-kernel-headers)?

Here's a bit from the end of the compile log where the build currently fails, giving an example of the multiple problems from the kernel header includes (the build has got a lot further than this before, but then it reports lots of "cannot find include file" warnings, and eventually dies with "Floating point exception" after: " ../../../../../config/makedepend/makedepend: warning: mmapr.c (reading ../../../../../exports/include/linux/jiffies.h), line 42: # error Invalid value of HZ. " , and adding symlinks in xc/exports/include to fix that leads to this):

../../exports/include/linux/types.h:26:26: error: conflicting types for 'timer_t ' typedef __kernel_timer_t timer_t; ^~~~~~~ In file included from ../../exports/include/sys/types.h:130, from /usr/include/stdlib.h:394, from imake.c:154: ../../exports/include/bits/types/timer_t.h:7:19: note: previous declaration of ' timer_t' was here typedef __timer_t timer_t; ^~~~~~~ In file included from ../../exports/include/linux/limits.h:6, from ../../exports/include/bits/local_lim.h:38, from ../../exports/include/bits/posix1_lim.h:161, from /usr/include/limits.h:183, from /usr/lib/gcc/arm-linux-gnueabihf/8/include-fixed/limits.h:

194, from /usr/lib/gcc/arm-linux-gnueabihf/8/include-fixed/syslimits.h:7, from /usr/lib/gcc/arm-linux-gnueabihf/8/include-fixed/limits.h:34, from imake.c:255: ../../exports/include/linux/types.h:131:13: error: conflicting types for 'blkcnt_t' typedef u64 blkcnt_t; ^~~~~~~~ In file included from /usr/include/stdlib.h:394, from imake.c:154: ../../exports/include/sys/types.h:209:20: note: previous declaration of 'blkcnt_t' was here typedef __blkcnt_t blkcnt_t; /* Type to count number of disk blocks. */ ^~~~~~~~ In file included from ../../exports/include/bits/local_lim.h:38, from ../../exports/include/bits/posix1_lim.h:161, from /usr/include/limits.h:183, from /usr/lib/gcc/arm-linux-gnueabihf/8/include-fixed/limits.h:194, from /usr/lib/gcc/arm-linux-gnueabihf/8/include-fixed/syslimits.h:7, from /usr/lib/gcc/arm-linux-gnueabihf/8/include-fixed/limits.h:34, from imake.c:255: ../../exports/include/bits/xopen_lim.h:99:5: error: missing binary operator before token "(" #if INT_MAX == 32767 ^~~~~~~ ../../exports/include/bits/xopen_lim.h:102:5: error: missing binary operator before token "(" #if INT_MAX == 2147483647 ^~~~~~~ ../../exports/include/bits/xopen_lim.h:126:5: error: missing binary operator before token "(" #if LONG_MAX == 2147483647 ^~~~~~~~ make[2]: *** [: imake.o] Error 1
--
__          __ 
#_ < |\| |< _#
Reply to
Computer Nerd Kev
Loading thread data ...

It turns out the makedpend executable wasn't getting recompiled, and the include paths are actually compiled into it, so that's why the changes to linux.cf weren't doing anything.

"gcc -xc -E -v -" shows default include paths that GCC would use. "/usr/src/linux-headers-5.4.51+" isn't among them, but I got past the makedepend stage by adding header paths to lib/Xaw6/Imakefile. But then it started with compiler errors about wrong types, etc.

It seems those problems are all in lib/Xaw/OS.c which includes as a fall-back method of determining the page size. This include has been commented out in the X.Org version of the file:

formatting link
so I just did that too and it worked (plus it no longer needs the extra include paths in lib/Xaw6/Imakefile).

Actually it's still compiling now, but it got me further at the very least... Now it's stopped in lib/GLU/libnurbs/internals with a bunch of compiler errors related to this first one:

"In file included from arc.cc:49: simplemath.h:56:13: error: 'REAL abs(REAL)' conflicts with a previous declaration abs( REAL x ) { return ( x < 0.0 ) ? -x : x; } ^ "

Removing the "#if" around this in extras/ogl-sample/main/gfx/lib/glu/libnurbs/internals/simplemath.h "#if defined(_SCO_DS) || defined(__SCO__) #define abs __gluabs #endif " seems to fix that. Looks like I might get there eventually...

--
__          __ 
#_ < |\| |< _#
Reply to
Computer Nerd Kev

Heh. Computers are so thoughtful.

[snip tales of stumbling blocks]

Sounds like fun times.

Elijah

------ coercing something to compile can be so satisfying

Reply to
Eli the Bearded

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.