[Xenomai-help] compiling xenomai on x86_64

[Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

Hi,

I'm dumb x86 user who unfortunately just seem to have tumbled in the
cross-compilation trap: I'm trying to generate i586 code on a fancy new
and fast x86_64 compilation host. I got the kernel compiled with
ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
cross tool chain), but I failed to compile xenomai against that kernel
in the following. Which magic switch do I have to apply and where?

Many thanks in advance,
Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [Xenomai-help] compiling xenomai on x86_64

[Heikki Lindholm]

Jan Kiszka kirjoitti:
> Hi,
> 
> I'm dumb x86 user who unfortunately just seem to have tumbled in the
> cross-compilation trap: I'm trying to generate i586 code on a fancy new
> and fast x86_64 compilation host. I got the kernel compiled with
> ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
> cross tool chain), but I failed to compile xenomai against that kernel
> in the following. Which magic switch do I have to apply and where?

As dumb a guess: -m32 compiler switch?

-- Heikki Lindholm

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

Heikki Lindholm wrote:
> Jan Kiszka kirjoitti:
> 
>> Hi,
>>
>> I'm dumb x86 user who unfortunately just seem to have tumbled in the
>> cross-compilation trap: I'm trying to generate i586 code on a fancy new
>> and fast x86_64 compilation host. I got the kernel compiled with
>> ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
>> cross tool chain), but I failed to compile xenomai against that kernel
>> in the following. Which magic switch do I have to apply and where?
> 
> 
> As dumb a guess: -m32 compiler switch?
> 

Yes, I know, that would help. But where to feed this argument into the
build system?

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [Xenomai-help] compiling xenomai on x86_64

[Heikki Lindholm]

Jan Kiszka kirjoitti:
> Heikki Lindholm wrote:
> 
>>Jan Kiszka kirjoitti:
>>
>>
>>>Hi,
>>>
>>>I'm dumb x86 user who unfortunately just seem to have tumbled in the
>>>cross-compilation trap: I'm trying to generate i586 code on a fancy new
>>>and fast x86_64 compilation host. I got the kernel compiled with
>>>ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
>>>cross tool chain), but I failed to compile xenomai against that kernel
>>>in the following. Which magic switch do I have to apply and where?
>>
>>
>>As dumb a guess: -m32 compiler switch?
>>
> 
> 
> Yes, I know, that would help. But where to feed this argument into the
> build system?

I would try makefile (and perhaps config/kconfig/Makefile*) and command 
line 'CC="gcc -m32" CXX="gcc -m32" make menuconfig/install' to be sure.

-- Heikki Lindholm

Re: [Xenomai-help] compiling xenomai on x86_64

[Philippe Gerum]

Heikki Lindholm wrote:
> Jan Kiszka kirjoitti:
> 
>> Heikki Lindholm wrote:
>>
>>> Jan Kiszka kirjoitti:
>>>
>>>
>>>> Hi,
>>>>
>>>> I'm dumb x86 user who unfortunately just seem to have tumbled in the
>>>> cross-compilation trap: I'm trying to generate i586 code on a fancy new
>>>> and fast x86_64 compilation host. I got the kernel compiled with
>>>> ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
>>>> cross tool chain), but I failed to compile xenomai against that kernel
>>>> in the following. Which magic switch do I have to apply and where?
>>>
>>>
>>>
>>> As dumb a guess: -m32 compiler switch?
>>>
>>
>>
>> Yes, I know, that would help. But where to feed this argument into the
>> build system?
> 
> 
> I would try makefile (and perhaps config/kconfig/Makefile*) and command 
> line 'CC="gcc -m32" CXX="gcc -m32" make menuconfig/install' to be sure.
>

You should be able to do that just by reconfiguring:

cd build && make reconfig CC="gcc -m32"

> -- Heikki Lindholm
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 

Philippe.

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]

Philippe Gerum wrote:
> Heikki Lindholm wrote:
> 
>> Jan Kiszka kirjoitti:
>>
>>> Heikki Lindholm wrote:
>>>
>>>> Jan Kiszka kirjoitti:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm dumb x86 user who unfortunately just seem to have tumbled in the
>>>>> cross-compilation trap: I'm trying to generate i586 code on a fancy
>>>>> new
>>>>> and fast x86_64 compilation host. I got the kernel compiled with
>>>>> ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
>>>>> cross tool chain), but I failed to compile xenomai against that kernel
>>>>> in the following. Which magic switch do I have to apply and where?
>>>>
>>>>
>>>>
>>>>
>>>> As dumb a guess: -m32 compiler switch?
>>>>
>>>
>>>
>>> Yes, I know, that would help. But where to feed this argument into the
>>> build system?
>>
>>
>>
>> I would try makefile (and perhaps config/kconfig/Makefile*) and
>> command line 'CC="gcc -m32" CXX="gcc -m32" make menuconfig/install' to
>> be sure.
>>
> 
> You should be able to do that just by reconfiguring:
> 
> cd build && make reconfig CC="gcc -m32"
> 

... would have been too easy: :-/

[after "make menuconfig ARCH=i386"]
gcchost2:/tmp/xenomai/build # make reconfig CC="gcc -m32"
make[1]: Entering directory `/tmp/xenomai/build'
configure: error: unrecognized option: -m32
Try `/tmp/xenomai/configure --help' for more information.
make[1]: *** [config.status] Error 1
make[1]: Leaving directory `/tmp/xenomai/build'
make: *** [reconfig] Error 2

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [Xenomai-help] compiling xenomai on x86_64

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>Heikki Lindholm wrote:
>>
>>
>>>Jan Kiszka kirjoitti:
>>>
>>>
>>>>Heikki Lindholm wrote:
>>>>
>>>>
>>>>>Jan Kiszka kirjoitti:
>>>>>
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>I'm dumb x86 user who unfortunately just seem to have tumbled in the
>>>>>>cross-compilation trap: I'm trying to generate i586 code on a fancy
>>>>>>new
>>>>>>and fast x86_64 compilation host. I got the kernel compiled with
>>>>>>ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
>>>>>>cross tool chain), but I failed to compile xenomai against that kernel
>>>>>>in the following. Which magic switch do I have to apply and where?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>As dumb a guess: -m32 compiler switch?
>>>>>
>>>>
>>>>
>>>>Yes, I know, that would help. But where to feed this argument into the
>>>>build system?
>>>
>>>
>>>
>>>I would try makefile (and perhaps config/kconfig/Makefile*) and
>>>command line 'CC="gcc -m32" CXX="gcc -m32" make menuconfig/install' to
>>>be sure.
>>>
>>
>>You should be able to do that just by reconfiguring:
>>
>>cd build && make reconfig CC="gcc -m32"
>>
> 
> 
> ... would have been too easy: :-/
> 
> [after "make menuconfig ARCH=i386"]
> gcchost2:/tmp/xenomai/build # make reconfig CC="gcc -m32"
> make[1]: Entering directory `/tmp/xenomai/build'
> configure: error: unrecognized option: -m32
> Try `/tmp/xenomai/configure --help' for more information.
> make[1]: *** [config.status] Error 1
> make[1]: Leaving directory `/tmp/xenomai/build'
> make: *** [reconfig] Error 2
> 

