1:41 p.m.
Executable program files built by gcc+glibc on Fedora 14 contain a PT_NOTE
which says "for GNU/Linux 2.6.32". (For example, see "file
/bin/date";
the presence of a NOTE is indicated by "readelf --segments /bin/date",
but readelf does not display the contents.) What does the PT_NOTE mean;
what program cares about this value?
The /bin/date of Fedora 14 does run on Fedora 11 which is only Linux 2.6.30.
So there is no harm in this case, despite "not meeting the requirement." Why?
If the requirement really is something less than Linux 2.6.32,
then why not note the minimum kernel version that is required?
How far back on previous Fedora releases can the /bin/date (and/or anything
else built by gcc+glibc on Fedora 14) run successfully? What does this mean
for builders who want to build on Fedora 14 and distribute the binary
executable program files to run on other systems?
--
3:31 p.m.
On Mon, Sep 20, 2010 at 11:41:31 -0700,
John Reiser <jreiser(a)bitwagon.com> wrote:
Executable program files built by gcc+glibc on Fedora 14 contain a
PT_NOTE
which says "for GNU/Linux 2.6.32". (For example, see "file
/bin/date";
the presence of a NOTE is indicated by "readelf --segments /bin/date",
but readelf does not display the contents.) What does the PT_NOTE mean;
what program cares about this value?
I expect this is the lowest version kernel you can be running executable
programs on with this combination of gcc and glibc.
The /bin/date of Fedora 14 does run on Fedora 11 which is only Linux
2.6.30.
So there is no harm in this case, despite "not meeting the requirement." Why?
Not that you noticed, but potentially there could have been registers
clobbered that you didn't notice or similar things.
If the requirement really is something less than Linux 2.6.32,
then why not note the minimum kernel version that is required?
How far back on previous Fedora releases can the /bin/date (and/or anything
else built by gcc+glibc on Fedora 14) run successfully? What does this mean
for builders who want to build on Fedora 14 and distribute the binary
executable program files to run on other systems?
They probably shouldn't be doing that.
6:23 p.m.
On Mon, Sep 20, 2010 at 12:41, John Reiser <jreiser(a)bitwagon.com> wrote:
Executable program files built by gcc+glibc on Fedora 14 contain a
PT_NOTE
which says "for GNU/Linux 2.6.32". (For example, see "file
/bin/date";
the presence of a NOTE is indicated by "readelf --segments /bin/date",
but readelf does not display the contents.) What does the PT_NOTE mean;
what program cares about this value?
The /bin/date of Fedora 14 does run on Fedora 11 which is only Linux 2.6.30.
So there is no harm in this case, despite "not meeting the requirement." Why?
If the requirement really is something less than Linux 2.6.32,
then why not note the minimum kernel version that is required?
How far back on previous Fedora releases can the /bin/date (and/or anything
else built by gcc+glibc on Fedora 14) run successfully? What does this mean
for builders who want to build on Fedora 14 and distribute the binary
executable program files to run on other systems?
Here is a limited matrix for what glibc was with which kernel. Stuff
compiled with 14/Rawhide looks like it is compiled with upcoming
2.13...
I would think that items compiled in 12 and 13 would work well
together but 14 items on 12/13 may have issues. Items before 12 even
more so.
Fedora OS Version Release Name Date of Release # of .src.rpms
kernel glibc gcc X
01 Yarrow 2003-11-05 876 2.4.22-nptl 2.3.2 3.3.2 XFree86 4.3.0
02 Tettnang 2004-05-18 946 2.6.5 (2.6.10) 2.3.3 3.3.3 x.org 6.7.0
03 Heidelberg 2004-11-08 2079 2.6.9 (2.6.12) 2.3.3 (2.3.4) 3.4.2
(3.4.4) 6.8.1 (6.8.2)
04 Stentz 2005-06-13 2753 2.6.11 (2.6.17) 2.3.5 (2.3.6) 4.0.0
(4.0.2) 6.8.2
05 Bordeaux 2006-03-20 3137 2.6.15 (2.6.20) 2.4 4.1.0 (4.1.1)
server 1.0.1
06 Zod 2006-10-24 3681 2.6.18 (2.6.22.14) 2.5 4.1.1 (4.1.2) 1.1.1
07 Moonshine 2007-05-31 5189 2.6.21 (2.6.23.17) 2.6 4.1.2 1.3.0.0
08 Werewolf 2007-11-08 6042 2.6.23.1 (2.6.26.8) 2.7 4.1.2 1.3.0.0
09 Sulphur 2008-05-13 7085 2.6.25 (2.6.27.25) 2.8 4.3.0
1.4.99.901 (1.5.2)
10 Cambridge 2008-11-25 8103 2.6.27.5 (2.6.27.41) 2.9 4.3.2 1.5.3
11 Leonidas 2009-06-09 8935 2.6.29.4 (2.6.30.10) 2.10.1 (2.10.2)
4.4.0 (4.4.1) 1.6.1.901 (1.6.4)
12 Constantine 2009-11-17 9428 2.6.31.5 (2.6.32.21) 2.11 (2.11.2)
4.4.2 (4.4.4) 1.7.1 (1.7.6)
13 Goddard 2010-05-25 9555 2.6.33.3 (2.6.34.6) 2.12 4.4.4 1.8.0 (1.8.2)
14 Laughlin (2010-09-14) 9644 2.6.35.4 2.12.90 4.5.1 1.8.99.905 ()
Rawhide Rawhide (2010-09-14) 9701 2.6.36 2.12.90 4.5.1 7.6
--
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines
1:35 a.m.
This note comes from crt1.o, which is linked into every normal program
(both static and dynamic). Off hand, I'm not sure of anything that
actually checks this note.
What it indicates is the minimum required kernel version that glibc was
built for (its --enable-kernel configure option). This controls what
system calls and such kernel features the libc code is built to assume
exist and work correctly.
In a statically-linked executable, there may very well be libc code that
requires that new a kernel. The startup code in libc actually checks
the kernel version against this, so a static executable won't try to run.
For normal dynamically-linked executables, it is unlikely this note
really means anything that matters. (I'm not entirely positive about
this.) The same kernel requirement is built into all the DSOs in the
glibc package, including the dynamic linker itself. The dynamic
linker's startup code does the same kernel version check that is done by
static libc code in a static link. But that is based on what those DSOs
need, not what the crt1.o note in your executable says.
For Fedora glibc builds, we have chosen the newest --enable-kernel
version that we can use. (It is always more optimal to disable the
compatibility code.) The limiting factor has been the kernels that
the koji build machines run, so that glibc's build can do "make check"
(actually the build itself requires running the just-built libc too).
That's why it was 2.6.18 for so long, because those machines ran RHEL5.
Now, I guess they run RHEL6 or something, so we can rely on getting 2.6.32.
The proper and recommended way to build binaries that will be sure to be
compatible with an older Fedora is to build them against the glibc-devel
(and every other -devel) from that Fedora. I think most people use mock.
Thanks,
Roland
4994
days inactive
4995
days old
3 comments
4 participants
participants (4)
-
Bruno Wolff III -
John Reiser -
Roland McGrath -
Stephen John Smoogen