Re: [Xenomai-help] compiling xenomai on x86_64
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 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. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] compiling xenomai on x86_64
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 signature.asc Description: OpenPGP digital signature
Re: [Xenomai-help] compiling xenomai on x86_64
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 signature.asc Description: OpenPGP digital signature ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] compiling xenomai on x86_64
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 signature.asc Description: OpenPGP digital signature
Re: [Xenomai-help] compiling xenomai on x86_64
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
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" 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 > > /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 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 signature.asc Description: OpenPGP digital signature
Re: [Xenomai-help] compiling xenomai on x86_64
Jan Kiszka wrote: > Gilles Chanteperdrix wrote: > > Jan Kiszka wrote: > > > I just analysed this further: the problem disappears when I manually > > > remove any "-I" 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 > /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 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
Gilles Chanteperdrix wrote: > Jan Kiszka wrote: > > I just analysed this further: the problem disappears when I manually > > remove any "-I" 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 /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 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 /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 signature.asc Description: OpenPGP digital signature
Re: [Xenomai-help] compiling xenomai on x86_64
Jan Kiszka wrote: > I just analysed this further: the problem disappears when I manually > remove any "-I" 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
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
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 <[EMAIL PROTECTED]> >> 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 signature.asc Description: OpenPGP digital signature
Re: [Xenomai-help] compiling xenomai on x86_64
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 signature.asc Description: OpenPGP digital signature ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] compiling xenomai on x86_64
Gilles Chanteperdrix wrote: > Jan Kiszka wrote: > > I just analysed this further: the problem disappears when I manually > > remove any "-I" 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 /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 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 /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 signature.asc Description: OpenPGP digital signature ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] compiling xenomai on x86_64
Jan Kiszka wrote: > I just analysed this further: the problem disappears when I manually > remove any "-I" 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. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] 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. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] compiling xenomai on x86_64
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
signature.asc
Description: OpenPGP digital signature
Re: [Xenomai-help] 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" 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 signature.asc Description: OpenPGP digital signature
Re: [Xenomai-help] compiling xenomai on x86_64
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 wrote: > Jan Kiszka wrote: > I just analysed this further: the problem disappears when I manually > remove any "-I" 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
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
signature.asc
Description: OpenPGP digital signature
Re: [Xenomai-help] 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, > 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" from the makefiles. Seems to be the well-known user space include issue again... ;) Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-help] 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: [Xenomai-help] 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, > > 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 >> 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 signature.asc Description: OpenPGP digital signature ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] compiling xenomai on x86_64
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
signature.asc
Description: OpenPGP digital signature
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] compiling xenomai on x86_64
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 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
Gilles Chanteperdrix wrote: > Jan Kiszka wrote: > > Jan Kiszka wrote: > > I just analysed this further: the problem disappears when I manually > > remove any "-I" 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 signature.asc Description: OpenPGP digital signature ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] compiling xenomai on x86_64
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.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] 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" 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. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] 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
> 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
signature.asc
Description: OpenPGP digital signature
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] 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, > 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" from the makefiles. Seems to be the well-known user space include issue again... ;) Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] compiling xenomai on x86_64
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 signature.asc Description: OpenPGP digital signature
Re: [Xenomai-help] compiling xenomai on x86_64
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 <[EMAIL PROTECTED]> 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 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 ___ Xenomai-help mailing list [EMAIL PROTECTED] https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] compiling xenomai on x86_64
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 <[EMAIL PROTECTED]> 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 signature.asc Description: OpenPGP digital signature
Re: [Xenomai-help] compiling xenomai on x86_64
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 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 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 signature.asc Description: OpenPGP digital signature
Re: [Xenomai-help] compiling xenomai on x86_64
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@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe.
Re: [Xenomai-help] compiling xenomai on x86_64
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
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 signature.asc Description: OpenPGP digital signature
Re: [Xenomai-help] compiling xenomai on x86_64
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
