Re: [Xenomai-help] Questions porting existing rtai-24.1.12 app to xenomai (PART II)

[Philippe Gerum <rpm@xenomai.org>]

Randy Smith wrote:
> 
> 
> Philippe Gerum wrote:
> 
>>
>> Make sure to read this then (also includes simple porting tips from 
>> RTAI to the native API):
>>
>> http://download.gna.org/xenomai/documentation/branches/v2.1.x/pdf/Native-API-Tour.pdf 
>>
> 
> 
> Thanks...Already been looking it over.
> 
>>
>>> I must have installed xenomai incorrectly as my code is not compiling 
>>> without some header files complaining about basic types like atomic_t 
>>> not being defined.  I have a kernel source tree installed in a 
>>> non-standard place, lets call it /home/randy/linux and the xenomai 
>>> package under /home/randy/xenomai-2.1.0.  I have applied the adios 
>>> patch and done the prepare_kernel.sh thing.  So far so good.  I can 
>>> then do make menuconfig and setup the realtime stuff then make uImage 
>>> and the kernel builds correctly (yes, I am cross-compiling for a 
>>> powerpc).  That all works ok.
>>>
>>> Where I'm confused is this.  Do I then do something like
>>>
>>> $ cd /home/randy
>>> $ mkdir xenomai && cd xenomai
>>> $ ../xenomai-2.1.0/configure --build=i686-linux --host=ppc-linux 
>>> --prefix=/home/randy
>>> $ make all
>>> $ make install
>>
>>
>> Make sure reading configure's output that the right ppc 
>> (cross-)compiler is found and used.
> 
> Yes, the correct cross-compiler is being used.
> 
>>
>>>
>>> OR should I be in the kernel tree such as
>>>
>>> $ cd /home/randy/linux
>>> $ ../xenomai-2.1.0/configure --build=i686-linux --host=ppc-linux 
>>> --prefix=/home/randy/linux
>>>
>>
>> This part is to build the user-space (only) support, so #1 is the 
>> right one. Since 2.1, Xenomai clearly splits the kernel side from the 
>> user-space support, so building the RT subsystem is just a matter of 
>> configuring yet-another-linux-subsystem using the regular Linux 
>> Kconfig interface, instead of fiddling with 
>> yet-another-nonstandard-kconfig. It also makes possible to build such 
>> RT subsystem statically into the kernel, and not only as external 
>> modules, which is good for our poor TLBs.
>>
>> If we keep on being good boys in the future and don't change the skin 
>> system call numbers and prototypes each time at full moon, we might 
>> even reach some kind of reasonably stable ABI, so that the user-space 
>> stuff could run on the largest possible set of older versions of the 
>> kernel side.
>>
>> README.INSTALL gives simple examples for building the user-space 
>> support for various archs; maybe this would help.
> 
> It got me started, but I was unsure (since my case is such a unique one 
> of cross-compiling and source tree in non-standard place) of what to do.
> 
>>
>>> ???
>>>
>>> One of the problems I am seeing is that after the make all and make 
>>> install, there is built, an include file tree under 
>>> /home/randy/include and when I include this path on the compiler 
>>> command line, I get circular references such as
>>>
>>> #include <asm/atomic.h> from line 29 of /home/randy/include/asm/atomic.h
>>>
>>> which should refer to the kernel include of 
>>> /home/randy/linux/include/asm/atomic.h but instead picks up itself 
>>> again and doesn't define the atomic_t (among other things)
>>>
>>> Obviously I'm doing something wrong and any help would be appreciated.
>>>
>>
>> Something looks like being badly trashed in your source tree, which 
>> would be quite possible if #2 is current.
> 
> No, I haven't done the second case yet.  I am having so many problems 
> compiling the kernel modules with case #1 that I thought I did something 
> wrong.

Ok, just to be 100% sure, I've just tried the following on a stock 2.1.0 
grabbed from the mirror:

../somewhere/xenomai-2.1.0/configure --build=i686-linux --host=ppc-linux 
--prefix=$HOME/xenomai-install  CC=ppc_82xx-gcc CXX=ppc_82xx-gcc 
AR=ppc_82xx-ar LD=ppc_82xx-ld

The resulting tree builds and install fine under $HOME/xenomai-install 
afterwards. There is no kernel dependency whatsoever since the 
user-space support does not even know about the kernel version which is 
going to be used in the first place, so we should be able to get the 
same user-space setup. Could you try rebuilding in a clean build tree 
using equivalent switches at config time, and let me know of the 
outcome? TIA,

-- 

Philippe.