Changing the destination Linux Kernel version

Changing the destination Linux Kernel version

[Clément VERMOT-DESROCHES]

Hi everybody,

I'm currently trying to create a cross toolchain using crosstool-ng.
I have 3 machines :
-my build machine : i386 with Linux Kernel 3.5.0
-my host machine : i386 with Linux Kernel 2.6.18
-my target machine : ARM with Linux Kernel 3.6.11

I manage to generate a valid toolchain. I compile with success a
binary for the target from my build machine. But I have to use the
host machine to produce my target binary. If I try to compile on my
host machine with the toolchain produced on my build machine, I get
the message :
"FATAL : kernel too old
segmentation fault"

If I do a "file linux-gnueabi-gcc", I get "ELF 32-bit LSB executable,
Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.24, statically
linked, for GNU/Linux 2.6.24, stripped", so, it's explain the kernel
too old error.

So, my question is : how can I produce a 2.6.18 (or less) compliant
toolchain from my build machine ? I have checked and tryed a lot of
parameters but I didn't manage to get a binary which run happily on my
host machine.
I can not run crosstool-ng on my host machine because I haven't the
right to update tools and the installed versions are too old to
successfully using crosstool-ng on this computer.

Thank you,
Best regards,
Clément VERMOT

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Changing the destination Linux Kernel version

[Johannes Stezenbach]

On Mon, Mar 11, 2013 at 03:17:12PM +0100, Clément VERMOT-DESROCHES wrote:
> I'm currently trying to create a cross toolchain using crosstool-ng.
> I have 3 machines :
> -my build machine : i386 with Linux Kernel 3.5.0
> -my host machine : i386 with Linux Kernel 2.6.18
> -my target machine : ARM with Linux Kernel 3.6.11
> 
> I manage to generate a valid toolchain. I compile with success a
> binary for the target from my build machine. But I have to use the
> host machine to produce my target binary. If I try to compile on my
> host machine with the toolchain produced on my build machine, I get
> the message :
> "FATAL : kernel too old
> segmentation fault"
> 
> If I do a "file linux-gnueabi-gcc", I get "ELF 32-bit LSB executable,
> Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.24, statically
> linked, for GNU/Linux 2.6.24, stripped", so, it's explain the kernel
> too old error.
> 
> So, my question is : how can I produce a 2.6.18 (or less) compliant
> toolchain from my build machine ? I have checked and tryed a lot of
> parameters but I didn't manage to get a binary which run happily on my
> host machine.

The "for GNU/Linux 2.6.24" is determined by the glibc of your
build machine, you cannot change it by any compile
or link options.

> I can not run crosstool-ng on my host machine because I haven't the
> right to update tools and the installed versions are too old to
> successfully using crosstool-ng on this computer.

You can build and install updated tools in a local environment
(e.g. in your home directory) on your host machine and then build
the toolchain on the host.

The only other choice would be to build a toolchain on
your build machine with a glibc with lower minimum kernel
version (CT_LIBC_GLIBC_MIN_KERNEL in ct-ng or --enable-kernel=<version>
in glibc configure), and then use that to compile the cross toolchain.


HTH
Johannes

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Changing the destination Linux Kernel version

[Clément VERMOT-DESROCHES]

Hi, thank you for your response,

On Wed, Mar 13, 2013 at 8:49 PM, Johannes Stezenbach <js@sig21.net> wrote:
>
> The "for GNU/Linux 2.6.24" is determined by the glibc of your
> build machine, you cannot change it by any compile
> or link options.
>
Ok for this point.


> You can build and install updated tools in a local environment
> (e.g. in your home directory) on your host machine and then build
> the toolchain on the host.
>
I have tryied this, but, local tools are as old as the kernel. So, I
need to update a lot of tools and there is many dependencies. E.g., I
need to update automake, but my version of autotools is too old to
build a newer version of automake, so, I need to update autotools too,
which have many others dependencies.

> The only other choice would be to build a toolchain on
> your build machine with a glibc with lower minimum kernel
> version (CT_LIBC_GLIBC_MIN_KERNEL in ct-ng or --enable-kernel=<version>
> in glibc configure), and then use that to compile the cross toolchain.
>
If I do that, I will have to use a very old version of glibc. I think
the old version will come with many other problems (bugs and maybe
leak of some functionalities).

I will try to update the kernel on my host machine...

Clément

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Changing the destination Linux Kernel version

[Yann E. MORIN]

Clément, All,

On Sunday 24 March 2013 Clément VERMOT-DESROCHES wrote:
> On Wed, Mar 13, 2013 at 8:49 PM, Johannes Stezenbach <js@sig21.net> wrote:
> >
> > The "for GNU/Linux 2.6.24" is determined by the glibc of your
> > build machine, you cannot change it by any compile
> > or link options.
> >
> Ok for this point.

You have to tell at build-time (the toolchain build-time) what your oldest
running kernel will be:
    C-library  -->
        Minimum supported kernel version  -->
            (Specific kernel version)
        (2.6.9) Minimum kernel version to support

Change '2.6.9' with the oldest kernel you'll be running on the target.

> > You can build and install updated tools in a local environment
> > (e.g. in your home directory) on your host machine and then build
> > the toolchain on the host.
> >
> I have tryied this, but, local tools are as old as the kernel. So, I
> need to update a lot of tools and there is many dependencies. E.g., I
> need to update automake, but my version of autotools is too old to
> build a newer version of automake, so, I need to update autotools too,
> which have many others dependencies.

Crosstool-NG can build some of these tools for you:
    Paths and misc options  --->
        [*] Try features marked as EXPERIMENTAL
    Companion tools  --->
        [*] Build some companion tools
        (Then select the ones you need)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Changing the destination Linux Kernel version