make reconfig CC="\"gcc -m32\""

(Ok, ok, we'll get rid of autoconf for kernel modules in 2.1...)

-- 

Philippe.

Re: [Xenomai-help] compiling xenomai on x86_64

[Philippe Gerum]

Philippe Gerum wrote:
> Jan Kiszka wrote:
> 
>> Philippe Gerum wrote:
>>
>>> Heikki Lindholm wrote:
>>>
>>>
>>>> Jan Kiszka kirjoitti:
>>>>
>>>>
>>>>> Heikki Lindholm wrote:
>>>>>
>>>>>
>>>>>> Jan Kiszka kirjoitti:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm dumb x86 user who unfortunately just seem to have tumbled in the
>>>>>>> cross-compilation trap: I'm trying to generate i586 code on a fancy
>>>>>>> new
>>>>>>> and fast x86_64 compilation host. I got the kernel compiled with
>>>>>>> ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
>>>>>>> cross tool chain), but I failed to compile xenomai against that 
>>>>>>> kernel
>>>>>>> in the following. Which magic switch do I have to apply and where?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> As dumb a guess: -m32 compiler switch?
>>>>>>
>>>>>
>>>>>
>>>>> Yes, I know, that would help. But where to feed this argument into the
>>>>> build system?
>>>>
>>>>
>>>>
>>>>
>>>> I would try makefile (and perhaps config/kconfig/Makefile*) and
>>>> command line 'CC="gcc -m32" CXX="gcc -m32" make menuconfig/install' to
>>>> be sure.
>>>>
>>>
>>> You should be able to do that just by reconfiguring:
>>>
>>> cd build && make reconfig CC="gcc -m32"
>>>
>>
>>
>> ... would have been too easy: :-/
>>
>> [after "make menuconfig ARCH=i386"]
>> gcchost2:/tmp/xenomai/build # make reconfig CC="gcc -m32"
>> make[1]: Entering directory `/tmp/xenomai/build'
>> configure: error: unrecognized option: -m32
>> Try `/tmp/xenomai/configure --help' for more information.
>> make[1]: *** [config.status] Error 1
>> make[1]: Leaving directory `/tmp/xenomai/build'
>> make: *** [reconfig] Error 2
>>
> 
> make reconfig CC="\"gcc -m32\""
>

Please resync from the SVN head too; I've added the necessary quoting hackery 
for the above to fully work.

> (Ok, ok, we'll get rid of autoconf for kernel modules in 2.1...)
> 


-- 

Philippe.

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 4578 bytes --]

Philippe Gerum wrote:
> Philippe Gerum wrote:
> 
>> Jan Kiszka wrote:
>>
>>> Philippe Gerum wrote:
>>>
>>>> Heikki Lindholm wrote:
>>>>
>>>>
>>>>> Jan Kiszka kirjoitti:
>>>>>
>>>>>
>>>>>> Heikki Lindholm wrote:
>>>>>>
>>>>>>
>>>>>>> Jan Kiszka kirjoitti:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm dumb x86 user who unfortunately just seem to have tumbled in
>>>>>>>> the
>>>>>>>> cross-compilation trap: I'm trying to generate i586 code on a fancy
>>>>>>>> new
>>>>>>>> and fast x86_64 compilation host. I got the kernel compiled with
>>>>>>>> ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
>>>>>>>> cross tool chain), but I failed to compile xenomai against that
>>>>>>>> kernel
>>>>>>>> in the following. Which magic switch do I have to apply and where?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> As dumb a guess: -m32 compiler switch?
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes, I know, that would help. But where to feed this argument into
>>>>>> the
>>>>>> build system?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I would try makefile (and perhaps config/kconfig/Makefile*) and
>>>>> command line 'CC="gcc -m32" CXX="gcc -m32" make menuconfig/install' to
>>>>> be sure.
>>>>>
>>>>
>>>> You should be able to do that just by reconfiguring:
>>>>
>>>> cd build && make reconfig CC="gcc -m32"
>>>>
>>>
>>>
>>> ... would have been too easy: :-/
>>>
>>> [after "make menuconfig ARCH=i386"]
>>> gcchost2:/tmp/xenomai/build # make reconfig CC="gcc -m32"
>>> make[1]: Entering directory `/tmp/xenomai/build'
>>> configure: error: unrecognized option: -m32
>>> Try `/tmp/xenomai/configure --help' for more information.
>>> make[1]: *** [config.status] Error 1
>>> make[1]: Leaving directory `/tmp/xenomai/build'
>>> make: *** [reconfig] Error 2
>>>
>>
>> make reconfig CC="\"gcc -m32\""
>>
> 
> Please resync from the SVN head too; I've added the necessary quoting
> hackery for the above to fully work.
> 

Great, thanks.

Now I likely run into some gcc-4 issue:

