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
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
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
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
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
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
rep
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 aga
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 ever
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
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 iss
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-co
Philippe Gerum wrote:
> Jan Kiszka wrote:
>
>> Philippe Gerum wrote:
>>
>>> Jan Kiszka wrote:
>>>
>>>
Philippe Gerum wrote:
> Heikki Lindholm wrote:
>
>
>
>> Jan Kiszka kirjoitti:
>>
>>
>>
>>> Heikki Lindholm 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
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
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 iss
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-co
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 distrib
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 s
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
work
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-p
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 tr
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
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 configurat
Philippe Gerum wrote:
> Jan Kiszka wrote:
>
>> Philippe Gerum wrote:
>>
>>> Jan Kiszka wrote:
>>>
>>>
Philippe Gerum wrote:
> Heikki Lindholm wrote:
>
>
>
>> Jan Kiszka kirjoitti:
>>
>>
>>
>>> Heikki Lindholm wrote:
>>>
>>>
>>>
>>>
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 distrib
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 fl
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
> >>>an
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 s
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
work
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-p
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 tr
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
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,
>>>
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
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 configurat
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
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 co
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 fa
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
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 com
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, usi
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
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 dedica
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), b
44 matches
Mail list logo
