[gentoo-user] glibc update

[gentoo-user] glibc update

[Michael P. Soulier]

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]

Hello,

Looking at what I'm about to pick up via emerge, I notice this

[ebuild     U ] sys-libs/glibc-2.8_p20080602-r1 [2.6.1]

This immediately sets off alarm bells for me, since glibc is the basis of the
whole system. If I pick this up do I have to rebuild everything?

I've also frozen my kernel at 2.6.25 for now due to the nvidia-drivers
package. I have to use an older one for 3D accel and it doesn't work with the
newer kernels according to a bug report I saw. At some point I'm assuming that
a new glibc will require a new kernel too, if the interface changes, so
presumably I'll have to update eventually.

I could just use the nv driver since the 3D accel is not a must-have, or pick
up a new video card. Currently VIDEO_CARDS="nvidia" in my make.conf just
automatically pulls in nvidia-drivers though, which is broken for me.

But I digress. Upgrade glibc, rebuild everything? I suppose revdep-rebuild
will figure that out anyway...

Mike
-- 
Michael P. Soulier <msoulier@digitaltorque.ca>
"Any intelligent fool can make things bigger and more complex... It takes a
touch of genius - and a lot of courage to move in the opposite direction."
--Albert Einstein

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] glibc update

[Alan McKinnon]

On Wednesday 18 March 2009 13:23:47 Michael P. Soulier wrote:
> Hello,
>
> Looking at what I'm about to pick up via emerge, I notice this
>
> [ebuild     U ] sys-libs/glibc-2.8_p20080602-r1 [2.6.1]
>
> This immediately sets off alarm bells for me, since glibc is the basis of
> the whole system. If I pick this up do I have to rebuild everything?

No, this one is safe. Here's what happens:

You said "glibc is the basis of the whole system". That's not quite true, it's 
actually "glibc provides the C library, which is a collection of basic 
function calls that just about every other program uses sooner or later"

Quite a different thing actually. The interface the glibc presents to the rest 
of the machine doesn't reduce. Everything that your programs used to see, they 
will still see. What might happen is the glibc provides extra stuff, but that 
doesn't matter as your existing compiled programs don't know about it and 
can't use it. A lot like replacing a power outlet in your house - it looks the 
same as the old one so there's no need to buy a new toaster.

If there's an issues, revdep-rebuild will pick them up.

Sometimes, glibc is all fsck'ed up. Like sys-libs/glibc-2.9_p20081201-r1. It 
looks great, till you start firefox and find that it doesn't run anymore...

>
> I've also frozen my kernel at 2.6.25 for now due to the nvidia-drivers
> package. I have to use an older one for 3D accel and it doesn't work with
> the newer kernels according to a bug report I saw. At some point I'm
> assuming that a new glibc will require a new kernel too, if the interface
> changes, so presumably I'll have to update eventually.

No, glibc might need updated kernel headers. The compiler uses them when 
building glibc - the headers tell the compiler what data structures, functions 
etc look like so that the glibc it builds can talk to whatever kernel you 
choose to run later.

The only time you really need to update the kernel headers is if they provide 
some new features you want to take advantage of. The interface that the kernel 
provides to userspace is virtually frozen and Linus simply never changes it.

In short, updating glibc is as safe as updating any other piece of software, 
as long as it has no known major bugs that cause you issues.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] glibc update

[Michael P. Soulier]

[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]

On 18/03/09 Alan McKinnon said:

> You said "glibc is the basis of the whole system". That's not quite true,
> it's actually "glibc provides the C library, which is a collection of basic
> function calls that just about every other program uses sooner or later"

I wasn't sure if any interface changes had been made. Looking at the glibc 2.8
release notes, it doesn't look like it but I wanted to check before upgrading.
It makes me nervous. :)

> If there's an issues, revdep-rebuild will pick them up.

Ok, good.

> Sometimes, glibc is all fsck'ed up. Like sys-libs/glibc-2.9_p20081201-r1. It
> looks great, till you start firefox and find that it doesn't run anymore...

So, how would I know, in general, whether it's safe to upgrade when it appears
in my emerge output? Just ask here? My BSD box has a /usr/ports/UPDATING file
that I check before upgrading ports for any notices...

> No, glibc might need updated kernel headers. The compiler uses them when
> building glibc - the headers tell the compiler what data structures,
> functions etc look like so that the glibc it builds can talk to whatever
> kernel you choose to run later.

So will it use /usr/src/linux by default? If so then I'm ok...

> The only time you really need to update the kernel headers is if they
> provide some new features you want to take advantage of. The interface that
> the kernel provides to userspace is virtually frozen and Linus simply never
> changes it.

Good to know.

> In short, updating glibc is as safe as updating any other piece of software,
> as long as it has no known major bugs that cause you issues.

