Chris Staub | 1 Oct 2006 09:58

Re: Two identical paragraphs in 8.8

Vladimir A. Pavlov wrote:
> Hi!
> 
> There are two identical paragraphs in the chapter
> "8.8. Creating the passwd, group, and log Files".
> 
> They sounds as follows
> 
> START
> 
> The created groups are not part of any standard—they are groups
> decided on in part by the requirements of the Udev configuration in the
> final system [snip] All other group names and GIDs can be chosen freely by
> the system administrator since well-written programs do not depend on
> GID numbers, but rather use the group's name.
> 
> END
> 
> The first copy is right after the list of additional groups while the
> second one is right before the command block starting with
> "touch /var/run/utmp ...".
> 
> The error appears both in 1.0.0 and SVN-20060925.
> 

Thanks for reporting this, it has been fixed.
Dennis Stout | 1 Oct 2006 23:24
Picon

Re: What has to be rebuilt when a new kernel is used?

>     Glibc depends on Linux Headers which depends on the Linux Release
>     Everything depends on GCC and Glibc.

So if you only recompile Glibc and GCC for the new kernel version,
nothing else needs recompiled?

Eric Stout
Jim Gifford | 1 Oct 2006 23:30

Re: What has to be rebuilt when a new kernel is used?

Dennis Stout wrote:
>>     Glibc depends on Linux Headers which depends on the Linux Release
>>     Everything depends on GCC and Glibc.
>
> So if you only recompile Glibc and GCC for the new kernel version,
> nothing else needs recompiled?
>
> Eric Stout
> _______________________________________________
> Clfs-support mailing list
> Clfs-support <at> lists.cross-lfs.org
> http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-support
In most circumstances no.
Ken Moffat | 2 Oct 2006 01:28
Picon
Favicon

Re: What has to be rebuilt when a new kernel is used?

On Sun, Oct 01, 2006 at 01:24:12PM -0800, Dennis Stout wrote:
> 
> So if you only recompile Glibc and GCC for the new kernel version,
> nothing else needs recompiled?
> 
 Most people using LFS-based systems would NOT upgrade glibc in
place (if you really need a new glibc, it's time to rebuild the
system).  Yes, I know some people have upgraded 2.3 across point
releases, but I never saw a reason to try that.

 If all you really want to do is upgrade the kernel, keep the
existing glibc (even though it was built against old headers) and
the existing headers.  You might occasionally need to upgrade
something else - recently, udev has been a favourite for requiring
newer versions (and then newer bootscripts), but that is deprecated
if Linus or akpm spot it.

 Of course, if a new kernel has a new interface, it won't be usable
unless you rebuild glibc.  But, that assumes that glibc knows how to
use it - the normal pattern seems to be to put the interface in the
kernel, then make glibc-CVS know about it (mainly because until the
interface _is_ in the kernel, the details could change).  So, a
stable version of glibc that can use the new interface will lag
behind the kernel.

Ken
--

-- 
das eine Mal als Tragödie, das andere Mal als Farce
Dennis J Perkins | 2 Oct 2006 01:49
Favicon

Re: What has to be rebuilt when a new kernel is used?

On Mon, 2006-10-02 at 00:28 +0100, Ken Moffat wrote:
> On Sun, Oct 01, 2006 at 01:24:12PM -0800, Dennis Stout wrote:
> > 
> > So if you only recompile Glibc and GCC for the new kernel version,
> > nothing else needs recompiled?
> > 
>  Most people using LFS-based systems would NOT upgrade glibc in
> place (if you really need a new glibc, it's time to rebuild the
> system).  Yes, I know some people have upgraded 2.3 across point
> releases, but I never saw a reason to try that.
> 

I suppose that if you want to replace glibc without rebuilding the
system, the safest way would be to do it the same way a package manager
(RPM or dpkg) would do it.  If I recall correctly, the glibc FAQ warns
against doing "make install" on a running system.

  I haven't thought about what would be required, or the risks of
something breaking.  I think I still prefer to build a new system.
Dennis Stout | 2 Oct 2006 01:58
Picon

Re: What has to be rebuilt when a new kernel is used?

>  Most people using LFS-based systems would NOT upgrade glibc in
> place (if you really need a new glibc, it's time to rebuild the
> system).  Yes, I know some people have upgraded 2.3 across point
> releases, but I never saw a reason to try that.

I appreciate the answer, but I was concerned with only upgrading the
kernel, and simply recompling glibc against the newer kernel; keeping
the same version.