make[3]: Entering directory `/tmp/xenomai/build/skins/native/lib'
if /bin/sh ../../../libtool --mode=compile --tag=CC gcc -m32
-DHAVE_CONFIG_H -I. -I/tmp/xenomai/skins/native/lib -I../../../include
-O2 -I/tmp/linux-2.6.13.1/include -D_GNU_SOURCE -D_REENTRANT -D__XENO__
 -march=i586 -Wall -pipe -fstrict-aliasing -Wno-strict-aliasing
-D__IN_XENO__ -Wstrict-prototypes -I../../../include
-I/tmp/xenomai/include -I/tmp/xenomai/skins/native/lib/../..    -MT
libnative_la-task.lo -MD -MP -MF ".deps/libnative_la-task.Tpo" -c -o
libnative_la-task.lo `test -f 'task.c' || echo
'/tmp/xenomai/skins/native/lib/'`task.c; \
then mv -f ".deps/libnative_la-task.Tpo" ".deps/libnative_la-task.Plo";
else rm -f ".deps/libnative_la-task.Tpo"; exit 1; fi
 gcc -m32 -DHAVE_CONFIG_H -I. -I/tmp/xenomai/skins/native/lib
-I../../../include -O2 -I/tmp/linux-2.6.13.1/include -D_GNU_SOURCE
-D_REENTRANT -D__XENO__ -march=i586 -Wall -pipe -fstrict-aliasing
-Wno-strict-aliasing -D__IN_XENO__ -Wstrict-prototypes
-I../../../include -I/tmp/xenomai/include
-I/tmp/xenomai/skins/native/lib/../.. -MT libnative_la-task.lo -MD -MP
-MF .deps/libnative_la-task.Tpo -c /tmp/xenomai/skins/native/lib/task.c
 -fPIC -DPIC -o .libs/libnative_la-task.o
In file included from /tmp/linux-2.6.13.1/include/asm/math_emu.h:4,
                 from /tmp/linux-2.6.13.1/include/asm/processor.h:11,
                 from /tmp/linux-2.6.13.1/include/asm/atomic.h:6,
                 from ../../../include/nucleus/asm/atomic.h:44,
                 from /tmp/xenomai/include/nucleus/system.h:33,
                 from /tmp/xenomai/include/nucleus/asm-generic/system.h:560,
                 from ../../../include/nucleus/asm/system.h:25,
                 from /tmp/xenomai/include/nucleus/types.h:40,
                 from /tmp/xenomai/include/nucleus/queue.h:23,
                 from /tmp/xenomai/include/nucleus/timer.h:23,
                 from /tmp/xenomai/include/nucleus/thread.h:23,
                 from /tmp/xenomai/skins/native/lib/../../native/task.h:26,
                 from /tmp/xenomai/skins/native/lib/task.c:28:
/tmp/linux-2.6.13.1/include/asm/sigcontext.h:20: error: redefinition of
struct _fpreg
/tmp/linux-2.6.13.1/include/asm/sigcontext.h:25: error: redefinition of
struct _fpxreg
/tmp/linux-2.6.13.1/include/asm/sigcontext.h:31: error: redefinition of
struct _xmmreg
/tmp/linux-2.6.13.1/include/asm/sigcontext.h:35: error: redefinition of
struct _fpstate
/tmp/linux-2.6.13.1/include/asm/sigcontext.h:59: error: redefinition of
struct sigcontext

Any idea where this comes from? If not, I will dig deeper.

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2896 bytes --]

Jan Kiszka wrote:
> ...
> make[3]: Entering directory `/tmp/xenomai/build/skins/native/lib'
> if /bin/sh ../../../libtool --mode=compile --tag=CC gcc -m32
> -DHAVE_CONFIG_H -I. -I/tmp/xenomai/skins/native/lib -I../../../include
> -O2 -I/tmp/linux-2.6.13.1/include -D_GNU_SOURCE -D_REENTRANT -D__XENO__
>  -march=i586 -Wall -pipe -fstrict-aliasing -Wno-strict-aliasing
> -D__IN_XENO__ -Wstrict-prototypes -I../../../include
> -I/tmp/xenomai/include -I/tmp/xenomai/skins/native/lib/../..    -MT
> libnative_la-task.lo -MD -MP -MF ".deps/libnative_la-task.Tpo" -c -o
> libnative_la-task.lo `test -f 'task.c' || echo
> '/tmp/xenomai/skins/native/lib/'`task.c; \
> then mv -f ".deps/libnative_la-task.Tpo" ".deps/libnative_la-task.Plo";
> else rm -f ".deps/libnative_la-task.Tpo"; exit 1; fi
>  gcc -m32 -DHAVE_CONFIG_H -I. -I/tmp/xenomai/skins/native/lib
> -I../../../include -O2 -I/tmp/linux-2.6.13.1/include -D_GNU_SOURCE
> -D_REENTRANT -D__XENO__ -march=i586 -Wall -pipe -fstrict-aliasing
> -Wno-strict-aliasing -D__IN_XENO__ -Wstrict-prototypes
> -I../../../include -I/tmp/xenomai/include
> -I/tmp/xenomai/skins/native/lib/../.. -MT libnative_la-task.lo -MD -MP
> -MF .deps/libnative_la-task.Tpo -c /tmp/xenomai/skins/native/lib/task.c
>  -fPIC -DPIC -o .libs/libnative_la-task.o
> In file included from /tmp/linux-2.6.13.1/include/asm/math_emu.h:4,
>                  from /tmp/linux-2.6.13.1/include/asm/processor.h:11,
>                  from /tmp/linux-2.6.13.1/include/asm/atomic.h:6,
>                  from ../../../include/nucleus/asm/atomic.h:44,
>                  from /tmp/xenomai/include/nucleus/system.h:33,
>                  from /tmp/xenomai/include/nucleus/asm-generic/system.h:560,
>                  from ../../../include/nucleus/asm/system.h:25,
>                  from /tmp/xenomai/include/nucleus/types.h:40,
>                  from /tmp/xenomai/include/nucleus/queue.h:23,
>                  from /tmp/xenomai/include/nucleus/timer.h:23,
>                  from /tmp/xenomai/include/nucleus/thread.h:23,
>                  from /tmp/xenomai/skins/native/lib/../../native/task.h:26,
>                  from /tmp/xenomai/skins/native/lib/task.c:28:
> /tmp/linux-2.6.13.1/include/asm/sigcontext.h:20: error: redefinition of
> struct _fpreg
> /tmp/linux-2.6.13.1/include/asm/sigcontext.h:25: error: redefinition of
> struct _fpxreg
> /tmp/linux-2.6.13.1/include/asm/sigcontext.h:31: error: redefinition of
> struct _xmmreg
> /tmp/linux-2.6.13.1/include/asm/sigcontext.h:35: error: redefinition of
> struct _fpstate
> /tmp/linux-2.6.13.1/include/asm/sigcontext.h:59: error: redefinition of
> struct sigcontext
> 
> Any idea where this comes from? If not, I will dig deeper.
> 

I just analysed this further: the problem disappears when I manually
remove any "-I<path-to-kernel-includes>" from the makefiles. Seems to be
the well-known user space include issue again... ;)

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [Xenomai-help] compiling xenomai on x86_64

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > Jan Kiszka wrote:
 > I just analysed this further: the problem disappears when I manually
 > remove any "-I<path-to-kernel-includes>" from the makefiles. Seems to be
 > the well-known user space include issue again... ;)