[Johannes Stezenbach]

Hi Yann and Clément,

On Sun, Mar 24, 2013 at 06:09:10PM +0100, Yann E. MORIN wrote:
> On Sunday 24 March 2013 Clément VERMOT-DESROCHES wrote:
> > On Wed, Mar 13, 2013 at 8:49 PM, Johannes Stezenbach <js@sig21.net> wrote:
> > >
> > > The "for GNU/Linux 2.6.24" is determined by the glibc of your
> > > build machine, you cannot change it by any compile
> > > or link options.
> > >
> > Ok for this point.
> 
> You have to tell at build-time (the toolchain build-time) what your oldest
> running kernel will be:
>     C-library  -->
>         Minimum supported kernel version  -->
>             (Specific kernel version)
>         (2.6.9) Minimum kernel version to support
> 
> Change '2.6.9' with the oldest kernel you'll be running on the target.

We're talking about about the "host" (where the toolchain should
run) not about the target, and not about the "build" machine
(where the toolchain is built).

I also had to build a toolchain to run on old RHEL release.
Sorry I can't post my build script (but it is very specific
the the environment anyway), but I needed to build
bash, xz, tar, flex, bison, gperf, texinfo, zlib, binutils and gcc-4.1.2
before I could run install and run ct-ng. (gcc-4.1.2 is sufficient
to build cross gcc-4.7, and can be built using the old gcc in the old RHEL).
However, I used the RHEL glibc, so all the tools can be installed
using simple unpack/configure/make/make install.


HTH
Johannes

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Changing the destination Linux Kernel version

[Yann E. MORIN]

Johannes, Clément, All,

On Monday 25 March 2013 Johannes Stezenbach wrote:
> On Sun, Mar 24, 2013 at 06:09:10PM +0100, Yann E. MORIN wrote:
> > On Sunday 24 March 2013 Clément VERMOT-DESROCHES wrote:
> > > On Wed, Mar 13, 2013 at 8:49 PM, Johannes Stezenbach <js@sig21.net> wrote:
> > > >
> > > > The "for GNU/Linux 2.6.24" is determined by the glibc of your
> > > > build machine, you cannot change it by any compile
> > > > or link options.
> > > >
> > > Ok for this point.
> > 
> > You have to tell at build-time (the toolchain build-time) what your oldest
> > running kernel will be:
> >     C-library  -->
> >         Minimum supported kernel version  -->
> >             (Specific kernel version)
> >         (2.6.9) Minimum kernel version to support
> > 
> > Change '2.6.9' with the oldest kernel you'll be running on the target.
> 
> We're talking about about the "host" (where the toolchain should
> run) not about the target, and not about the "build" machine
> (where the toolchain is built).

Ah, OK.

If I were to build such a toolchain, I would build a canadian-cross.
Here's how I-d do it:

 0) Install a recent distro (on a physical nachine, or in a VM);
 1) Build  a cross-compiler that targets your old machine, using the
    "minimum kernel version" trick I demomnstrated in my previous mail;
 2) Build a static canadian-cross whose host would be the old machine,
    and would be built using the cross-compiler just above;
 3) Deploy that canadian cros to the old machine.

So, as it is statically-linked, and the glibc that was used to build it has
support for an old kernel, the toolchain would run on your old machine.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Changing the destination Linux Kernel version

[Clément VERMOT-DESROCHES]

Thank you all for advices,

I will check if it's work. Finally, I managed to get root privileges
on my old machine, so I have updated the kernel of my old machine from
2.6.18 to 2.6.24. But it will be great if I manage to avoid updating
kernel, so I will try it (I have to do some documentation about the
cross compiler generating process, and it should be as easy as
possible, but update the kernel significantly increase the time and
complexity of the procedure).

I will keep you informed.
Clément

On Mon, Mar 25, 2013 at 5:04 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Johannes, Clément, All,
>
> On Monday 25 March 2013 Johannes Stezenbach wrote:
>> On Sun, Mar 24, 2013 at 06:09:10PM +0100, Yann E. MORIN wrote:
>> > On Sunday 24 March 2013 Clément VERMOT-DESROCHES wrote:
>> > > On Wed, Mar 13, 2013 at 8:49 PM, Johannes Stezenbach <js@sig21.net> wrote:
>> > > >
>> > > > The "for GNU/Linux 2.6.24" is determined by the glibc of your
>> > > > build machine, you cannot change it by any compile
>> > > > or link options.
>> > > >
>> > > Ok for this point.
>> >
>> > You have to tell at build-time (the toolchain build-time) what your oldest
>> > running kernel will be:
>> >     C-library  -->
>> >         Minimum supported kernel version  -->
>> >             (Specific kernel version)
>> >         (2.6.9) Minimum kernel version to support
>> >
>> > Change '2.6.9' with the oldest kernel you'll be running on the target.
>>
>> We're talking about about the "host" (where the toolchain should
>> run) not about the target, and not about the "build" machine
>> (where the toolchain is built).
>
> Ah, OK.
>
> If I were to build such a toolchain, I would build a canadian-cross.
> Here's how I-d do it:
>
>  0) Install a recent distro (on a physical nachine, or in a VM);
>  1) Build  a cross-compiler that targets your old machine, using the
>     "minimum kernel version" trick I demomnstrated in my previous mail;
>  2) Build a static canadian-cross whose host would be the old machine,
>     and would be built using the cross-compiler just above;
>  3) Deploy that canadian cros to the old machine.
>
> So, as it is statically-linked, and the glibc that was used to build it has
> support for an old kernel, the toolchain would run on your old machine.
>
> Regards,
> Yann E. MORIN.
>
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq