The suppress_hostname patch in BLFS broke with the new
suppress_uptime_kill_su patch which prompted me to see why. The reason
was obvious and the workaround simple, but while looking through the new
patch, I realized it was extremely bloated. The -2 patch in the book is
272 lines long (counting the
The attached patch does the following:
* Kills the words "hotplug event". These things are officially renamed to
"uevents".
* Kills "udev". There is no such command anymore, but
it is still appropriate to refer to the "Udev" package.
* Moves the text about obsolete module alias documentation
Archaic wrote:
The suppress_hostname patch in BLFS broke with the new
suppress_uptime_kill_su patch which prompted me to see why. The reason
was obvious and the workaround simple, but while looking through the new
patch, I realized it was extremely bloated. The -2 patch in the book is
272 lines l
I have lost the thread for this topic so I will reply to my own posting..
You bring up a good point: I should have mentioned that I built the
glibc flavor. I wonder if this could be a glibc issue? That would
cause havoc when the kernel tries to run init, I assume - but would it
cause a kern
Hi all,
In the GCC-4.0.3 Chapter 6 instructions it tells you to repeat the
sanity checks done earlier in the Toolchain Adjustment section.
The toolchain adjustment sanity checks have changed recently, and
though they pass with exactly what the book says in the toolchain
adjustment, during GCC the
On 3/22/06, Chris Staub <[EMAIL PROTECTED]> wrote:
> Archaic wrote:
> > The attached patch is only 62
> > lines long (also counting the header). The size difference is 14 kB
> > versus 3.1 kB.
>
> I don't know about Makefile.in, but the coreutils build checks the
> README and AUTHORS files to gener
On Wed, Mar 22, 2006 at 10:06:25AM -0500, Chris Staub wrote:
>
> I don't know about Makefile.in, but the coreutils build checks the
> README and AUTHORS files to generate the list of programs to build.
> AFAICT they *do* need to be changed, counterintuitive as that may seem...
Looks like we are
On Wed, Mar 22, 2006 at 09:55:59AM -0700, Archaic wrote:
>
> I'll investigate further and see if it is even worth continuing.
That that would be a negative. Not worth the bother, though there are
still large chunks of bloat in the patch, the grep and other butchery is
still needed.
Now if only I
On 3/22/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
>
> I believe this needs to be annotated somehow as it is very confusing.
> It works during one time and not the other. Specifically the crt.*
> stuff is different and nothing is returned when doing it after the
> GCC installation.
There were a
Hi all,
The Man-DB instructions don't mention a test suite at all. This
seems out of the ordinary as I'm used to seeing either a note to
run the tests, or that there are no tests.
Perhaps this was overlooked when the Man-DB page was put in.
--
Randy
rmlscsi: [GNU ld version 2.15.94.0.2 2004122
DJ Lucas wrote:
Ran into difficulties tonight. Need to protect against kernel types
that conflict with glibc in linux/types.h.
From llh:
#include
#include
#include
#ifndef __KERNEL_STRICT_NAMES
typedef __u32 __kernel_dev_t;
#if defined(WANT_KERNEL_TYPES) || !defined(__GLIBC__)
typed
Hi all,
Noted in the book that the Groff package creates a zsoelim file
in /usr/bin (which is a symlink), and is described in the "installed
programs" section.
A little bit later, Man-DB comes along and trumps this file with
another, and it is not reflected in the "installed programs". Could
this
DJ Lucas wrote:
> Ran into difficulties tonight. Need to protect against kernel types
> that conflict with glibc in linux/types.h.
I'm not sure what you're trying say in this post. It would help if you
specified the actual problem you are having.
> The quick solution for xorg-server was to
>
Jim Gifford wrote:
I don't see any of these references in sys/types.h, or am I missing something.
Glibc-2.3.6. This may not be an issue at all, see below. Will let you
know tomorrow if I have the time to complete xorg.
---
Greg Schafer wrote:
I'm not sure what you're
DJ Lucas wrote:
Sorry for the noise. Thanks for taking a look. Oh, I also forgot about
the original problem with sys/kd.h. Thanks for the reminder. Should
this be fixed in LFS if continuing with glibc-2.3.6? Xorg is the only
known (to me) issue and it's worked around in BLFS.
BLFS is not
Alexander E. Patrakov wrote:
BLFS is not the right place to work around libc bugs.
Agreed. If someone could cook up a patch for glibc-2.3.6 I'd appreciate it.
Thanks,
Matt.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the
16 matches
Mail list logo
