Fwd: Compiling pgm for an older linux version - cross compiler

Fwd: Compiling pgm for an older linux version - cross compiler

[Jacques Greindl]

Hi !

This is probably a newby question but I can't find the anwser ...

I have 2 files : a.new & a.old
a.new : compiled today
a.old : compiled some years ago, on another system

jack@cixci:/$ file a.new
a.new: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not
stripped
jack@cixci:/$ file a.old
a.old: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.0.0, not
stripped

Is there a way to build again the same "a.old" --> on my actual
system, build the program for the old system ?

Thanks for your help,

Jack

Re: Fwd: Compiling pgm for an older linux version - cross compiler

[Ian Lance Taylor]

Jacques Greindl <jgreindl@gmail.com> writes:

> This is probably a newby question but I can't find the anwser ...
>
> I have 2 files : a.new & a.old
> a.new : compiled today
> a.old : compiled some years ago, on another system
>
> jack@cixci:/$ file a.new
> a.new: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not
> stripped
> jack@cixci:/$ file a.old
> a.old: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.0.0, not
> stripped
>
> Is there a way to build again the same "a.old" --> on my actual
> system, build the program for the old system ?

It is possible in principle by essentially setting up a little version
of the old system, with the old compiler, binutils, and glibc, all
properly configured and built to work together.  It's a fair bit of
work, though.  There is no simple way to do it.  This of course assumes
that you have the original source code.

At least, that is what it would take to build the exact same a.old, with
the same resulting bytes.  If you have a looser meaning of "same" than
perhaps a simpler procedure would be possible.

Ian

Re: Fwd: Compiling pgm for an older linux version - cross compiler

[Jacques Greindl]

Thanks for your help.

The same "number" of byte is not necessary.
What I need is to be sure that my program will run on the older system.
And yes, I have the source files.

If necessary, where can I find all those old utils (compiler, binutils
...). I ve looked on the web, but don't know precisly what to take
(version...)

On Thu, Jan 20, 2011 at 7:32 PM, Ian Lance Taylor <iant@google.com> wrote:
> Jacques Greindl <jgreindl@gmail.com> writes:
>
>> This is probably a newby question but I can't find the anwser ...
>>
>> I have 2 files : a.new & a.old
>> a.new : compiled today
>> a.old : compiled some years ago, on another system
>>
>> jack@cixci:/$ file a.new
>> a.new: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
>> dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not
>> stripped
>> jack@cixci:/$ file a.old
>> a.old: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
>> dynamically linked (uses shared libs), for GNU/Linux 2.0.0, not
>> stripped
>>
>> Is there a way to build again the same "a.old" --> on my actual
>> system, build the program for the old system ?
>
> It is possible in principle by essentially setting up a little version
> of the old system, with the old compiler, binutils, and glibc, all
> properly configured and built to work together.  It's a fair bit of
> work, though.  There is no simple way to do it.  This of course assumes
> that you have the original source code.
>
> At least, that is what it would take to build the exact same a.old, with
> the same resulting bytes.  If you have a looser meaning of "same" than
> perhaps a simpler procedure would be possible.
>
> Ian
>

Re: Fwd: Compiling pgm for an older linux version - cross compiler

[Ian Lance Taylor]

Jacques Greindl <jgreindl@gmail.com> writes:

> What I need is to be sure that my program will run on the older system.
> And yes, I have the source files.

The best way to do that is to build your program on the older system.

If that is not possible, the key thing you need is to compile and link
using the version of glibc which runs on the older system.

Ian

Re: Fwd: Compiling pgm for an older linux version - cross compiler

[Jacques Greindl]

The older system is an embedded one --> no compiler on it (run on 2mb
flash mem).
I build this one a few years ago with an old linux desktop. And I
don't have it anymore. But I have to make an upgrade for the embedded
system...

So I have to :
1- find the glibc version of my embedded system
2- install this version on my actual system without erasing my actual one (how?)
3- compile my sources with gcc and a parameter to specify this version (how?)

Once again, many thanks for your help.
Jack