This is wrong, the include files that should be used are those from the
Adeos/I-pipe patched 2.6 kernel you are compiling for, not those which
come from your distribution.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Jan Kiszka wrote:
>  > I just analysed this further: the problem disappears when I manually
>  > remove any "-I<path-to-kernel-includes>" from the makefiles. Seems to be
>  > the well-known user space include issue again... ;)
> 
> This is wrong, the include files that should be used are those from the
> Adeos/I-pipe patched 2.6 kernel you are compiling for, not those which
> come from your distribution.
> 

Yep, true. But then the build system is still somehow confused, because
it seems to include headers from both sources - otherwise I would not
see redefinitions when only asm/sigcontext.h contains the structs.

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [Xenomai-help] compiling xenomai on x86_64

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > I just analysed this further: the problem disappears when I manually
 > remove any "-I<path-to-kernel-includes>" from the makefiles. Seems to be
 > the well-known user space include issue again... ;)

I tried to compile every kernel arch/i386 has a patch for with gcc 2.95,
3.3 and 3.4, and I saw no issue with inclusions of kernel headers
from user-space. At all.

So, there is definitely something you are doing differently from me. 
If this issue is different from the '-m32' flag issue, could you please
fill a bug report, and this time, attach the exact procedure you are
following to compile (whether in-tree, or out-of-tree, whether using
configure or Kconfig, everything that would allow someone to ), the
.config and .xeno_config files you used, in order for me to be able to
reproduce the problem you observed ?

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2272 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > I just analysed this further: the problem disappears when I manually
>  > remove any "-I<path-to-kernel-includes>" from the makefiles. Seems to be
>  > the well-known user space include issue again... ;)
> 
> I tried to compile every kernel arch/i386 has a patch for with gcc 2.95,
> 3.3 and 3.4, and I saw no issue with inclusions of kernel headers
> from user-space. At all.

I think you were lucky. As far as I remember, it is generally no good
idea to include kernel header for userspace compilation as long as you
do not _exactly_ know (or test) what they bring with them. Some
structures or defines locate in different headers under /usr/include
compared to some kernel tree. So, if you are not lucky, you drag those
definitions in twice - see below.

> 
> So, there is definitely something you are doing differently from me. 
> If this issue is different from the '-m32' flag issue, could you please
> fill a bug report, and this time, attach the exact procedure you are
> following to compile (whether in-tree, or out-of-tree, whether using
> configure or Kconfig, everything that would allow someone to ), the
> .config and .xeno_config files you used, in order for me to be able to
> reproduce the problem you observed ?
> 

As I'm not sure if you can reproduce it easily without my environment
(that damn x86_64 gcc4 on SuSE10), I digged a little bit deeper, and
here is a new theory:

The compilation fails in skins/native/libs/task.c (there exist similar
files in other skins as well). The error: structures in
<linux>/include/asm/sigcontext.h are being redefined. Unfortunately, gcc
does not tell me where the first definition was. But here is my finding:
commenting out #include <signal.h> in libs/task.c makes that error
disappear. Following the include chain of /usr/include/signal.h
(userspace headers...), you get to /usr/include/bits/sigcontext.h.
Bingo. On the x86_64 box all structs are defined here according to the
target address width. And as /usr/include/bits/sigcontext.h and
<linux>/include/asm/sigcontext.h do not exclude each other, we get
redefines.

To sum up, I still think that kernel headers need to be avoided in
userspace. Or we have to work around such issues case-by-case...

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [Xenomai-help] compiling xenomai on x86_64

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > Gilles Chanteperdrix wrote:
 > > Jan Kiszka wrote:
 > >  > I just analysed this further: the problem disappears when I manually
 > >  > remove any "-I<path-to-kernel-includes>" from the makefiles. Seems to be
 > >  > the well-known user space include issue again... ;)
 > > 
 > > I tried to compile every kernel arch/i386 has a patch for with gcc 2.95,
 > > 3.3 and 3.4, and I saw no issue with inclusions of kernel headers
 > > from user-space. At all.
 > 
 > I think you were lucky. As far as I remember, it is generally no good
 > idea to include kernel header for userspace compilation as long as you
 > do not _exactly_ know (or test) what they bring with them. Some
 > structures or defines locate in different headers under /usr/include
 > compared to some kernel tree. So, if you are not lucky, you drag those
 > definitions in twice - see below.
 > 
 > > 
 > > So, there is definitely something you are doing differently from me. 
 > > If this issue is different from the '-m32' flag issue, could you please
 > > fill a bug report, and this time, attach the exact procedure you are
 > > following to compile (whether in-tree, or out-of-tree, whether using
 > > configure or Kconfig, everything that would allow someone to ), the
 > > .config and .xeno_config files you used, in order for me to be able to
 > > reproduce the problem you observed ?
 > > 
 > 
 > As I'm not sure if you can reproduce it easily without my environment
 > (that damn x86_64 gcc4 on SuSE10), I digged a little bit deeper, and
 > here is a new theory:
 > 
 > The compilation fails in skins/native/libs/task.c (there exist similar
 > files in other skins as well). The error: structures in
 > <linux>/include/asm/sigcontext.h are being redefined. Unfortunately, gcc
 > does not tell me where the first definition was. But here is my finding:
 > commenting out #include <signal.h> in libs/task.c makes that error
 > disappear. Following the include chain of /usr/include/signal.h
 > (userspace headers...), you get to /usr/include/bits/sigcontext.h.

I still do not get it: you are compiling on x86_64, so headers in
/usr/include are for x86_64, not ia32. Are you sure you do not need some
glibc-ia32-cross-devel package, or something like that ? The kernel does
not have these problems, since it is compiled with -ffreestanding.

Are you able to compile an ia32 user-space  hello world for example ?

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2796 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Gilles Chanteperdrix wrote:
>  > > Jan Kiszka wrote:
>  > >  > I just analysed this further: the problem disappears when I manually
>  > >  > remove any "-I<path-to-kernel-includes>" from the makefiles. Seems to be
>  > >  > the well-known user space include issue again... ;)
>  > > 
>  > > I tried to compile every kernel arch/i386 has a patch for with gcc 2.95,
>  > > 3.3 and 3.4, and I saw no issue with inclusions of kernel headers
>  > > from user-space. At all.
>  > 
>  > I think you were lucky. As far as I remember, it is generally no good
>  > idea to include kernel header for userspace compilation as long as you
>  > do not _exactly_ know (or test) what they bring with them. Some
>  > structures or defines locate in different headers under /usr/include
>  > compared to some kernel tree. So, if you are not lucky, you drag those
>  > definitions in twice - see below.
>  > 
>  > > 
>  > > So, there is definitely something you are doing differently from me. 
>  > > If this issue is different from the '-m32' flag issue, could you please
>  > > fill a bug report, and this time, attach the exact procedure you are
>  > > following to compile (whether in-tree, or out-of-tree, whether using
>  > > configure or Kconfig, everything that would allow someone to ), the
>  > > .config and .xeno_config files you used, in order for me to be able to
>  > > reproduce the problem you observed ?
>  > > 
>  > 
>  > As I'm not sure if you can reproduce it easily without my environment
>  > (that damn x86_64 gcc4 on SuSE10), I digged a little bit deeper, and
>  > here is a new theory:
>  > 
>  > The compilation fails in skins/native/libs/task.c (there exist similar
>  > files in other skins as well). The error: structures in
>  > <linux>/include/asm/sigcontext.h are being redefined. Unfortunately, gcc
>  > does not tell me where the first definition was. But here is my finding:
>  > commenting out #include <signal.h> in libs/task.c makes that error
>  > disappear. Following the include chain of /usr/include/signal.h
>  > (userspace headers...), you get to /usr/include/bits/sigcontext.h.
> 
> I still do not get it: you are compiling on x86_64, so headers in
> /usr/include are for x86_64, not ia32. Are you sure you do not need some