This of course only really applies if the newer kernel doesn't require
a new version of glibc.  In my expereince though, there has never been
a shiney enough new feature in a kernel to make reinstallation of an
OS worth the effort.

But maybe I'm just lazy :)

Eric
Rob Landley | 2 Oct 2006 02:54

Re: What has to be rebuilt when a new kernel is used?

On Sunday 01 October 2006 7:49 pm, Dennis J Perkins wrote:
> I suppose that if you want to replace glibc without rebuilding the
> system, the safest way would be to do it the same way a package manager
> (RPM or dpkg) would do it.

I.E. replace it atomically with "mv".  Whatever you do, don't truncate and 
overwrite the existing file, or all the executables that currently have it 
mmaped (including init) are likely to segfault as the data changes out from 
under them.  (Deleting the old version just leaves it as a detached inode 
until the applications using it exit, that's fine.  The space doesn't get 
freed up until it's no longer being used, but that's actually what you want.)

Rob
--

-- 
Never bet against the cheap plastic solution.
Brandon Peirce | 4 Oct 2006 19:12
Picon
Favicon

Advice needed: Which CLFS for various Intel/AMD archs?

Hi,

I have experience with building software on Linux system but 
cross-compilation
is a new frontier for me.  I would like to achieve two things and I could 
use some
advice.

My starting host platform is i686-pc-linux-gnu running on an amd64 
processor.
The one goal is to "upgrade to 64-bit" and the other is to build i486/i586 
for
some old machines lying around in the garage.

For the "64-bit upgrade", I guess I have to choose one of the two x86_64
Clfs books. Is the multilib build significantly more complicated for a 
cross-
compiling newbie? Is the "pure 64" system significantly more limited in 
everyday
use (difficulties compiling CBLFS packages, binary-only packages not 
available)?

For the i{4,5}86 build, I guess I have to use the Intel/AMD x86 book.  Is 
that
the same whether I start from i686 or x86_64?  (I guess that's another way 
of
saying I'm not clear whether the choice of book depends solely on the target
or is determined by the host?).  Alternatively, is it really 
necessary/easier to
do a CLFS build for that, or could I better just hack my way through a 
(Continue reading)

Ken Moffat | 4 Oct 2006 20:52
Picon
Favicon

Re: Advice needed: Which CLFS for various Intel/AMD archs?

On Wed, Oct 04, 2006 at 07:12:49PM +0200, Brandon Peirce wrote:
> 
> For the "64-bit upgrade", I guess I have to choose one of the two x86_64
> Clfs books. Is the multilib build significantly more complicated for a 
> cross-
> compiling newbie? Is the "pure 64" system significantly more limited in 
> everyday
> use (difficulties compiling CBLFS packages, binary-only packages not 
> available)?
> 

 Hi Brandon,

 as one of the proponents of pure64, I regard it as easier ;)  For
people who compile most things from source, it means you don't have
to care if a package is going to install into /lib or /lib64 [ no
longer quite true, the version of popt in BLFS likes lib64 on
certain 64-bit arches - but then the same is true if you build it as
32-bit on multilib! ].

 In general, both pure64 and multilib on x86_64 will need attention
in the same packages (typically, update config.guess and config.sub,
sometimes pass -fPIC).  However, there is probably a little more
breakage in pure64 (I've seen it in the past in abiword, I'm possibly
seeing it at the moment in audacious and somewhere in the printing
function, but that remains to be debugged).

 Certainly, you won't find binaries for pure64.  AFAIK for clfs this
mostly only affects browser plugins (flash, java, realplayer, ...) and
perhaps some proprietary codecs (if you had other proprietary apps,
(Continue reading)

Ken Moffat | 4 Oct 2006 22:31
Picon
Favicon

Re: Advice needed: Which CLFS for various Intel/AMD archs?

On Wed, Oct 04, 2006 at 07:52:18PM +0100, Ken Moffat wrote:
> However, there is probably a little more
> breakage in pure64 (I've seen it in the past in abiword, I'm possibly
> seeing it at the moment in audacious and somewhere in the printing
> function, but that remains to be debugged).
> 
 Bad choice of words there - I don't mean printing in abiword, I
mean somewhere in the cups - ghostscript - gutenprint stack, and for
the moment I think it's probably something I'm doing wrong.  But,  I
can print from another machine, so it isn't urgent.

Ken
--

-- 
das eine Mal als Tragödie, das andere Mal als Farce

Gmane