On Thu, Jan 20, 2011 at 10:47 PM, Ian Lance Taylor <iant@google.com> wrote:
> Jacques Greindl <jgreindl@gmail.com> writes:
>
>> What I need is to be sure that my program will run on the older system.
>> And yes, I have the source files.
>
> The best way to do that is to build your program on the older system.
>
> If that is not possible, the key thing you need is to compile and link
> using the version of glibc which runs on the older system.
>
> Ian
>

Re: Fwd: Compiling pgm for an older linux version - cross compiler

[Kai Ruottu]

21.1.2011 14:15, Jacques Greindl kirjoitti:

> The older system is an embedded one -->  no compiler on it (run on 2mb
> flash mem).
> I build this one a few years ago with an old linux desktop. And I
> don't have it anymore. But I have to make an upgrade for the embedded
> system...
>
> So I have to :
> 1- find the glibc version of my embedded system

Running '/lib/libc.so.6' on it should tell if there are any shared libs
and if, how the main one was produced...

> 2- install this version on my actual system without erasing my actual one (how?)

Copying the complete glibc set onto the "cross" development host...

> 3- compile my sources with gcc and a parameter to specify this version (how?)

With a self-made cross GCC or with the native GCC from that 'old linux
desktop', my guess would be Red Hat 6.2 by your earlier message... The
GCC (egcs-1.1.2) binaries from RHL6.2 should work still on the uptodate 
Linuces...

But you had better to reveal more details, CPU arch etc., the Linux/x86
was mu guess...

Re: Fwd: Compiling pgm for an older linux version - cross compiler

[Ian Lance Taylor]

Jacques Greindl <jgreindl@gmail.com> writes:

> The older system is an embedded one --> no compiler on it (run on 2mb
> flash mem).
> I build this one a few years ago with an old linux desktop. And I
> don't have it anymore. But I have to make an upgrade for the embedded
> system...

You could recreate the old GNU/Linux system.  Old GNU/Linux distros are
easy to find on the web.


> So I have to :
> 1- find the glibc version of my embedded system
> 2- install this version on my actual system without erasing my actual one (how?)
> 3- compile my sources with gcc and a parameter to specify this version (how?)

Building glibc is nontrivial.  But the basic idea is to build and
install glibc with a specific --prefix option, and use that directory as
a --with-sysroot option when building GNU binutils and gcc.

Ian

Re: Fwd: Compiling pgm for an older linux version - cross compiler

[Jacques Greindl]

Here are the details of the lib of the embedded system :

ls -ls /lib :

-rwxr-xr-x    1 root     root        94543 Apr 25  2007 ld-2.2.4.so

lrwxrwxrwx    1 root     root           11 Nov  9  2007 ld-linux.so.2
-> ld-2.2.4.so

-rwxr-xr-x    1 root     root      1384168 Apr 25  2007 libc-2.2.4.so

lrwxrwxrwx    1 root     root           13 Nov  9  2007 libc.so.6 ->
libc-2.2.4.so

-rwxr-xr-x    1 root     root        22388 Apr 25  2007 libcrypt-2.2.so

lrwxrwxrwx    1 root     root           15 Nov  9  2007 libcrypt.so.1
-> libcrypt-2.2.so

-rwxr-xr-x    1 root     root        14653 Apr 25  2007 libdl.so.2

-rwxr-xr-x    1 root     root       187118 Apr 25  2007 libm.so.6

lrwxrwxrwx    1 root     root           28 Jan  1 00:00 libnsl.so.1 ->
/mnt/AgentServer/libnsl.so.1

-rwxr-xr-x    1 root     root        37248 Apr 25  2007 libnss_files-2.2.so

lrwxrwxrwx    1 root     root           19 Nov  9  2007
libnss_files.so.2 -> libnss_files-2.2.so

-rwxr-xr-x    1 root     root       106843 Apr 25  2007 libpthread.so.0

lrwxrwxrwx    1 root     root           31 Jan  1 00:00 libresolv.so.2
-> /mnt/AgentServer/libresolv.so.2

-rwxr-xr-x    1 root     root        36672 Apr 25  2007 librt.so.1

-rw-r--r--    1 root     root       619093 Apr 25  2007 libtcl8.3.so

-rwxr-xr-x    1 root     root         8476 Apr 25  2007 libutil-2.2.so

lrwxrwxrwx    1 root     root           14 Nov  9  2007 libutil.so.1
-> libutil-2.2.so