They are for both. You can compile some helloworld64 by calling gcc
without arguments or as easily a helloworld32 by running "gcc -m32" -
all on the same box withouth additional cross-tool stuff.

> glibc-ia32-cross-devel package, or something like that ? The kernel does
> not have these problems, since it is compiled with -ffreestanding.

...and it does not include user space headers.

> 
> Are you able to compile an ia32 user-space  hello world for example ?
> 

Yes, see above.

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [Xenomai-help] compiling xenomai on x86_64

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > They are for both. You can compile some helloworld64 by calling gcc
 > without arguments or as easily a helloworld32 by running "gcc -m32" -
 > all on the same box withouth additional cross-tool stuff.

Ok, the -m32 fix to configure.in is what I can do for now, it is in the
repository. Could you try it ?

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > They are for both. You can compile some helloworld64 by calling gcc
>  > without arguments or as easily a helloworld32 by running "gcc -m32" -
>  > all on the same box withouth additional cross-tool stuff.
> 
> Ok, the -m32 fix to configure.in is what I can do for now, it is in the
> repository. Could you try it ?
> 

Sorry, this doesn't work (but it was my first guess as well).

The problem is that "-m32" comes from the CC-overloading in
arch/i386/Makefile, and this is not visible to the grabbing trick in
configure.in. Moreover, this would not address ld and ar flags.

I'm not deep enough into this to see where one can best get the
information from. All I know is that - by chance? - RTnet's stolen build
system did not suffer from this effect the last time I checked. I think
I will have to re-check.

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> 
>>Jan Kiszka wrote:
>> > They are for both. You can compile some helloworld64 by calling gcc
>> > without arguments or as easily a helloworld32 by running "gcc -m32" -
>> > all on the same box withouth additional cross-tool stuff.
>>
>>Ok, the -m32 fix to configure.in is what I can do for now, it is in the
>>repository. Could you try it ?
>>
> 
> 
> Sorry, this doesn't work (but it was my first guess as well).
> 
> The problem is that "-m32" comes from the CC-overloading in
> arch/i386/Makefile, and this is not visible to the grabbing trick in
> configure.in. Moreover, this would not address ld and ar flags.
> 
> I'm not deep enough into this to see where one can best get the
> information from. All I know is that - by chance? - RTnet's stolen build
> system did not suffer from this effect the last time I checked. I think
> I will have to re-check.
> 

I know now what makes the difference: setting CC=\"$CC\" in
XENO_KBUILD_CMD. Xenomai does this and seems to override the "-m32"
extension of the kernel build system, RTnet does not.

I guess that there is a reason for passing CC to the kernel build system
and RTnet is ignoring some use case here, but then we likely have to
pass an adapted CC, just like linux/arch/i386/Makefile does.

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

[Xenomai-help] newbie question

[Ignacio García Pérez]

Hi,

I'm quite new to xenomai (switching from RTAI). I noticed that the
latency_rt.ko module fails to start the timer if the posix skin module
(xeno_posix.ko) is loaded. Is this the expected behaviour?

Thanks.

Re: [Xenomai-help] newbie question

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 694 bytes --]

Ignacio García Pérez wrote:
> Hi,
> 
> I'm quite new to xenomai (switching from RTAI). I noticed that the
> latency_rt.ko module fails to start the timer if the posix skin module
> (xeno_posix.ko) is loaded. Is this the expected behaviour?
> 

Expected yes, wanted no.

Avoid xeno_posix being loaded for this test. It starts the timer when
being insmoded, while latency_rt (as a xeno_native application) does
this on program start up (and fails if it already runs).

I think I already mentioned here that I don't like this situation and
that xeno_native should provide the same timer control interface as the
other skins, didn't I? Will file a feature request now! :)

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [Xenomai-help] newbie question

[Philippe Gerum]

Ignacio García Pérez wrote:
> Hi,
> 
> I'm quite new to xenomai (switching from RTAI). I noticed that the
> latency_rt.ko module fails to start the timer if the posix skin module
> (xeno_posix.ko) is loaded. Is this the expected behaviour?
>

Yes and no. There is a change pending in my tree that makes rt_time_start() a 
bit smarter, trying its best effort to check whether the requested setting fits 
any current one, in which case the call returns without error. In the case you 
mentioned, both timer setups at nucleus level asked for oneshot, so this should 
have been ok with this patch, instead of bailing out on error rather uselessly. 
The UVM skin already enforces this for instance. I have just committed it to the 
SVN repo.

But on the long-term, I recall that Jan once asked for a normalized approach, 
allowing the timer to be set at configuration/loadup time for each skin, just 
keeping the system call as is for legacy/unusual/dynamic purposes. I agree with 
that, most of us don't really need to fiddle with the timer settings while the 
application runs, so having it statically configurable is more user-friendly and 
less error-prone.

-- 

Philippe.

Re: [Xenomai-help] newbie question

[Gilles Chanteperdrix]

Philippe Gerum wrote:
 > Ignacio Garc~a P~rez wrote:
 > > Hi,
 > > 
 > > I'm quite new to xenomai (switching from RTAI). I noticed that the
 > > latency_rt.ko module fails to start the timer if the posix skin module
 > > (xeno_posix.ko) is loaded. Is this the expected behaviour?
 > >
 > 
 > Yes and no. There is a change pending in my tree that makes rt_time_start() a 
 > bit smarter, trying its best effort to check whether the requested setting fits 
 > any current one, in which case the call returns without error. In the case you 
 > mentioned, both timer setups at nucleus level asked for oneshot, so this should 
 > have been ok with this patch, instead of bailing out on error rather uselessly. 
 > The UVM skin already enforces this for instance. I have just committed it to the 
 > SVN repo.

