mem_unit

[Stephen Weeks]

> I  think  that thing that link with the new libraries just won't run with the
> old ones. 
...
> The old Red Hat has the older glibc, the older type of RPM and the
> older kernel.  The newer Red Hats have the reverse.

OK.  I  guess we have to live with it.  The only thing I don't
understand is the details of why it works for Matthew:

> I don't know what issues Henry saw.  I do self-compiles on a Linux
> cluster with 2.4 kernel/2.2.2 glibc, then pull the resulting
> executables back to my office 2.2 kernel/2.1.3 glibc box.

and not for Henry:

> I just tried running a binary compiled under Red Hat 7.2 using MLton
> under Red Hat 6.0, and as I rememberd, it fails.  ldd reports
> 	/lib/libc.so.6: version `GLIBC_2.1.3' not found

I see that Henry is going back further.  If I do an objdump -p on a
recent mlton-generated executable on my machine, I see

required from libc.so.6:
    0x09691f73 0x00 05 GLIBC_2.1.3
    0x0d696911 0x00 04 GLIBC_2.1
    0x0d696910 0x00 02 GLIBC_2.0

This even though I am using glibc-2.2.2.  I am confused about the
relationship between the version of glibc that I'm using, the version
of glibc for executables I link with, and versions that they require
when running.  On my machine, in /lib, I have libc-2.2.2.so and
libc.so.6, which points to libc-2.2.2.so.

Does the above objump mean that three different shared libraries must
be loaded in order for the app to work?

> As to the mem_unit problem and the different kernels
...
> One option would be to simple  include  the  struct  definition  in  our  own
> include  file  (basically  from /usr/include/linux/kernel.h of a new kernel).
> This way we will ALWAYS have mem_unit defined.  The code would then check  if
> the  value  was  0  (meaning  it  is  running  under an old kernel) and use 1
> instead.

OK.  I went with this.  It seems the most painless, and avoids having
to tell others to change the code so they can compile.