Ok, thanks for the response.

Mike
-- 
Michael P. Soulier <msoulier@digitaltorque.ca>
"Any intelligent fool can make things bigger and more complex... It takes a
touch of genius - and a lot of courage to move in the opposite direction."
--Albert Einstein

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-user] glibc update

[Alan McKinnon]

On Wednesday 18 March 2009 20:05:27 Michael P. Soulier wrote:
> > Sometimes, glibc is all fsck'ed up. Like sys-libs/glibc-2.9_p20081201-r1.
> > It looks great, till you start firefox and find that it doesn't run
> > anymore...
>
> So, how would I know, in general, whether it's safe to upgrade when it
> appears in my emerge output? Just ask here? My BSD box has a
> /usr/ports/UPDATING file that I check before upgrading ports for any
> notices...

Well, this is gentoo and we don't need no stinking Changelogs on gentoo :-)

Seriously, you are running a stable arch. All known issues should be resolved 
by the time glibc hits stable. You can always askhere, or look at b.g.o for 
any outstanding issues
>
> > No, glibc might need updated kernel headers. The compiler uses them when
> > building glibc - the headers tell the compiler what data structures,
> > functions etc look like so that the glibc it builds can talk to whatever
> > kernel you choose to run later.
>
> So will it use /usr/src/linux by default? If so then I'm ok...

No, it goes nowhere near that directory. It uses /usr/include/linux

From your responses it seems like you haven't figured out yet how the whole 
compile/link/header thing works, so here's the (quickish) version:

If an application uses a library that is already built and located elsewhere, 
the compiler needs to know what the data structures and functions in that 
library look like. This information is in the library's source code, but to 
make life for everyone infinitely easier, it is by convention separated out 
into so-called header files. These files don't contain any executable source 
code, just the definitions of things implemented by the library and publicly 
available. The benefit is that to compile something, you only need the (small) 
header files, not the full collection of (large) source code. Even on gentoo 
we have this - when you emerge wget, it most certainly uses something provided 
by glibc, yet the glibc source code is not available at emerge time - but the 
glibc headers are.

These headers can technically be placed anywhere. The convention is to put 
them in /usr/include and to tell your compiler to look there for headers.

glibc in turn also needs headers for things it uses, and amongst others this 
is the kernel headers in /usr/include/linux/. This doesn't have to be the same 
headers for the kernel you are running, it just has to be compatible headers. 
To prove this, just reboot and choose a different kernel. Everything works, 
but glibc could not possibly have been built against both kernel's sources.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] glibc update

[Michael P. Soulier]

[-- Attachment #1: Type: text/plain, Size: 2123 bytes --]

On 18/03/09 Alan McKinnon said:

> Well, this is gentoo and we don't need no stinking Changelogs on gentoo :-)

:)

> Seriously, you are running a stable arch. All known issues should be resolved 
> by the time glibc hits stable. You can always askhere, or look at b.g.o for 
> any outstanding issues

Bulgarian Gay Organization? Sorry, googling for b.g.o is dangerous. :)

> No, it goes nowhere near that directory. It uses /usr/include/linux
> 
> From your responses it seems like you haven't figured out yet how the whole 
> compile/link/header thing works, so here's the (quickish) version:

Actually I do, but I don't go anywhere near the kernel so I wasn't sure of the
relationship between glibc and the kernel interfaces. I'm just wondering if
/usr/include/linux is ever incompatible with my kernel, and what to do about it if
it is.

> glibc in turn also needs headers for things it uses, and amongst others this 
> is the kernel headers in /usr/include/linux/. This doesn't have to be the same 
> headers for the kernel you are running, it just has to be compatible headers. 
> To prove this, just reboot and choose a different kernel. Everything works, 
> but glibc could not possibly have been built against both kernel's sources.

I see that, for example, 

msoulier@anton:~$ equery belongs /usr/include/linux/quota.h
[ Searching for file(s) /usr/include/linux/quota.h in *... ]
sys-kernel/linux-headers-2.6.23-r3 (/usr/include/linux/quota.h)

ulier@anton:~$ uname -a
Linux anton 2.6.25-gentoo-r8 #9 Sun Nov 23 19:14:08 EST 2008 i686 AMD
Athlon(tm) XP 1700+ AuthenticAMD GNU/Linux

So slightly off but compatible. At some point a newer glibc would simply fail
to build if it's incompatible then, I assume?

Looking on a CentOS box I see that they package that directory in a package
called glibc-kernheaders. Makes sense...

Thanks,
Mike
-- 
Michael P. Soulier <msoulier@digitaltorque.ca>
"Any intelligent fool can make things bigger and more complex... It takes a
touch of genius - and a lot of courage to move in the opposite direction."
--Albert Einstein


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] glibc update

[Paul Hartman]

