Very Computer

Hi All,

I'm looking for some help compiling some software to run under an older
kernel than the one running on my system. I've Googled and Google Grouped
this subject, but most of the articles/posts are about kernel compiling,
rather than compiling software. Although I have a specific use for this
procedure in mind, I am curious as to how this is done in general.

Specs:
Host system: Core Linux (http://coredistro.sourceforge.net) running kernel
2.4.19, gcc 3.0.3, make 3.79.1 - Celeron 700, 512Mb RAM etc.
Target system: Freesco (http://www.freesco.org) 0.2.7 router running kernel
2.0.38 (I'm told), gcc and make not included - P60, 32Mb RAM etc

My specific use is: I want to compile thttpd-2.20c
http://www.acme.com/software/thttpd/ for a Freesco 0.2.7 router system. I
have compiled, made, installed and tested my tweaked thttpd-2.20c server
under kernel 2.4.19 successfully. But when I try to run the version compiled
under 2.4.19 on my Freesco box it returns the error: thttpd: No such file or
directory. The Freesco forum suggested that this could be due to compiling
under a different kernel then the one it was being run under. (It seemed
more like a file system error to me though.)

As Freesco doesn't have make/gcc etc. I want to use my Core Linux system to
compile the software. (I cannot use the packaged versions of thttpd that are
available for Freesco because there are some compile-time tweaks I want to
make.) I assume one way round this problem would be to compile and boot
using the 2.0.38 kernel, compile thttpd and then restart using the 2.4.19
kernel. However, I'm sure that there was an easier way - there usually is
with Linux.

So, I have downloaded the kernel source for version 2.0.38 to my Core Linux
system, unzipped it to /usr/src/linux-2.0.38 and changed the sysmlink
/usr/src/linux to point to this new directory rather than the 2.4.19 kernel
source. thttpd uses a fairly standard configure script, which I have run in
the following ways:

./configure --prefix=/safe --target=i386-pc-linux-gnu
./configure --prefix=/safe --target=i386-pc-linux-gnu --includedir=/usr/src/
linux/include
./configure --prefix=/safe --target=i386-pc-linux-gnu --includedir=/usr/src/
linux/include --libdir=/usr/src/linux/lib

(admittedly this last one was a long shot ;-) ) However, the compiled
binaries are always the same size as when compiled under 2.4.19, leading me
to believe that what I'm trying is not the right way.

If anyone has any useful links on this subject, or can otherwise help out,
I'd be grateful.

Cheers, and sorry for the long post.

Tony Whitmore

It's most likely a library error, not a kernel issue.  On
the box on which you built the binary do 'ldd <binary file>'
to see what shared libs it is linked to.  Then ensure those
same libs are available on the target box.  Or give the same
command on the target machine, and see if it lists any libs
as "not found".  

It is likely either a glibc version incompatability between
the two systems, or a library is present on the build
machine but absent on the target.

[snip]

More likely: the box you're compiling it on is using a new glibc (2.2.x)
and the other box is using an ancient glibc (or libc5).

--
Jon Portnoy

Hello John-Paul, thanks for your reply.

I'm afraid I've got a few follow-up questions which I hope you, Jon Portnoy,
or someone else will be able to help me with.

1) If I find the correct library version for the "old" system, download it
to my "new" system and run the configure script using the "--libdir" switch
to point at the "old" libraries will that be sufficient?

2) If I do 1, do I still need to have the /usr/src/linux symlink still
pointing to the "old" kernel source?

3) What about the "--includedir" switch on the configure script: Am I right
to point that to "/usr/src/linux-2.0.38/include"?

Thanks again,

Tony

Quote:

> It's most likely a library error, not a kernel issue.  On
> the box on which you built the binary do 'ldd <binary file>'
> to see what shared libs it is linked to.  Then ensure those
> same libs are available on the target box.  Or give the same
> command on the target machine, and see if it lists any libs
> as "not found".

> It is likely either a glibc version incompatability between
> the two systems, or a library is present on the build
> machine but absent on the target.

Hmm. I think the problem you're going to have is that the program will use
whatever you input for libdir as an absolute path for future library
references. This means that on the target system, the library paths would
have to match whatever you input for libdir.

Quote:

> 2) If I do 1, do I still need to have the /usr/src/linux symlink still
> pointing to the "old" kernel source?

No, I don't think the program will care about the kernel sources unless
it's something that interacts directly with the kernel.