drwxr-xr-x    2 root     root          416 Nov 23  2004 modules


I can copy all these libs on my computer, but then how to specify to
gcc to use this directory for shared lib instead of /lib ?
And will this solve my problem ? (which is: rebuild an program on a
new linux so that it will run on the embedded system,where there is no
compiler)

On Fri, Jan 21, 2011 at 4:33 PM, Ian Lance Taylor <iant@google.com> wrote:
> Jacques Greindl <jgreindl@gmail.com> writes:
>
>> The older system is an embedded one --> no compiler on it (run on 2mb
>> flash mem).
>> I build this one a few years ago with an old linux desktop. And I
>> don't have it anymore. But I have to make an upgrade for the embedded
>> system...
>
> You could recreate the old GNU/Linux system.  Old GNU/Linux distros are
> easy to find on the web.
>
>
>> So I have to :
>> 1- find the glibc version of my embedded system
>> 2- install this version on my actual system without erasing my actual one (how?)
>> 3- compile my sources with gcc and a parameter to specify this version (how?)
>
> Building glibc is nontrivial.  But the basic idea is to build and
> install glibc with a specific --prefix option, and use that directory as
> a --with-sysroot option when building GNU binutils and gcc.
>
> Ian
>

Re: Fwd: Compiling pgm for an older linux version - cross compiler

[Kai Ruottu]

22.1.2011 11:15, Jacques Greindl kirjoitti:

> Here are the details of the lib of the embedded system :
>
> ls -ls /lib :
>
> -rwxr-xr-x    1 root     root        94543 Apr 25  2007 ld-2.2.4.so
>
> lrwxrwxrwx    1 root     root           11 Nov  9  2007 ld-linux.so.2
> ->  ld-2.2.4.so
>
> -rwxr-xr-x    1 root     root      1384168 Apr 25  2007 libc-2.2.4.so
>
> lrwxrwxrwx    1 root     root           13 Nov  9  2007 libc.so.6 ->
> libc-2.2.4.so

This could be a RHL7.1 or RHL7.2 distro with updates, RHL7.3 without
updates, Debian Woody (3.0r5) or anything else...

> I can copy all these libs on my computer, but then how to specify to
> gcc to use this directory for shared lib instead of /lib ?

For RHL distros there were those 'compat-rhl7.1' etc. RPMS. Installing
one of them via 'rpm' or preferably first unpacking with something like:

    rpm2cpio <the-RPM> | cpio -idmuvB

into some temporary place and seeing what one got before copying the
toolchain into its final place, would be the most easy route. Maybe
the current package handlers allow one to only unpack something but
if not, then knowing how to unpack '.rpm's and '.deb's manually is a
recommended know-how...

Generally downloading old RPMS or Debian packages for some old distro
and unpacking them for investigation before deciding what to do with
the stuff, shouldn't be any rocket science.

> And will this solve my problem ? (which is: rebuild an program on a
> new linux so that it will run on the embedded system,where there is no
> compiler)

If you cannot tell the distro on the embedded board or the distro on
which the earlier program was built and then it ran ok on the possibly
different distro, then it is quite hard to help you :(

For instance I myself have both the RHL7.1 and RHL7.3 install CDs and
one can easily find them on the net. I have also the Debian 3.0r5 CDs
but couldn't easily find any Debian 3.0r5 stuff like its glibc-2.2.4
and gcc-2.95.4 on the net.

Anyhow for curiosity I unpacked the Debian 3.0r5 gcc-2.95.4 and 
glibc-2.2.5 updates onto my CentOS 5.5 (no binutils) and tried
the toolchain with a simple program :

[root@localhost tprintf]# gcc-debian3.0r5 -v -Os -o tst_debian3.0r5 
tprintf.c
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
  /usr/lib/gcc-lib/i386-linux/2.95.4/cpp0 -lang-c -v -D__GNUC__=2 
-D__GNUC_MINOR__=95 -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__ 
-D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix) 
-D__OPTIMIZE_SIZE__ -D__OPTIMIZE__ -Acpu(i386) -Amachine(i386) -Di386 
-D__i386 -D__i386__ tprintf.c /tmp/ccgcHRUF.i
GNU CPP version 2.95.4 20011002 (Debian prerelease) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
  /usr/local/include
  /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../i386-linux/include
  /usr/lib/gcc-lib/i386-linux/2.95.4/include
  /usr/include