On Wed, Mar 18, 2009 at 4:43 PM, Michael P. Soulier
<msoulier@digitaltorque.ca> wrote:
> On 18/03/09 Alan McKinnon said:
>
>> Seriously, you are running a stable arch. All known issues should be resolved
>> by the time glibc hits stable. You can always askhere, or look at b.g.o for
>> any outstanding issues
>
> Bulgarian Gay Organization? Sorry, googling for b.g.o is dangerous. :)

I assume he meant bugs.gentoo.org

Re: [gentoo-user] glibc update

[Alan McKinnon]

On Wednesday 18 March 2009 23:43:50 Michael P. Soulier wrote:
> On 18/03/09 Alan McKinnon said:
> > Well, this is gentoo and we don't need no stinking Changelogs on gentoo
> > :-)
> >
> :)
> :
> > Seriously, you are running a stable arch. All known issues should be
> > resolved by the time glibc hits stable. You can always askhere, or look
> > at b.g.o for any outstanding issues
>
> Bulgarian Gay Organization? Sorry, googling for b.g.o is dangerous. :)

hehehe, that's funny :-)

bugs.gentoo.org
b.g.o. is the common name used around here. Probably not the most obvious 
thing in the world though

[snip]

> msoulier@anton:~$ equery belongs /usr/include/linux/quota.h
> [ Searching for file(s) /usr/include/linux/quota.h in *... ]
> sys-kernel/linux-headers-2.6.23-r3 (/usr/include/linux/quota.h)
>
> ulier@anton:~$ uname -a
> Linux anton 2.6.25-gentoo-r8 #9 Sun Nov 23 19:14:08 EST 2008 i686 AMD
> Athlon(tm) XP 1700+ AuthenticAMD GNU/Linux
>
> So slightly off but compatible. At some point a newer glibc would simply
> fail to build if it's incompatible then, I assume?

It is as close to guaranteed to build as you are ever going to get. The public 
interface to the kernel via it's headers simply does not change in 
incompatible ways.

But if it ever did, then yes, glibc would fail to build

> Looking on a CentOS box I see that they package that directory in a package
> called glibc-kernheaders. Makes sense...
>
> Thanks,
> Mike

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] glibc update

[Jorge Morais]

On Wed, 18 Mar 2009 23:49:12 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> > msoulier@anton:~$ equery belongs /usr/include/linux/quota.h
> > [ Searching for file(s) /usr/include/linux/quota.h in *... ]
> > sys-kernel/linux-headers-2.6.23-r3 (/usr/include/linux/quota.h)
> >
> > ulier@anton:~$ uname -a
> > Linux anton 2.6.25-gentoo-r8 #9 Sun Nov 23 19:14:08 EST 2008 i686 AMD
> > Athlon(tm) XP 1700+ AuthenticAMD GNU/Linux
> >
> > So slightly off but compatible. At some point a newer glibc would simply
> > fail to build if it's incompatible then, I assume?
> 
> It is as close to guaranteed to build as you are ever going to get. The public 
> interface to the kernel via it's headers simply does not change in 
> incompatible ways.
> 
> But if it ever did, then yes, glibc would fail to build

This was a doubt of mine. One of the reasons I prefer to use a stable
kernel is that I don't know if, when using a newer (and ~x86) kernel,
I should also use the corresponding linux-headers version. So you say
I can be 99.999% sure that, should I update my kernel (say, to 2.6.28)
and meet problems, those will be intrinsic to this kernel version
(and possibly to incompatibilities with things like out-of-tree
kernel modules), but never because the kernel headers are outdated?

IOW, the only real problem of using outdated kernel headers is not
fully taking advantage of new features?

I prefer to use stable software anyway, but it is important to know.

Re: [gentoo-user] glibc update

[Alan McKinnon]

On Friday 20 March 2009 03:52:10 Jorge Morais wrote:
> This was a doubt of mine. One of the reasons I prefer to use a stable
> kernel is that I don't know if, when using a newer (and ~x86) kernel,
> I should also use the corresponding linux-headers version. So you say
> I can be 99.999% sure that, should I update my kernel (say, to 2.6.28)
> and meet problems, those will be intrinsic to this kernel version
> (and possibly to incompatibilities with things like out-of-tree
> kernel modules), but never because the kernel headers are outdated?

Yes

> IOW, the only real problem of using outdated kernel headers is not
> fully taking advantage of new features?

Yes

-- 
alan dot mckinnon at gmail dot com

[gentoo-user] Re: glibc update

[Nikos Chantziaras]

Alan McKinnon wrote:
>> IOW, the only real problem of using outdated kernel headers is not
>> fully taking advantage of new features?
> 
> Yes

I did encounter strange bugs (programs not starting) until I updated the 
kernel headers, so instead of "yes" I'd say "no".