[gentoo-user] Re: linux-headers-4.19 & glibc

2019-07-24 Thread Nikos Chantziaras

On 24/07/2019 16:49, Hasan ÇALIŞIR wrote:

Today i got linux-headers-4.19 update.

Doesn't it need re-building glibc that currently not triggered on my system?


Nope. No need.




Re: [gentoo-user] Re: linux-headers-3.5 with 3.4 kernel?

2012-07-24 Thread Oszkár Ocsenás
I totally agree with Q
2012.07.23. 23:15, »Q« boxc...@gmx.net ezt írta:

 On Mon, 23 Jul 2012 17:16:41 +0300
 Nikos Chantziaras rea...@gmail.com wrote:

  Portage now installs sys-kernel/linux-headers-3.5.
  sys-kernel/gentoo-sources is at 3.4.5.
 
  Is it even adviced to do that, installing 3.5 headers and running a
  3.4 kernel?  This sounds like a bad idea to me.

 As I read the glibc faq, linux-headers are backwards-compatible as far
 as glibc is concerned;  that is, newer linux-headers still have
 everything needed to make glibc work with older kernels.  And I assume
 that holds for other packages which need linux-headers, not just glibc.

 Whether my understanding of why is correct or not, the glibc folks do
 recommend using the latest linux-headers, even if your kernel is older.

 https://www.gnu.org/software/libc/documentation.html links to
 
 http://sourceware.org/glibc/wiki/FAQ#What_version_of_the_Linux_kernel_headers_should_be_used.3F
 .





[gentoo-user] Re: linux-headers-3.5 with 3.4 kernel?

2012-07-24 Thread Nikos Chantziaras

On 23/07/12 23:01, Helmut Jarausch wrote:

On 07/23/2012 04:16:41 PM, Nikos Chantziaras wrote:

Portage now installs sys-kernel/linux-headers-3.5.
sys-kernel/gentoo-sources is at 3.4.5.

Is it even adviced to do that, installing 3.5 headers and running a
3.4 kernel?  This sounds like a bad idea to me.



Why are you not using the 3.5.0 kernel


Because BFS doesn't support it yet.




[gentoo-user] Re: linux-headers-3.5 with 3.4 kernel?

2012-07-23 Thread »Q«
On Mon, 23 Jul 2012 17:16:41 +0300
Nikos Chantziaras rea...@gmail.com wrote:

 Portage now installs sys-kernel/linux-headers-3.5. 
 sys-kernel/gentoo-sources is at 3.4.5.
 
 Is it even adviced to do that, installing 3.5 headers and running a
 3.4 kernel?  This sounds like a bad idea to me.

As I read the glibc faq, linux-headers are backwards-compatible as far
as glibc is concerned;  that is, newer linux-headers still have
everything needed to make glibc work with older kernels.  And I assume
that holds for other packages which need linux-headers, not just glibc.

Whether my understanding of why is correct or not, the glibc folks do
recommend using the latest linux-headers, even if your kernel is older.

https://www.gnu.org/software/libc/documentation.html links to 
http://sourceware.org/glibc/wiki/FAQ#What_version_of_the_Linux_kernel_headers_should_be_used.3F.




Re: [gentoo-user] Re: linux-headers-2.6.38

2011-08-11 Thread Pandu Poluan
On Thu, Aug 11, 2011 at 07:50, Nikos Chantziaras rea...@arcor.de wrote:
 On 08/10/2011 04:02 PM, c...@chrekh.se wrote:

 There is at least a theoretical benifit if you set NPTL_KERN_VER=2.6.38
 in make.conf and recompile glibc. That way glibc could use things not
 present in older kernels.

 glibc will use things in newer kernels anyway.  You don't need to use
 NPTL_KERN_VER=2.6.38 in order for glibc to use 2.6.38 features; it will do
 that by default.  NPTL_KERN_VER only omits fallbacks for older kernels.
  It's there to reduce the size of glibc.  The size difference is very small
 though.


Thanks for the explanation, Nikos. Since the size difference is very
small, I'll just use NPTL_KER_VER as it is (that is, not mucking with
it).

Rgds,
-- 
FdS Pandu E Poluan
~ IT Optimizer ~

 • Blog : http://pepoluan.tumblr.com
 • Linked-In : http://id.linkedin.com/in/pepoluan



[gentoo-user] Re: linux-headers-2.6.38

2011-08-11 Thread che
Nikos Chantziaras rea...@arcor.de writes:


 glibc will use things in newer kernels anyway.  You don't need to use
 NPTL_KERN_VER=2.6.38 in order for glibc to use 2.6.38 features; it
 will do that by default.  NPTL_KERN_VER only omits fallbacks for older
 kernels.  It's there to reduce the size of glibc.  The size difference
 is very small though.

That seems likely. Thanks.

Do you know if linux-headers-2.6.38 is needed for that to work?

I would guess it is.


--
 Christer




[gentoo-user] Re: linux-headers-2.6.38

2011-08-10 Thread che
Pandu Poluan pa...@poluan.info writes:

 While I'm about to do an `emerge -e @world` ...

 Should I `emerge -av =sys-kernel/linux-headers-2.6.38 ` ?

 Any benefits over the current sys-kernel/linux-headers-2.6.36.1 ?

There is at least a theoretical benifit if you set NPTL_KERN_VER=2.6.38
in make.conf and recompile glibc. That way glibc could use things not
present in older kernels.

I haven't researched if there are any such things, perhaps someone else
knows.

Also, beware. If you recompile glibc withe NPTL_KERN_VER set, you can't
boot with older kernels anymore.