End of search list.
The following default directories have been omitted from the search path:
  /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3
End of omitted list.
  /usr/lib/gcc-lib/i386-linux/2.95.4/cc1 /tmp/ccgcHRUF.i -quiet 
-dumpbase tprintf.c -Os -version -o /tmp/cc23BDBn.s
GNU C version 2.95.4 20011002 (Debian prerelease) (i386-linux) compiled 
by GNU C version 2.95.4 20011002 (Debian prerelease).
  as -V -Qy -o /tmp/cci3Ypck.o /tmp/cc23BDBn.s
GNU assembler version 2.17.50.0.6-14.el5 (i386-redhat-linux) using BFD 
version 2.17.50.0.6-14.el5 20061020
  /usr/lib/gcc-lib/i386-linux/2.95.4/collect2 -m elf_i386 
-dynamic-linker /lib/ld-linux.so.2 -o tst_debian3.0r5 
/usr/i386-linux/lib/crt1.o /usr/i386-linux/lib/crti.o 
/usr/lib/gcc-lib/i386-linux/2.95.4/crtbegin.o 
-L/usr/lib/gcc-lib/i386-linux/2.95.4 -L/usr/i386-linux/lib 
-L/lib/i386-linux/2.95.4 /tmp/cci3Ypck.o -lgcc -lc -lgcc 
/usr/lib/gcc-lib/i386-linux/2.95.4/crtend.o /usr/i386-linux/lib/crtn.o

As can be seen, even a native GCC searches its target stuff from other
places first, the target headers from :

  /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../i386-linux/include
aka
  /usr/i386-linux/include

and the libs from :

  /usr/i386-linux/lib

before searching the system ones, '/usr/include', '/usr/lib' and '/lib'.

In any case there are those '-nostdinc' and '-nostdlib' and '-I' / '-L'
etc. options for GCC if the native GCC also uses the same (here
'i386-linux') target name... Where a GCC will search as default can be
seen with the (should be) well-known '-print-search-dirs' option and
this option can be seen with the option '--help' which everyone should
at least know...

Getting the original '/lib' and '/usr/lib' stuff being seen in a single
'lib' maybe needs some advice, who knows... Anyhow, I unpacked all the
Debian 3.0r5 stuff into its own $sysroot :

  /opt/host-Debian3.0r5_i386/lib
  /opt/host-Debian3.0r5_i386/usr/include
  /opt/host-Debian3.0r5_i386/usr/lib
  etc

and then made the necessary symlinks so that the 2nd and 3rd '/usr'
directory were seen in the searched '/usr/i386-linux'. Furthermore
I fixed the existing symlinks in the original '/usr/lib', pointing
to '/lib' to point to '../../lib' (a normal glibc install should
use these relative links!) and added some new like for 'libc.so.6'
and 'ld-linux.so.2' and edited the 'libc.so' script to not have any
absolute pathnames for 'libc.so.6' and 'libc_nonshared.a'...

The original target binutils weren't unpacked (and then symlinked
to '/usr/i386-linux/bin'), but the system's own 'as' and 'ld' were
used with the old 'gcc', 'cc1' and 'collect2'... Quite often those
in some distro have used shared bfd and opcodes libs like in CentOS :

[root@localhost bin]# ldd as
         linux-gate.so.1 =>  (0x00637000)
         libbfd-2.17.50.0.6-14.el5.so => 
/usr/lib/libbfd-2.17.50.0.6-14.el5.so (0x0031d000)
         libc.so.6 => /lib/libc.so.6 (0x00101000)
         /lib/ld-linux.so.2 (0x00ccf000)

