Matthew Burgess wrote:
* GCC-4.0 - 4.0.0 is currently scheduled for April 15th. There's some
interesting changes for us (like they went and removed our beloved spec
file!) as well as compile and execution time speedups and the usual
bunch of bug fixes. There's also currently issues with
Matthew Burgess wrote:
However, for such a trivial one-liner, I'd
prefer to go with Greg's `sed' (or a variation thereof) - unless he's
going to claim rights over it like he did with a previous effort.
Don't be ridiculous. Last time it was a question of attribution. LFS has a
poor record of
Jeremy Huntwork wrote:
Increased complexity? For x86 - x86, I'm not sure I see it that way.
You have to be kidding, right? Everyone around here has obviously
forgotten what it's like to be a newbie. I'll repeat what I've stated in
the past:
- the greatest thing about LFS is that newbies can
Archaic wrote:
I have found that doing a touch modprobe.conf.5 after unpacking sorts it
out, without need for any arguments to make.
Yes. Been doing it that way for months in the DIY build. It's clearly the
correct fix.
Regards
Greg
--
http://www.diy-linux.org/
--
Tushar Teredesai wrote:
I stumbled across this message
http://lists.gnu.org/archive/html/bug-grep/2004-12/msg00064.html
from the Grep maintainer. It seems that we should not be using the
above configure option.
Yes. As mentioned in the original plfs hint the reason for using the
included
Bruce Dubbs wrote:
Victor Nilsson wrote:
In Gentoo bash reads /etc/bash/bashrc when it's started as non-login
shell, which can prevent a clean environment from being created (the
default file however is only used for settings PS1).
I wonder if they changed the bash man page too? Look
Hi
I haven't seen this mentioned on the LFS lists so I'm bringing it up here
for your info.. LFS is certainly affected.
2.6.12 kernel introduced a new feature called address space randomization
and it's switched on by default. AFAICT, this is the same thing that Red Hat
calls
jim wrote:
Author: jim
Date: 2005-07-22 21:07:35 -0600 (Fri, 22 Jul 2005) New Revision: 6572
Log:
[EMAIL PROTECTED]: jim | 2005-07-22 20:06:43 -0700 This changes the build
method in cross-tools.
It removes glibc-headers from all architectures except for x86 and
x86_64. It changes
Randy McMurchy wrote:
Tushar Teredesai wrote these words on 07/23/05 19:38 CST:
On 7/23/05, Greg Schafer [EMAIL PROTECTED] wrote:
Where is the development happening? I do not see it happening on the LFS
lists.
I think the development happens on IRC coz I have not seen any major
discussion
Randy McMurchy wrote:
There is merit to the school of thought that the cross-lfs branch
is open for whatever changes as it is just a branch right now, and
doesn't necessarily need to be discussed here.
I initially shared those thoughts, but on reflection I do not buy into
that argument at
Jim Gifford wrote:
Randy McMurchy wrote:
Seems like just a day or so ago Jim was saying that the book is now
ready for the wordsmiths.
It still is, but everyone seems to be interested in the next release of
LFS 6. So I made a change on my own, which is a positive change for the
book.
Say
Jim Gifford wrote:
I've been working on this for over a year Greg, you a few weeks.
A few months actually. And in those few months I've managed to come up
with a sane cross build method... something that the punters should
hopefully be able to understand. Many folks here have said they do not
Hi
Following on from recent goodwill discussions with Matt, here is another
issue I'm bringing here for your attention.
The Grub page in LFS says this:
Note that the test results will always show the error ufs2_stage1_5 is too
big. This is due to a compiler issue, but can be ignored unless you
Jeremy Huntwork wrote:
What evidence?
Surely I don't need to point out how easy it is to determine who is
accessing what and when and where from, using apache logs, ip addresses,
dns, etc etc etc?
Secondly you say that you made those changes in the diy cross build as a
result of your
Justin R. Knierim wrote:
Examples please? Just showing us vague changelog messages and saying
you researched that is not very convincing.
Justin, with all due respect, and this is not directed specifically at
you, but it appears there is still a tendency within LFS for folks to jump
into
DJ Lucas wrote:
Well it looks easy enough to fix. Is it as simple as I think it
isreplacing the fopen to point at the different filename...better if
the open call to exec-shield-randomize fails, then go for
randomize_va_space...assuming the data contained in each is the same.
Or check
Ryan Oliver wrote:
Now a few comments after reading this thread...
1) I support what Jim has done (though I haven't had time to test it),
anything that removes a pile of builds is a good thing for lfs.
Excellent.
2) Please all, enough with the attitude. We are all working towards the
same
Randy McMurchy wrote:
That said, I have always respected your ideas, though often I've
thought your delivery was less-than-stellar.
Like it or lump it :-)
You made a recent post
which said that Jim's latest mass-change had some technical issues,
but you didn't discuss the reasons why you
Jeremy Huntwork wrote:
I understand what the proposal was about. You mentioned the possibility
of some of the host tools not being able to produce verbosity as
expected, with the specific example of mkdir. That led me to wonder how
often we currently use mkdir and so I branched...
Oops.
Hi
Seeking feedback from anyone who is knowledgable about Shadow Group Support.
Is it actually used much in the wild?
How useful really is it?
Should the shadow pkg have it switched on by default?
The reason I ask - the latest shadow-4.0.11.1 has revamped the autoconfigury
to allow
Randy McMurchy wrote:
[snip highly technical and best as I can figure, well-reasoned analysis]
Thanks, Greg. I am interested in hearing from the pro-remove-headers
folks in response to your message.
Hopefully, there will be continued discussion. This type of discussion
is, after all,
Jim Gifford wrote:
So as you can see, yes I did look at Greg's scripts, but I did not use
them. What I don't understand here Greg is why you can say I stole your
work and didn't give you credit,
Jim, never once have I used the word stolen. The changes you made to the
LFS Cross build made it
Tushar Teredesai wrote:
This is a very valid point IMO.
No, it is completely invalid. See below.
Since the cross-LFS will most probably
have the official LFS blessing,
Have you even looked at it? Let alone tried it? It has a long way to go.
I would like it to have proper
attribution. If
Jim Gifford wrote:
Not until a formal apology is posted. I want my name and LFS's name
cleared of the allegations you brought up. I WILL NOT back down on this
point.
Tough.
The facts speak for themselves, and you know it. I do not care anymore. If
you want to act like a 12 year old, go for
DJ Lucas wrote:
TY, even if LFS doesn't use it, it'll probably be needed in BLFS at some
point. Will dig in and play after BLFS-6.1 release.
Should be no need now. Upstream are onto it. See here:
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg02072.html
This should hopefully go onto the 3.4
Randy McMurchy wrote:
I'm just about finished building the GCC4 branch of LFS which is
(I believe) trunk using GCC-4.0.1. Everyone is by now aware that
there will be difficulties with some BLFS packages using GCC-4.x.
I am going to begin building BLFS packages using GCC-4.0.1 and I'm
Hi
Matt, as maintainer of the GCC4 branch you should be aware of an issue
affecting the GCC4 build on x86. Some folks may consider this minor but I
believe it is important.
The issue arises as a side effect of the build method. To be precise, only
GCC Pass1 is run as `make bootstrap'. The other
Greg Schafer wrote:
This should hopefully go onto the 3.4 branch soon.. which of course
means it'll be in 3.4.5. We can always backport it to 3.4.4 if
deemed necessary.
Here is the final patch as committed:
http://gcc.gnu.org/ml/gcc-cvs/2005-08/msg00052.html
In summary, if you need
Jeremy Huntwork wrote:
In any case, what would be the difference between what you're trying to
accomplish with a sed and the results of something like:
make CFLAGS=-g -O2 -fomit-frame-pointer
Still curious about the difference of the sed vs. the above command...
Yes, that was how I
Matthew Burgess wrote:
I assume they've fixed all the problems with -fomit-frame-pointer?
What problems? In the past some software certainly broke with it, but I'm
not sure where the blame lied.
But that is orthogonal to this discussion anyway. The GCC devs believe
that compiling GCC-4.x
steve crosby wrote:
Just a heads up - util-linux 2.13 will remove several items, as per
the following changelog entry for pre1
Changes:
GNU autoconf/automake/libtool are now used for building.
Yay! However, the autoconfigury in this pre1 release is busted. Most of
the --enable-xxx and
Greg Schafer wrote:
- `setfdprm' is gone, yet `/etc/fdprm' is still installed. This looks
like a bug methinks.
- these symlinks are installed in /sbin all pointing to `initctl':
`display-services' `need' `provide'. Bug? Prolly.
- these symlinks are installed in /sbin all
Matthew Burgess wrote:
Move programs that the bootscripts require to /bin:
mv /usr/bin/{head,sleep} /bin
`head' does not belong in /bin IMHO. Red Hat and Debian both agree with
me. Surely `sed' can provide the same functionality for the bootscripts.
That then leaves us with the following
Hi
The /bin/compress symlink (pointing to gzip) was added to allow newer tar's
auto-detection of compressed archives to work on `.Z' archives.
This is technically incorrect IMHO.
Now, if you type in:
compress filename
you end up with a filename with a `.gz' extension instead of the expected
Hi
During the toolchain adjustments, LFS does stuff like this:
gcc --print-file specs
IMHO the usage is bogus because:
1) `--print-file' is undocumented (therefore could break anytime)
2) `--print-file' only works by pure good fortune. Don't believe me? Try
this with a GCC-3.4.x:
Matthew Burgess wrote:
Therefore, in order to change GCC's default specs file, I still think we
need to 1) dump them (as gcc-4.x no longer installs a specs file) 2)
change the relevant specs and 3) Place the updated specs file in
whatever directory GCC searches for its default specs in.
Matthew Burgess wrote:
Greg Schafer wrote:
The documented switch is:
-print-file-name=
However, the docs say it is only for library, but it appears to work for
any file or dir within GCC's private dir eg: specs, startfiles,
Doesn't appear to do what we need it to do though
Randy McMurchy wrote:
I am *not* in the class of individuals you mention above. Those guys
are experts. I, however, don't know shit about GCC internals. :-)
Me is no toolchain expert. Those folks who write the toolchain code are
the real experts. But I'll say my piece anyway :-)
I cannot
Hi
The explanation in Ch 5 Binutils Pass1 for --disable-nls says:
This disables internationalization as i18n is not needed for the temporary
tools.
This is misleading because only the Pass1's of Binutils and GCC are passed
`--disable-nls'. For the statement to be accurate, `--disable-nls' would
Archaic wrote:
On Wed, Aug 24, 2005 at 12:13:07PM +1000, Greg Schafer wrote:
This disables internationalization as i18n is not needed for the temporary
tools.
This is an accurate statement.
True.
But it's not accurate in the context I described. If it's to stay it
should at least
Alexander E. Patrakov wrote:
No, it was added deliberately in order to avoid binutils dependency on
the host gettext.
So Binutils won't build with NLS if Gettext is missing on the host?
Hmmm, interesting. Is this a FSF or HJL thing or both? I've just noticed
that Binutils-pass2 also has
Ken Moffat wrote:
Committed to patches as inetutils-1.4.2-gcc4_fixes-2.patch in r1076,
but I can't test it at the moment (hardware problems) so I'm not
updating the book.
It tests out fine here. I've also sent a pointer to the patch upstream and
already received a reply back that a
Greg Schafer wrote:
I've also sent a pointer to the patch upstream and
already received a reply back that a slightly different patch has been
committed.. but I haven't tested the new one yet..
http://lists.gnu.org/archive/html/commit-inetutils/2005-08/msg7.html
Works fine.
Regards
Greg
Jeremy Huntwork wrote:
I'm only guessing here, but..
read(3, \353H\220\320\274\0|\373P\7P\37\374\276\33|\277\33\6PW..., 512) =
512
ioctl(3, 0x301, 0xbfd12110) = 0
It seems the above is a read of the 1st 512 bytes of /dev/hda ie: the MBR.
The next few reads appears to be the
Greg Schafer wrote:
_llseek(3, 1028225536, [1028225536], SEEK_SET) = 0
read(3, ReIsEr4\0\0\0\0\0\0\0\0\0\0\0\0\20\2725\3511\237\246M\204...,
1024) = 1024
Here is a completely untested patch. Someone wanna try it? It's based on
previous problems we had with sfdisk and GCC-3.4.x
It's a long
On Sat, 03 Sep 2005 10:37:30 +0200, Jürg Billeter wrote:
Ok, it's not a gcc bug at all... The SEGV seems to have destroyed some
debug info on the stack and that's the reason gdb didn't help. The
problem occured on all systems with linux partitions that don't have a
ext2/ext3, xfs, or jfs
Jeremy Huntwork wrote:
Jürg Billeter wrote:
Ok, it's not a gcc bug at all... The SEGV seems to have destroyed some
debug info on the stack and that's the reason gdb didn't help. The
problem occured on all systems with linux partitions that don't have a
ext2/ext3, xfs, or jfs filesystem as
Jürg Billeter wrote:
The patch speaks for itself,
BTW, changing the problematic line to:
read(fd, reiserfsb, sizeof(reiserfsb)) == sizeof(reiserfsb)
seems to also fix the problem. It's simpler and is more in line with the
other filesystem checks in that function. Maybe the above variant is
Tushar Teredesai wrote:
The patch can be replaced by a sed (this is from memory so may need to
be adjusted):
sed -i '[EMAIL PROTECTED](SHELL) ./[EMAIL PROTECTED]@g'
gcc/fixincludes/Makefile.in
I wonder where you got the idea for that from :-)
For the record, here is what I've been using
Alexander E. Patrakov wrote:
5) Blacklist Fedora Core 4 since it can't build binutils.
Huh? Stable or development LFS? Could you please supply details of the
problem? Does passing --disable-werror help? Or maybe we just need to add
the required GCC4 patches to the Binutils version used in
Alexander E. Patrakov wrote:
The problem is only with non-LFS hosts that define
NONINTERACTIVE_LOGIN_SHELLS. Since the lfs user never logs in using an
interactive shell, his .bash_profile is never used on normal hosts and
(as already mentioned) only causes damage on strange hosts.
Last
Doug Ronne wrote:
I can't get used to vim, and use emacs. So my host system has emacs.
I only once managed to hack the gettext configure to not believe emacs
existed, so it always tries to compile lisp support or some such and
always fails if I don't have emacs in my toolchain, but do have
On Tue, 13 Dec 2005 22:18:50 -0600, Bruce Dubbs wrote:
I just ran into a minor problem on a new install. I was installing the
Java runtime and the included script had:
tail +122 ...
I had to change it to tail -n +122 ...
I thought this POSIX behavior was reverted in the current
Hi
Interesting thread :-/
First up, ICA is not the be all and end all. It's just another tool in the
armory in ensuring a good build. And it's not perfect either..
It's amazing how such a simple concept can apparently be troublesome for
some folks to grasp. I was hoping my scripts would have
Matthew Burgess wrote:
What I have trouble understanding is the fact that, apparently, one
shouldn't reboot during the ICA cycle. What I thought was trying to be
proved here was that a) any suitable host can build LFS
No. IMHO what you refer to there is bootstrapability ie: the ability to
On Wed, 21 Dec 2005 11:34:22 -0800, Jim Gifford wrote:
I posted a solution in lfs-support. Here is it
In my testing with Cross-LFS, I have found that this works
echo dummy1:x:1000: /etc/group
echo dummy:x:1000:1000:::/bin/bash /etc/passwd
cd tests
su dummy -c sh run-all
sed -i
Ken Moffat wrote:
'su' from /tools. Neither CLFS nor LFS suppress this in the first
build of coreutils.
WARNING: insufficient access; not installing su
NOTE: to install su, run 'make install-root' as root
The temporary tools are (meant to be) built as non-root.
Regards
Greg
--
Tushar Teredesai wrote:
Additionally, the libgcc_s.so symlink is not needed. Only the
libgcc_s.so.1 is needed so that glibc can dlopen that library (used in
nptl).
Are you sure? The libgcc_s.so symlink became necessary when LFS adopted
the startfile_prefix_spec hackery in the toolchain
Dan Nicholson wrote:
OK, round 2 here. I made a couple changes, some of which were just
guesses and haven't affected anything. bison, perl, vim, nscd are
still causing problems.
Looks pretty good. I'm pretty sure you'll find perl, vim and nscd are
different due to timestamps embedded into
Tushar Teredesai wrote:
It found the libgcc_s in
/tools/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../libgcc_s.so.
snip
Confirmed. Though it did come as a surprise. When I tried the test
that you mentioned, it found the glibc libraries in /tools/lib, not in
/usr/lib. I checked the command that
Author: ken
Date: 2006-01-07 15:12:20 -0700 (Sat, 07 Jan 2006)
New Revision: 7256
Modified:
trunk/BOOK/chapter01/changelog.xml
trunk/BOOK/chapter06/chapter06.xml
Log:
Build mktemp earlier, for gcc's gccbug which now wraps mktemp in 'if [ yes =
yes ];' instead of 'if [ no = yes
Ken Moffat wrote:
I'm not sure I fully understand your point, you seem to be saying that
gcc might be at risk from mktemp ?
Sorry, I guess I wasn't quite clear. What you've done is make a build
order change by inserting a questionable package smack-bang in the middle
of the toolchain
Greg Schafer wrote:
/* Define to 1 to internationalize bison runtime messages. */
-/* #undef YYENABLE_NLS */
+#define YYENABLE_NLS 1
Bingo! This looks like the culprit.
snip
I'll try and figure out a good fix tomorrow..
Hmmm, AFAICS there is no easy way to fool configure into doing
Ken Moffat wrote:
But certainly, you'll probably want r7257 (move grep before libtool) to
fix a hardcoded '/tools' in the libtool script.
Yes, this is new as of libtool-1.5.22. I only noticed this yesterday
myself in my latest ICA run. The problem is triggered because the latest
libtool
Jim Gifford wrote:
I think we all have come to realization that LLH headers are not coming
out.
?? Speak for yourself! :-) And why the impatience anyway? It seems some
folks around here think the l-l-h version needs to match the current
kernel release version. This is simply not true! Yes,
Rainer.wirtz wrote:
Is it just me or is expect completely broken?
This may be unrelated, but please note there has been a screwup at the
upstream tarball site. My upstream tarball detector script found this:
- [BIN] expect-5.43.0.tar.gz 08-Feb-2005 16:45 513K
+ [BIN] expect-5.43.0.tar.gz
saving the /tools directory to the beginning of
chapter 6.
Fixes bug 1677. Thanks to Chris Staub, Alexander Patrakov, Greg Schafer and
Tushar Teredesai for reporting and resolving this issue.
Temporary wrapper scripts? Hmmm, these are interesting changes to say the
least. They look completely
Jeremy Huntwork wrote:
Greg Schafer wrote:
Temporary wrapper scripts? Hmmm, these are interesting changes to say the
least. They look completely bogus. You actually tested this stuff before
committing? Where is the enhanced sanity check needed to verify this
crucial stage of the build method
On Thu, 26 Jan 2006 07:47:51 -0800, Dan Nicholson wrote:
I think this has been known for a long time. If this was wrong, why
wasn't there any noise by the Toolchain Maintainer?
Ryan, if you're reading this you'll be honest with yourself and realize
I'm not flaming!
This is not meant as a
Jeremy Huntwork wrote:
There is a bug open to remove this feature from gcc. But, it is a year
old now and still open.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19353
Not exactly. That bug report is about startfile_prefix_spec being a faulty
spec. It coincidentally highlighted the fact
Jeremy Huntwork wrote:
Obviously '-B' works for you, and obviously, Ryan's methods work for
him. Is there a 'best for LFS' in all of that?
When in doubt, play the multilib card! :-)
But seriously, I dunno. I fail to see how you can equate the 2. Comparing
cross compilation to native
Greg Schafer wrote:
Personally, I don't believe in it and will never use it because:
- the spec is faulty. It doesn't work when placed into an external file
for use by gcc -specs=... (luckily LFS is not using it externally).
Every other spec I've tried works properly when placed
Ryan Oliver wrote:
When you are doing an old style cross-toolchain build
Nobody sane uses old style cross-toolchain build procedures these days :-)
(ie: not using a sysroot, all target libraries and includes installed
under /prefix/target/lib /prefix/target/lib64
Alexander E. Patrakov wrote:
The problem is that any header
in /usr/include but not in /tools/include will be found as existing by
Perl Configure script, thus leaking unwanted influence from the host to
Chapter 5 Perl. While nobody reported a failed compilation because of
that, it is
Dan Nicholson wrote:
After looking over Configure for a while, I would suggest this
sed -i 's,/usr/include,/tools/include,g' Configure
Hmmm, yes it should work. But I believe hints/linux.sh is the place to
sort this stuff out. I just tried adding:
usrinc=${prefix}/include
to hints/linux.sh
Jeremy Huntwork wrote:
In talking with Ryan Oliver, there seems to be one final thing that we
can do to our current build which will help stabilize it completely: add
'make bootstrap' to the gcc build of chapter 6.
Hm, this means you effectively end up building GCC 7 times, 3 times in
Jeremy Huntwork wrote:
The benefits of this is that, after it builds its stage 1 xgcc, even if
there are inconsistencies in the chapter 5 toolchain, gcc will always
find and use the correct binutils in /usr. Also it will build itself
using the same configuration the final product will
Alexander E. Patrakov wrote:
some tme ago I imported from DIY linux the statement that none of the
locales are really required. As it stands now, this statement is wrong.
When checking whether the ctype macros accept non-ascii characters, Bash
configure script attempts to set the
Dan Nicholson wrote:
It appears that binutils ld will be changing its search behavior to
more closely follow ld.so. See this post:
http://sources.redhat.com/ml/binutils/2006-02/msg00127.html
It seems that rather than using the compiled in LIB_PATH that we make
use of in Ch. 5 to repoint
matthew wrote:
Author: matthew
Date: 2006-02-19 13:31:54 -0700 (Sun, 19 Feb 2006)
New Revision: 7381
Modified:
trunk/BOOK/chapter01/changelog.xml
trunk/BOOK/chapter01/whatsnew.xml
trunk/BOOK/chapter03/packages.xml
trunk/BOOK/chapter06/sed.xml
trunk/BOOK/general.ent
Log:
Dan Nicholson wrote:
I don't know much about the subject either, Chris. Here's the thread
for the original flame war that resulted in that wording, though:
http://linuxfromscratch.org/pipermail/lfs-dev/2003-October/039106.html
Maybe someone who understands the uses of SysV shared memory
Matthew Burgess wrote:
As regards to LFS unstable living up to its name, that's probably
because we chose the right name for it, i.e. we don't try and pretend
that it's something it isn't. I don't see why you thought a :-( was
necessary. Yes, testing could have been more thorough, but
archaic wrote:
Author: archaic
Date: 2006-02-27 18:26:57 -0700 (Mon, 27 Feb 2006)
New Revision: 7398
Modified:
trunk/BOOK/chapter01/changelog.xml
trunk/BOOK/general.ent
trunk/BOOK/patches.ent
Log:
New bash fixes patch adds patch 011 from Bash upstream.
The patch is wrong.
Alexander E. Patrakov wrote:
DJ Lucas wrote:
Another very minor point is trying to find a way to rip out all the
__KERNEL__ portions
That's what the unifdef tool in FreeBSD does. It also works in Linux.
http://www.cs.cmu.edu/~ajw/public/dist/unifdef-1.0.tar.gz
Note: Debian uses a
Tushar Teredesai wrote:
Gentoo is using a script similar to the above script to sanitize the
headers.
Do you have a pointer? Thanks.
Regards
Greg
--
http://www.diy-linux.org/
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See
Tushar Teredesai wrote:
The kernel-2.eclass file at
http://www.gentoo.org/cgi-bin/viewcvs.cgi/eclass/?hideattic=1 has
the gory details on how gentoo creates the headers. It has lot of
extra functions since the same elcass is also used for kernel
compilation.
Ok, thanks. Tho' I had managed
Alexander E. Patrakov wrote:
__iomem removal is not questionable at all. This macro indicates that
this is not a valid pointer that you can dereference directly, but a
cookie that you can pass to the ioremap() in-kernel function in order to
access the hardware via the MMIO mechanism. This
Bryan Kadzban wrote:
Not quite true anymore; 2.6.16 also includes some new syscalls (openat
and friends) that will (may? probably will) require changes in the
userspace headers.
Most definitely, if you want them to be used that is :-) Tho' only
Glibc-2.4 and above has support for the new
Jim Gifford wrote:
Just added a compare script. That will compare the difference between the
raw_headers produced with the headers script compared to the headers in
llh.
Jim, I've been working along similar lines. I'm getting the diff down all
the time. I've included some stuff below which
Jürg Billeter wrote:
Yes, LLH fails that criteria and it ships with a lot of kernel-only
stuff. Based on Jim's script I've written an extended version which
removes a lot of headers that shouldn't be part of the linux glibc
header set, AFAICT.
Cool. But one has to ask how you arrived at the
Jürg Billeter wrote:
Very short rationale is given on top of each file group. Detailed
rationale for each header would unfortunately be too time consuming.
Hmmm, that's not ideal. I'm assuming you've looked at each header and used
your judgement to determine whether it should be removed or
Jürg Billeter wrote:
I've also run a script to find used kernel headers over the sources of
the 800 packages (except kernel and headers packages). You can find the
results on http://www.paldo.org/headers/
Wow. Again, excellent work.
* headers-list: Sorted list of all found header
Jürg Billeter wrote:
I know that it's far from ideal but the only ideal way I see would be to
extensively add __KERNEL__ ifdefs to the linux headers upstream so that
the script could recognize automatically which headers are
kernel-internal. Unfortunately this probably won't happen in the
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
Archaic wrote:
or better yet, does anyone see a need to include the new syscalls?
I'm surprised this question has been asked. It's Glibc FAQ material:
http://sources.redhat.com/glibc/glibc-faq.html#s-1.8
And for an explanation with more details, pls see here:
Dan Nicholson wrote:
So, --with-sysroot is only needed while building the toolchain? It
looks like the only other trick is using DESTDIR to get the install to
go to the right spot. I imagine perl is causing all kind of
nightmares.
This looks awesome. Not to bash the work being done for
Bryan Kadzban wrote:
Hmm; it looks like unifdef is not included in the kernel tree. We're
going to have to add this to chapter 5. (Actually we'll have to build
it just before the kernel headers install in chapter 5; then we might as
well just use the version from /tools in chapter 6 also.)
Author: matthew
Date: 2006-10-04 10:40:23 -0600 (Wed, 04 Oct 2006)
New Revision: 7807
Upgrade to Coreutils-6.3
Modified: trunk/BOOK/chapter06/chapter06.xml
===
--- trunk/BOOK/chapter06/chapter06.xml2006-09-29 01:48:55
On Wed, Oct 25, 2006 at 10:03:16AM +0600, Alexander E. Patrakov wrote:
if the user includes -Os in his CFLAGS, binutils tests in LFS-6.2 will
show 21 failures (visibility and shared tests). 18 of them don't
show up if the binutils-2.17-ppc64_fix_testsuite-1.patch testsuite fix
...
Jeremy Huntwork wrote:
So, I'm not sure where this leaves us.
Exactly where you were before. Nothing has changed.
The bug does still seem to exist
in expect, but, at least currently, the test-suites that make use of
expect seem unaffected by the inclusion or absence of the patch.
No.
1 - 100 of 229 matches
Mail list logo
