Kernel too old

[rsandstrom]

I've recently been getting an error with bedops when running on a  cluster:


bedops -e bar.bed foo.bed
FATAL: kernel too old
Segmentation fault

foo.bed:
chr1   1   1000   a   1
chr1   10001   20000   b   2

bar.bed
chr1   10   1000   z   1


bedops was built on my local machine and looking at the kernel version i get:

Code: [Select]

cat /proc/sys/kernel/osrelease2.6.35.14-95.fc14.x86_64

and the cluster machine (threeski and nineski)  where my bedops executable is mounted via a home directory mount

Code: [Select]

cat /proc/sys/kernel/osrelease2.6.18-274.el5

if I go the other way and build bedops on the cluster then run commands locally everything works, and is cool.

My question is this, is this a sysadmin sort of issue or is there something about bedops that should handle kernel version differences?

I've tried the same thing with bedmap and get the same error, but if I do a utility like sort-bed the issue doesn't show up.

(note that I do a make clean before make, and I've done I full build and individual tool builds to debug).


feel free to delete this and/or send me along to my sysadmin 

[sjn]

This is an interesting problem.

Can you report what:
file applications/bed/bedops/bin/bedops
gives using your local machine?

This may have to do with glibc and not the kernel version difference.  I have local kernel 2.6.34.9-69.fc13.x86_64, and I can compile the static bedops executable and call from a cluster machine that runs the kernel version you note.  However, when I use file on the executable, it says:

bedops: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.18, stripped
(note the 2.6.18 version)

This will be an interesting problem to pin down and understand in detail.

[rsandstrom]

compiled on local machin:
bedops: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, stripped

complied on a cluster node:
bedops: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, stripped

[sjn]

Well, I give up.  Brendan spent some time on this and so did I.

I guess the take-home message is that if you create an (even static) executable on a system with a more current major release of gcc and library builds, the executable may not be runnable from a machine with older versions of libraries.  I'm certain the kernel would play a role at some point too.

I tried a lot of different things.  It appears that even with the -static flag to gcc, it likes to use -shared-libgcc and related flags.  Turning those off and ensuring everything was static still gives runtime errors.  Even if we had some success in all of this, the problem is very low-level (run with the strace command to see details of failure), and I would not feel confident in applying a fix.  Rather, we just need to keep the systems at the same major gcc release level, or compile on the older setups which (so far) seem to run OK on the newer builds.

Wish I had something of real substance to say here.  One message board showed:

"Correct, every binary compiled with a given version of glibc expects a
given kernel version or newer. The minimum kernel version is encoded
at glibc build time using --enable-kernel. The minimum kernel version
allows glibc to *expect* certain kernel features to be present."

So, perhaps the newer kernel does in fact play a direct role here.

[rsandstrom]

I'm fine with my solution, and I really appreciate you looking at this so closely.  It gives something to the knowledge base, and that's not nothing 

[sjn]

Looking at http://wiki.osdev.org/How_kernel,_compiler,_and_C_library_work_together

under ABI - Application Binary Interface

The ABI of a system defines how library function calls and kernel system calls are actually done. This includes e.g. whether parameters are passed on the stack or in registers, how function entry points are located in libraries etc.

When using static linkage, the resulting executable is depending on the executing kernel using the same ABI as the one it was built for; when using dynamic linkage, the executable is depending on the libraries' ABI staying the same.

Building bedops using dynamic linking (new kernel/glibc machine) and running (out of date machine) presents another set of errors based upon GLIBC version, as expected.