The problem is that you also have to make the module_exit function
smarter and avoid to stop the system timer if another module is
running. This means adding a sort of reference counter to the system
timer.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] newbie question

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>  > Ignacio Garc~a P~rez wrote:
>  > > Hi,
>  > > 
>  > > I'm quite new to xenomai (switching from RTAI). I noticed that the
>  > > latency_rt.ko module fails to start the timer if the posix skin module
>  > > (xeno_posix.ko) is loaded. Is this the expected behaviour?
>  > >
>  > 
>  > Yes and no. There is a change pending in my tree that makes rt_time_start() a 
>  > bit smarter, trying its best effort to check whether the requested setting fits 
>  > any current one, in which case the call returns without error. In the case you 
>  > mentioned, both timer setups at nucleus level asked for oneshot, so this should 
>  > have been ok with this patch, instead of bailing out on error rather uselessly. 
>  > The UVM skin already enforces this for instance. I have just committed it to the 
>  > SVN repo.
> 
> The problem is that you also have to make the module_exit function
> smarter and avoid to stop the system timer if another module is
> running. This means adding a sort of reference counter to the system
> timer.
> 

Another reason to look for a different way. The timer is a global
resource, let's manage it at a central place: the nucleus (module
parameter) plus maybe some sysfs variable. The days are over when skins
could decide about the whole system on their own ;). And it's also much
more comprehensible for the user when (s)he only has to look at one
place for tuning this parameter.

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [Xenomai-help] compiling xenomai on x86_64

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > I know now what makes the difference: setting CC=\"$CC\" in
 > XENO_KBUILD_CMD. Xenomai does this and seems to override the "-m32"
 > extension of the kernel build system, RTnet does not.

Of course ! stupid me. In makefiles, the variables assignment passed on
command line take precedence over the one made in the makefiles
themselves. And the environment variable have the least precedence, so I
guess passing CC in Kbuild environment instead of on command line should
do the trick.


-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2368 bytes --]

Philippe Gerum wrote:
> Jan Kiszka wrote:
> 
>> Philippe Gerum wrote:
>>
>>> Heikki Lindholm wrote:
>>>
>>>
>>>> Jan Kiszka kirjoitti:
>>>>
>>>>
>>>>> Heikki Lindholm wrote:
>>>>>
>>>>>
>>>>>> Jan Kiszka kirjoitti:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm dumb x86 user who unfortunately just seem to have tumbled in the
>>>>>>> cross-compilation trap: I'm trying to generate i586 code on a fancy
>>>>>>> new
>>>>>>> and fast x86_64 compilation host. I got the kernel compiled with
>>>>>>> ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
>>>>>>> cross tool chain), but I failed to compile xenomai against that
>>>>>>> kernel
>>>>>>> in the following. Which magic switch do I have to apply and where?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> As dumb a guess: -m32 compiler switch?
>>>>>>
>>>>>
>>>>>
>>>>> Yes, I know, that would help. But where to feed this argument into the
>>>>> build system?
>>>>
>>>>
>>>>
>>>>
>>>> I would try makefile (and perhaps config/kconfig/Makefile*) and
>>>> command line 'CC="gcc -m32" CXX="gcc -m32" make menuconfig/install' to
>>>> be sure.
>>>>
>>>
>>> You should be able to do that just by reconfiguring:
>>>
>>> cd build && make reconfig CC="gcc -m32"
>>>
>>
>>
>> ... would have been too easy: :-/
>>
>> [after "make menuconfig ARCH=i386"]
>> gcchost2:/tmp/xenomai/build # make reconfig CC="gcc -m32"
>> make[1]: Entering directory `/tmp/xenomai/build'
>> configure: error: unrecognized option: -m32
>> Try `/tmp/xenomai/configure --help' for more information.
>> make[1]: *** [config.status] Error 1
>> make[1]: Leaving directory `/tmp/xenomai/build'
>> make: *** [reconfig] Error 2
>>
> 
> make reconfig CC="\"gcc -m32\""
> 

Quoting - I like it...

Ok, one step further. Now I get on "make":

[...]
make[3]: Entering directory `/tmp/xenomai/build/arch/i386/hal'
make: invalid option -- 3
make: invalid option -- 2
Usage: make [options] [target] ...
Options:
  -b, -m                      Ignored for compatibility.
