Re: compiling xenomai on x86_64

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: compiling xenomai on x86_64

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,

Re: compiling xenomai on x86_64

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

Re: compiling xenomai on x86_64

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: compiling xenomai on x86_64

Jan Kiszka wrote:
 > > #! /bin/sh
 > > exec `expr "$0" : 'i686-linux-\(.*\)'` -m32r ${1+"$ <at> "}
 > > 
 > > 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: compiling xenomai on x86_64

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

_______________________________________________
Xenomai-help mailing list
Xenomai-help <at> gna.org
https://mail.gna.org/listinfo/xenomai-help

Re: compiling xenomai on x86_64

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > > #! /bin/sh
>  > > exec `expr "$0" : 'i686-linux-\(.*\)'` -m32r ${1+"$ <at> "}
>  > > 
>  > > 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

_______________________________________________
Xenomai-help mailing list
Xenomai-help <at> gna.org
https://mail.gna.org/listinfo/xenomai-help

Re: compiling xenomai on x86_64

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,
>>>>>>>>>

Re: compiling xenomai on x86_64

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: compiling xenomai on x86_64

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.