Quote:

> 3) What about the "--includedir" switch on the configure script: Am I right
> to point that to "/usr/src/linux-2.0.38/include"?

It probably is actually looking for /usr/include.

--
Jon Portnoy

Quote:> 1) If I find the correct library version for the "old" system, download it
> to my "new" system and run the configure script using the "--libdir" switch
> to point at the "old" libraries will that be sufficient?

> 2) If I do 1, do I still need to have the /usr/src/linux symlink still
> pointing to the "old" kernel source?

> 3) What about the "--includedir" switch on the configure script: Am I right
> to point that to "/usr/src/linux-2.0.38/include"?

You could just build a _static_ executable of 'thttpd' on the big box and
then move it to the firewall box.

Thanks Anon,

As I've said elsewhere, I'm keen to learn how to do this, even though I
think I've now found a workaround for my problem. Does anyone have any handy
links for HOW-TOs on compiling static binaries. I've tried running configure
with --disable-shared but I don't think that switch is defined for the
script I'm running. It certainly didn't make any difference to the compiled
binary sizes.

Thanks,

Tony

Thanks for your reply, Jon.

Luckily, there is a workaround for my exact problem (but I would like to
solve the issue more generally anyway). The workaround is to use ZipSlack
3.1 which can be used to compile software for a Freesco box as it has the
same library versions etc. as Freesco 0.2.7. But as I've said, I'd like to
learn how to solve the problem in a more linux-y way anyway.

On point 1) If the libraries on the target machine were in /lib for example,
would a symlink from /lib to the appropriate library version elsewhere on my
machine do the trick? After compiling, this could then be changed back to
the original location (if applicable).  This would solve the absolute path
name problem.

On point 2) So basically, the kernel version under which software is
compiled doesn't make any odds, unless there is direct interaction between
the program and theh kernel (eg iptables). All that is needed to compile a
piece of (non-kernel-interacting) software is the correct library versions.

On point 3) I understand that /usr/include is pretty much the default
location for this variable. Should this be different  for compiling under
different libary versions for a different system? Or is /usr/include for the
use of gcc and make etc. on the host system and so compatibility with the
target system shoudn't matter?

Cheers,

Tony

Quote:> > 1) If I find the correct library version for the "old" system, download
it
> > to my "new" system and run the configure script using the "--libdir"
switch
> > to point at the "old" libraries will that be sufficient?

> Hmm. I think the problem you're going to have is that the program will use
> whatever you input for libdir as an absolute path for future library
> references. This means that on the target system, the library paths would
> have to match whatever you input for libdir.

> > 2) If I do 1, do I still need to have the /usr/src/linux symlink still
> > pointing to the "old" kernel source?

> No, I don't think the program will care about the kernel sources unless
> it's something that interacts directly with the kernel.

> > 3) What about the "--includedir" switch on the configure script: Am I
right
> > to point that to "/usr/src/linux-2.0.38/include"?

> It probably is actually looking for /usr/include.

> --
> Jon Portnoy

Yes, you could _probably_ do something like use /path/to/old/libs for the
libdir as long as the target machine has proper symlinks in
/path/to/old/libs that match the machine it was built on.

Quote:

> On point 2) So basically, the kernel version under which software is
> compiled doesn't make any odds, unless there is direct interaction between
> the program and theh kernel (eg iptables). All that is needed to compile a
> piece of (non-kernel-interacting) software is the correct library versions.

Indeedy.

Quote:

> On point 3) I understand that /usr/include is pretty much the default
> location for this variable. Should this be different  for compiling under
> different libary versions for a different system? Or is /usr/include for the
> use of gcc and make etc. on the host system and so compatibility with the
> target system shoudn't matter?

[snip]

It shouldn't matter because includes aren't dynamically accessed.

--
Jon Portnoy

Thanks again Jon.

So, just to confirm that I've got this right: includes are used at compile
time only. Once an executable is compiled, the includes with which it was
compiled don't matter any more, and the executable should be portable
(subject to library dependencies).

Cheers,

Tony

Quote:> > On point 3) I understand that /usr/include is pretty much the default
> > location for this variable. Should this be different  for compiling
under
> > different libary versions for a different system? Or is /usr/include for
the
> > use of gcc and make etc. on the host system and so compatibility with
the
> > target system shoudn't matter?

> [snip]

> It shouldn't matter because includes aren't dynamically accessed.

Yup.

--
Jon Portnoy