[...]
This program built for x86_64-unknown-linux-gnu
Report bugs to <bug-make@domain.hid>
make[3]: *** [xeno_hal.ko] Error 2
make[3]: Leaving directory `/tmp/xenomai/build/arch/i386/hal'

> (Ok, ok, we'll get rid of autoconf for kernel modules in 2.1...)
> 

Might solve it. But meanwhile, isn't there a chance to do it as the
kernel already does within autoconf/automake?

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [Xenomai-help] compiling xenomai on x86_64

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>Jan Kiszka wrote:
>>
>>
>>>Philippe Gerum wrote:
>>>
>>>
>>>>Heikki Lindholm wrote:
>>>>
>>>>
>>>>
>>>>>Jan Kiszka kirjoitti:
>>>>>
>>>>>
>>>>>
>>>>>>Heikki Lindholm wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Jan Kiszka kirjoitti:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Hi,
>>>>>>>>
>>>>>>>>I'm dumb x86 user who unfortunately just seem to have tumbled in the
>>>>>>>>cross-compilation trap: I'm trying to generate i586 code on a fancy
>>>>>>>>new
>>>>>>>>and fast x86_64 compilation host. I got the kernel compiled with
>>>>>>>>ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
>>>>>>>>cross tool chain), but I failed to compile xenomai against that
>>>>>>>>kernel
>>>>>>>>in the following. Which magic switch do I have to apply and where?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>As dumb a guess: -m32 compiler switch?
>>>>>>>
>>>>>>
>>>>>>
>>>>>>Yes, I know, that would help. But where to feed this argument into the
>>>>>>build system?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>I would try makefile (and perhaps config/kconfig/Makefile*) and
>>>>>command line 'CC="gcc -m32" CXX="gcc -m32" make menuconfig/install' to
>>>>>be sure.
>>>>>
>>>>
>>>>You should be able to do that just by reconfiguring:
>>>>
>>>>cd build && make reconfig CC="gcc -m32"
>>>>
>>>
>>>
>>>... would have been too easy: :-/
>>>
>>>[after "make menuconfig ARCH=i386"]
>>>gcchost2:/tmp/xenomai/build # make reconfig CC="gcc -m32"
>>>make[1]: Entering directory `/tmp/xenomai/build'
>>>configure: error: unrecognized option: -m32
>>>Try `/tmp/xenomai/configure --help' for more information.
>>>make[1]: *** [config.status] Error 1
>>>make[1]: Leaving directory `/tmp/xenomai/build'
>>>make: *** [reconfig] Error 2
>>>
>>
>>make reconfig CC="\"gcc -m32\""
>>
> 
> 
> Quoting - I like it...
> 
> Ok, one step further. Now I get on "make":
> 
> [...]
> make[3]: Entering directory `/tmp/xenomai/build/arch/i386/hal'
> make: invalid option -- 3
> make: invalid option -- 2
> Usage: make [options] [target] ...
> Options:
>   -b, -m                      Ignored for compatibility.
> [...]
> This program built for x86_64-unknown-linux-gnu
> Report bugs to <bug-make@domain.hid>
> make[3]: *** [xeno_hal.ko] Error 2
> make[3]: Leaving directory `/tmp/xenomai/build/arch/i386/hal'
> 
> 
>>(Ok, ok, we'll get rid of autoconf for kernel modules in 2.1...)
>>
> 
> 
> Might solve it. But meanwhile, isn't there a chance to do it as the
> kernel already does within autoconf/automake?
> 

Probably grabbing more stuff from the kernel cflags into XENO_ARCH_FLAGS (e.g. 
-m[0-9]* to start with). Gilles, would this be ok?

-- 

Philippe.

Re: [Xenomai-help] compiling xenomai on x86_64

[Gilles Chanteperdrix]

Philippe Gerum wrote:
 > Probably grabbing more stuff from the kernel cflags into XENO_ARCH_FLAGS (e.g. 
 > -m[0-9]* to start with). Gilles, would this be ok?

Probably, but last time I checked that, the ppc-compiled version of the
dummy program used at configuration time to extract the arch flags from
Kbuild was not work here, because of ahem, quoting issues. There are
some -m arguments we do not want (such as for example the -msoft-float
used in ppc kernel space).

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] compiling xenomai on x86_64

[Heikki Lindholm]

Gilles Chanteperdrix kirjoitti:
> Philippe Gerum wrote:
>  > Probably grabbing more stuff from the kernel cflags into XENO_ARCH_FLAGS (e.g. 
>  > -m[0-9]* to start with). Gilles, would this be ok?
> 
> Probably, but last time I checked that, the ppc-compiled version of the
> dummy program used at configuration time to extract the arch flags from
> Kbuild was not work here, because of ahem, quoting issues. There are
> some -m arguments we do not want (such as for example the -msoft-float
> used in ppc kernel space).

Hmm. Does this also mean that the compiler isn't taken from kernel 
config at all? I tried compiling Xeno on a ppc box the other day, where 
the kernel had already been compiled by gcc-3.4 on another host. The box 
also had gcc-3.4, but 3.3 as the default (old debian.) Xenomai config 
seemed to pick the wrong compiler, because modules complained at load 
time of 3.3 vs. 3.4 conflict. The kernel compile host's default was 
gcc-4.0, so it was also forced to use gcc-3.4.

-- Heikki Lindholm

Re: [Xenomai-help] compiling xenomai on x86_64

[Gilles Chanteperdrix]

Heikki Lindholm wrote:
 > Gilles Chanteperdrix kirjoitti:
 > > Philippe Gerum wrote:
 > >  > Probably grabbing more stuff from the kernel cflags into XENO_ARCH_FLAGS (e.g. 
 > >  > -m[0-9]* to start with). Gilles, would this be ok?
 > > 
 > > Probably, but last time I checked that, the ppc-compiled version of the
 > > dummy program used at configuration time to extract the arch flags from
 > > Kbuild was not work here, because of ahem, quoting issues. There are
 > > some -m arguments we do not want (such as for example the -msoft-float
 > > used in ppc kernel space).
 > 
 > Hmm. Does this also mean that the compiler isn't taken from kernel 
 > config at all? I tried compiling Xeno on a ppc box the other day, where 
 > the kernel had already been compiled by gcc-3.4 on another host. The box 
 > also had gcc-3.4, but 3.3 as the default (old debian.) Xenomai config 
 > seemed to pick the wrong compiler, because modules complained at load 
 > time of 3.3 vs. 3.4 conflict. The kernel compile host's default was 
 > gcc-4.0, so it was also forced to use gcc-3.4.

No, it is only the hack to get the ARCH_FLAGS from kbuild system that
did not work, and now it seems to work. The Xenomai build system takes
the compiler from the CC variable, so as far as I know, the only way you
may get a different compiler when compiling the kernel and compiling
Xenomai is by having it set to a different value.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3078 bytes --]

