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.
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
I totally agree with Q
2012.07.23. 23:15, "»Q«" ezt írta:
> On Mon, 23 Jul 2012 17:16:41 +0300
> 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
On Mon, 23 Jul 2012 17:16:41 +0300
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.
As I read the glib
Nikos Chantziaras 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. Th
On Thu, Aug 11, 2011 at 07:50, Nikos Chantziaras 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
On 08/10/2011 04:02 PM, c...@chrekh.se wrote:
Pandu Poluan 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
Pandu Poluan writes:
> On Wed, Aug 10, 2011 at 20:02, 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-compi
On Wed, Aug 10, 2011 at 20:02, wrote:
> Pandu Poluan 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 benifi
Pandu Poluan 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
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 r
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 kerne
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
res
13 matches
Mail list logo