--
 Christer




Re: [gentoo-user] Re: linux-headers-2.6.38

2011-08-10 Thread Pandu Poluan
On Wed, Aug 10, 2011 at 20:02,  c...@chrekh.se wrote:
 Pandu Poluan pa...@poluan.info writes:

 While I'm about to do an `emerge -e @world` ...

 Should I `emerge -av =sys-kernel/linux-headers-2.6.38 ` ?

 Any benefits over the current sys-kernel/linux-headers-2.6.36.1 ?

 There is at least a theoretical benifit if you set NPTL_KERN_VER=2.6.38
 in make.conf and recompile glibc. That way glibc could use things not
 present in older kernels.

 I haven't researched if there are any such things, perhaps someone else
 knows.


Hmmm... without a reference, I'd rather not do something too drastic...

 Also, beware. If you recompile glibc withe NPTL_KERN_VER set, you can't
 boot with older kernels anymore.


Can you explain what did you mean with older kernels? Kernels older
than a certain version, or a previously-compiled kernel on my system?

Anyways, this is a fresh install, so I don't think I'll have any trouble.

But will still appreciate a reference and/or explanation re:
NPTL_KERN_VER, though.

Rgds
-- 
FdS Pandu E Poluan
~ IT Optimizer ~

 • Blog : http://pepoluan.tumblr.com
 • Linked-In : http://id.linkedin.com/in/pepoluan



[gentoo-user] Re: linux-headers-2.6.38

2011-08-10 Thread che
Pandu Poluan pa...@poluan.info writes:
 On Wed, Aug 10, 2011 at 20:02,  c...@chrekh.se wrote:
 Also, beware. If you recompile glibc withe NPTL_KERN_VER set, you can't
 boot with older kernels anymore.


 Can you explain what did you mean with older kernels? Kernels older
 than a certain version, or a previously-compiled kernel on my system?


Older then the kernel you specified, previously-compiled kernels not
older than that is still fine.

Any executable linked to glibc will fail unconditionally with
FATAL: Kernel too old, including init.


 Anyways, this is a fresh install, so I don't think I'll have any trouble.

 But will still appreciate a reference and/or explanation re:
 NPTL_KERN_VER, though.

glibc will be configured with --enable-kernel=2.6.38

The configure help says this;

 --enable-kernel=VERSION compile for compatibility with kernel not older than 
VERSION

--
 Christer




[gentoo-user] Re: linux-headers-2.6.38

2011-08-10 Thread Nikos Chantziaras

On 08/10/2011 04:02 PM, c...@chrekh.se wrote:

Pandu Poluanpa...@poluan.info  writes:


While I'm about to do an `emerge -e @world` ...

Should I `emerge -av =sys-kernel/linux-headers-2.6.38 ` ?

Any benefits over the current sys-kernel/linux-headers-2.6.36.1 ?


There is at least a theoretical benifit if you set NPTL_KERN_VER=2.6.38
in make.conf and recompile glibc. That way glibc could use things not
present in older kernels.

I haven't researched if there are any such things, perhaps someone else
knows.


glibc will use things in newer kernels anyway.  You don't need to use 
NPTL_KERN_VER=2.6.38 in order for glibc to use 2.6.38 features; it will 
do that by default.  NPTL_KERN_VER only omits fallbacks for older 
kernels.  It's there to reduce the size of glibc.  The size difference 
is very small though.





Re: [gentoo-user] Re: linux-headers

2009-01-14 Thread Michael P. Soulier
On 14/01/09 Nikos Chantziaras said:

 You don't need to have them in sync.  The safest is to have a version that 
 is either equal or lower to your kernel.  So for you, 2.6.23-r3 is 
 perfectly fine.  An exception is if you're using a recent glibc (2.9); 
 you'll need to build it against more recent headers.

Hmm. Well, I'm currently using sys-libs/glibc-2.6.1, but presumably that will
change at some point in the future...

Mike
-- 
Michael P. Soulier msoul...@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


pgpbEzybTPUf9.pgp
Description: PGP signature


[gentoo-user] Re: linux-headers

2009-01-13 Thread Nikos Chantziaras

Michael P. Soulier wrote:

Hello,

I'm currently running kernel 2.6.25 and I have no issues with it so I don't
really want to upgrade it just yet. I just picked up
sys-kernel/linux-headers-2.6.27-r2, so I thought I'd mask out anything above
2.6.25 for now to keep the headers in sync with the kernel that I'm running.


You don't need to have them in sync.  The safest is to have a version 
that is either equal or lower to your kernel.  So for you, 2.6.23-r3 is 
perfectly fine.  An exception is if you're using a recent glibc (2.9); 
you'll need to build it against more recent headers.





[gentoo-user] Re: linux-headers vs gentoo-sources

2006-12-07 Thread 7v5w7go9ub0o



This show the disadvantage of aggressively cleaning $DISTDIR. You have
already downloaded this file once, when you installed 2.6.17-r1 (or even
earlier when you first installed a 2.6.17 kernel). Patch level updates  
use

the same source files, so cleaning out tarballs for installed packages
results in more downloads and more load on the mirrors.




Thanks for pointing this out. Suppose it's listed somewhere, but new to me.

Newbie

p.s. perhaps a permanent link on the newsletter to a page titled 20 (30?)  
useful tidbits that everyone knows about Gentoo, that make life  
easier? It would include a link to Bugzilla; references to equery  
depends; dep -L; pquery --vdb --revdep; only one emerge sync per day; etc.  
i.e. all the stuff that recurrs here.




--
gentoo-user@gentoo.org mailing list