My self-made binutils have never required shared 'libbfd' or
'libopcodes', therefore this "feature" in the distro ones has
always been surprising... Problems expected with old binutils
from some distro :(

>> You could recreate the old GNU/Linux system.  Old GNU/Linux distros are
>> easy to find on the web.

The Debian ones didn't seem to be there :(  Ok, I didn't try googling,
only looked the main Debian archive and its mirrors in Finland and
Sweden.

>>> So I have to :
>>> 1- find the glibc version of my embedded system
>>> 2- install this version on my actual system without erasing my actual one (how?)
>>> 3- compile my sources with gcc and a parameter to specify this version (how?)

The previous should give the answers. If you can tell the distro you
have (for instance via running '/libc/so.6' on the target system),
then it would be much easier to discuss about issues related to that
distro, where to find its GCC and glibc etc. RPMS or '.deb's...

>> Building glibc is nontrivial.  But the basic idea is to build and
>> install glibc with a specific --prefix option, and use that directory as
>> a --with-sysroot option when building GNU binutils and gcc.

Neither I would recommend this. Relying on backwards compatibility
with the binutils, GCC etc. executables would be much easier, just
unpack them and see if they will run ok on the uptodate Linux system.

Re: Fwd: Compiling pgm for an older linux version - cross compiler

[Kai Ruottu]

27.1.2011 13:17, Kai Ruottu kirjoitti:

> Getting the original '/lib' and '/usr/lib' stuff being seen in a single
> 'lib' maybe needs some advice, who knows... Anyhow, I unpacked all the
> Debian 3.0r5 stuff into its own $sysroot :
>
> /opt/host-Debian3.0r5_i386/lib
> /opt/host-Debian3.0r5_i386/usr/include
> /opt/host-Debian3.0r5_i386/usr/lib
> etc
>
> and then made the necessary symlinks so that the 2nd and 3rd '/usr'
> directory were seen in the searched '/usr/i386-linux'.

Some people prefer a "chroot jail", using 'chroot' for the alien
stuff place, here '/opt/host-Debian3.0r5_i386', after that the
used tools will use the changed root place... The current MeeGo
project suggested this for running the 'i586-meego-linux' distro
packages on Ubuntus, Fedoras and SuSEs...

With crosscompilers the symlinking approach became familiar
before people invented the '--with-sysroot='. Somehow the two
Linux 'lib' dirs had to be seen in the one '$prefix/$target/lib'.
Putting the target stuff somewhere in its native scheme and then
symlinking things from it where required, wasn't that hard to
invent...

Re: Fwd: Compiling pgm for an older linux version - cross compiler

[Kai Ruottu]

27.1.2011 13:17, Kai Ruottu kirjoitti:

>>> You could recreate the old GNU/Linux system. Old GNU/Linux distros are
>>> easy to find on the web.
>
> The Debian ones didn't seem to be there :( Ok, I didn't try googling,
> only looked the main Debian archive and its mirrors in Finland and
> Sweden.

With some suitable search words it wasn't hard to find the required
stuff, like :

http://archive.debian.org/debian/pool/main/g/gcc-2.95/

Maybe there is some pessimism in these things, all the time many
people expects others to be walking and talking encyclopedias and
cannot use net like an encyclopedia with search words :(

Re: Fwd: Compiling pgm for an older linux version - cross compiler

[Jacques Greindl]

I solved my problem with your advices :
1- download old redhat (8.0)
2- Install it in a virtual machine (with virtual box)
3- compiling -> it worked.

On Fri, Jan 28, 2011 at 4:46 PM, Jacques Greindl <jgreindl@gmail.com> wrote:
>
> Thanks all for your help
>
> I solved my problem with your advices :
> 1- download old redhat (8.0)
> 2- Install it in a virtual machine (with virtual box)
> 3- compiling -> it worked.
>
>
> On Thu, Jan 27, 2011 at 1:04 PM, Kai Ruottu <kai.ruottu@wippies.com> wrote:
>>
>> 27.1.2011 13:17, Kai Ruottu kirjoitti:
>>
>>>>> You could recreate the old GNU/Linux system. Old GNU/Linux distros are
>>>>> easy to find on the web.
>>>
>>> The Debian ones didn't seem to be there :( Ok, I didn't try googling,
>>> only looked the main Debian archive and its mirrors in Finland and
>>> Sweden.
>>
>> With some suitable search words it wasn't hard to find the required
>> stuff, like :
>>
>> http://archive.debian.org/debian/pool/main/g/gcc-2.95/
>>
>> Maybe there is some pessimism in these things, all the time many
>> people expects others to be walking and talking encyclopedias and
>> cannot use net like an encyclopedia with search words :(
>