Philippe Gerum wrote:
> Jan Kiszka wrote:
> 
>> Philippe Gerum wrote:
>>
>>> Jan Kiszka wrote:
>>>
>>>
>>>> Philippe Gerum wrote:
>>>>
>>>>
>>>>> Heikki Lindholm wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Jan Kiszka kirjoitti:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Heikki Lindholm wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Jan Kiszka kirjoitti:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I'm dumb x86 user who unfortunately just seem to have tumbled
>>>>>>>>> in the
>>>>>>>>> cross-compilation trap: I'm trying to generate i586 code on a
>>>>>>>>> fancy
>>>>>>>>> new
>>>>>>>>> and fast x86_64 compilation host. I got the kernel compiled with
>>>>>>>>> ARCH=i386, using only the pre-installed compiler (i.e. no
>>>>>>>>> dedicated
>>>>>>>>> cross tool chain), but I failed to compile xenomai against that
>>>>>>>>> kernel
>>>>>>>>> in the following. Which magic switch do I have to apply and where?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> As dumb a guess: -m32 compiler switch?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Yes, I know, that would help. But where to feed this argument
>>>>>>> into the
>>>>>>> build system?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I would try makefile (and perhaps config/kconfig/Makefile*) and
>>>>>> command line 'CC="gcc -m32" CXX="gcc -m32" make
>>>>>> menuconfig/install' to
>>>>>> be sure.
>>>>>>
>>>>>
>>>>> You should be able to do that just by reconfiguring:
>>>>>
>>>>> cd build && make reconfig CC="gcc -m32"
>>>>>
>>>>
>>>>
>>>> ... would have been too easy: :-/
>>>>
>>>> [after "make menuconfig ARCH=i386"]
>>>> gcchost2:/tmp/xenomai/build # make reconfig CC="gcc -m32"
>>>> make[1]: Entering directory `/tmp/xenomai/build'
>>>> configure: error: unrecognized option: -m32
>>>> Try `/tmp/xenomai/configure --help' for more information.
>>>> make[1]: *** [config.status] Error 1
>>>> make[1]: Leaving directory `/tmp/xenomai/build'
>>>> make: *** [reconfig] Error 2
>>>>
>>>
>>> make reconfig CC="\"gcc -m32\""
>>>
>>
>>
>> Quoting - I like it...
>>
>> Ok, one step further. Now I get on "make":
>>
>> [...]
>> make[3]: Entering directory `/tmp/xenomai/build/arch/i386/hal'
>> make: invalid option -- 3
>> make: invalid option -- 2
>> Usage: make [options] [target] ...
>> Options:
>>   -b, -m                      Ignored for compatibility.
>> [...]
>> This program built for x86_64-unknown-linux-gnu
>> Report bugs to <bug-make@domain.hid>
>> make[3]: *** [xeno_hal.ko] Error 2
>> make[3]: Leaving directory `/tmp/xenomai/build/arch/i386/hal'
>>
>>
>>> (Ok, ok, we'll get rid of autoconf for kernel modules in 2.1...)
>>>
>>
>>
>> Might solve it. But meanwhile, isn't there a chance to do it as the
>> kernel already does within autoconf/automake?
>>
> 
> Probably grabbing more stuff from the kernel cflags into XENO_ARCH_FLAGS
> (e.g. -m[0-9]* to start with). Gilles, would this be ok?
> 

Please see my bug report:

https://gna.org/bugs/index.php?func=detailitem&item_id=4546

The -m32 switch (and others) has a different origin. Have no clue how to
fix this - that's a bit too much black magic for me.

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [Xenomai-help] compiling xenomai on x86_64

[Gilles Chanteperdrix]

Heikki Lindholm wrote:
 > Jan Kiszka kirjoitti:
 > > Heikki Lindholm wrote:
 > > 
 > >>Jan Kiszka kirjoitti:
 > >>
 > >>
 > >>>Hi,
 > >>>
 > >>>I'm dumb x86 user who unfortunately just seem to have tumbled in the
 > >>>cross-compilation trap: I'm trying to generate i586 code on a fancy new
 > >>>and fast x86_64 compilation host. I got the kernel compiled with
 > >>>ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
 > >>>cross tool chain), but I failed to compile xenomai against that kernel
 > >>>in the following. Which magic switch do I have to apply and where?
 > >>
 > >>
 > >>As dumb a guess: -m32 compiler switch?
 > >>
 > > 
 > > 
 > > Yes, I know, that would help. But where to feed this argument into the
 > > build system?
 > 
 > I would try makefile (and perhaps config/kconfig/Makefile*) and command 
 > line 'CC="gcc -m32" CXX="gcc -m32" make menuconfig/install' to be sure.

When using autoconf, you are not supposed to pass compiler flags in
CC, CFLAGS and CXXFLAGS are made for that... and the build system is
supposed to only touch AM_CFLAGS, so that CFLAGS is let for users, but I
am pretty sure this does not work with Xenomai, since we never tried :-)

As for the compilation for pentium on an x86_64, isn't there any
i686-linux-gcc that directly cross compiles for ia32 ?

If not, would not the following wrapper do the trick ?

#! /bin/sh
exec `expr "$0" : 'i686-linux-\(.*\)'` -m32r ${1+"$@"}

It should work with most build systems...


-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1770 bytes --]

Gilles Chanteperdrix wrote:
> Heikki Lindholm wrote:
>  > Jan Kiszka kirjoitti:
>  > > Heikki Lindholm wrote:
>  > > 
>  > >>Jan Kiszka kirjoitti:
>  > >>
>  > >>
>  > >>>Hi,
>  > >>>
>  > >>>I'm dumb x86 user who unfortunately just seem to have tumbled in the
>  > >>>cross-compilation trap: I'm trying to generate i586 code on a fancy new
>  > >>>and fast x86_64 compilation host. I got the kernel compiled with
>  > >>>ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
>  > >>>cross tool chain), but I failed to compile xenomai against that kernel
>  > >>>in the following. Which magic switch do I have to apply and where?
>  > >>
>  > >>
>  > >>As dumb a guess: -m32 compiler switch?
>  > >>
>  > > 
>  > > 
>  > > Yes, I know, that would help. But where to feed this argument into the
>  > > build system?
>  > 
>  > I would try makefile (and perhaps config/kconfig/Makefile*) and command 
>  > line 'CC="gcc -m32" CXX="gcc -m32" make menuconfig/install' to be sure.
> 
> When using autoconf, you are not supposed to pass compiler flags in
> CC, CFLAGS and CXXFLAGS are made for that... and the build system is
> supposed to only touch AM_CFLAGS, so that CFLAGS is let for users, but I
> am pretty sure this does not work with Xenomai, since we never tried :-)

Indeed. Setting CFLAGS on make overwrites a lot of important stuff, and
the compilation fails eagerly.

> 
> As for the compilation for pentium on an x86_64, isn't there any
> i686-linux-gcc that directly cross compiles for ia32 ?
> 
> If not, would not the following wrapper do the trick ?
> 
> #! /bin/sh
> exec `expr "$0" : 'i686-linux-\(.*\)'` -m32r ${1+"$@"}
> 
> It should work with most build systems...
> 

Yes, this seems to work (and fail) just like the "CC=" approach.

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [Xenomai-help] compiling xenomai on x86_64

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > > #! /bin/sh
 > > exec `expr "$0" : 'i686-linux-\(.*\)'` -m32r ${1+"$@"}
 > > 
 > > It should work with most build systems...
 > > 
 > 
 > Yes, this seems to work (and fail) just like the "CC=" approach.

Are you sure your distribution does not provide a cross-compiler ? I
worked once on an x86_64 with Fedora Core installed. And there was an
i386-linux-gcc, but it needed a special package.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > > #! /bin/sh
>  > > exec `expr "$0" : 'i686-linux-\(.*\)'` -m32r ${1+"$@"}
>  > > 
>  > > It should work with most build systems...
>  > > 
>  > 
>  > Yes, this seems to work (and fail) just like the "CC=" approach.
> 
> Are you sure your distribution does not provide a cross-compiler ? I
> worked once on an x86_64 with Fedora Core installed. And there was an
> i386-linux-gcc, but it needed a special package.
> 

Nope: OpenSuSE 10.0. Seems like there are still shortcomings of that
distribution. But I also cannot setup some kind of zoo here... :-/

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]