On Mon, 27 Aug 2012 05:20:39 +0100, Jasmine Iwanek wrote:
I'll have a poke at building glibc with no host headers shortly to see
what other headers get pulled in, if nothing else it'll keep Greg quiet
Fat chance of that :-)
Anyway, my immediate concerns have been allayed because it turns out
On Sat, 25 Aug 2012 21:59:04 +0100, Jasmine Iwanek wrote:
Actually, when I copied in rpc/types.h, I put it in /usr/include/rpc and
that made the ch5-glibc build happy
Um, doesn't anyone see the obvious problem here?
The cross toolchain is apparently finding stuff on the host. The whole
point
On Fri, 16 Mar 2012 22:29:29 -0400, Jeremy Huntwork wrote:
Greg, there's no need to make this personal.
No worries dude. Not trying to cause trouble so my apologies if you've
taken any offence. I just tend to get passionate about build method
matters.
It was mostly reading those (and bits
On Wed, 14 Mar 2012 20:32:36 -0700, Bryan Kadzban wrote:
It seems that Greg never got the time to comment any more thoroughly on
the modifications, either. I'd kinda like to hear what he has to say,
Well, I've been doing a lot of reading in order to get back up-to-speed.
One of the reasons I
On Thu, 01 Mar 2012 16:27:31 -0500, Jeremy Huntwork wrote:
And that's it. It's cleaner, more direct, and more closely tracks what
upstream has provided.
I'm sorry to say this but your whole premise is based on hearsay and
personal opinion.
Instead of vague assertions about upstream
On Mon, 27 Feb 2012 22:49:07 -0500, Jeremy Huntwork wrote:
The main differences (I'll outline all of them shortly) are the
pre-adjusting of gcc in pass 1 along with the use of sysroot and newlib.
I'm so far out of touch I don't have the energy to shoot this down.
For the record, I don't agree
On Tue, 02 Feb 2010 07:15:38 +, Greg Schafer wrote:
On Mon, 01 Feb 2010 23:00:57 +, Matthew Burgess wrote:
What's your recommendation then? Pass '-j1' on the command line for all
'make install' invocations?
That's probably overkill. All I know is I've previously been burnt
On Thu, 04 Feb 2010 20:46:58 -0600, Bruce Dubbs wrote:
FAIL: stackoverflow2
===
1 of 5 tests failed
===
I've determined that this is a kernel problem. I was using lfs-6.5 and
the kernel was 2.6.30.2. After booting to 2.6.32.7, this failure went
away.
On Mon, 01 Feb 2010 23:00:41 +0100, Mark Rosenstand wrote:
Much more clever would be to mention MAKEFLAGS in the intro somewhere,
and add -j1 as needed for the packages that don't support parallel make.
Exactly as currently done in DIY Linux.
This is what I do in my build scripts, and out of
On Mon, 01 Feb 2010 23:00:57 +, Matthew Burgess wrote:
What's your recommendation then? Pass '-j1' on the command line for all
'make install' invocations?
That's probably overkill. All I know is I've previously been burnt by
both GCC and Glibc with `-j3' on 2 cores. And considering the
On Mon, 25 Jan 2010 01:39:13 +0100, Jean-Philippe MENGUAL wrote:
what kind of buildings can do a user exactly
with this stable (6.6)? From 64 to 64 bits? From 32 to 32? Or 32 to 64?
Actually, the underlying build method supports all combinations:
32-32
64-64
32-64
64-32[*]
(* the last one
On Thu, 29 Oct 2009 00:48:05 -0500, Bruce Dubbs wrote:
I have updated the book to GRUB-1.97.
Grub2 appears to have a major regression in that installing into the PBR
no longer works. Note - I'm talking about non-MBR installs, ie:
installing Grub into a Partition Boot Record.
I haven't looked
On Mon, 09 Nov 2009 17:36:53 -0600, Bruce Dubbs wrote:
I don't know for sure, but I think that install into a PBR is a
configuration issue.
No, it's definitely a bug (and a regression at that). See these links:
http://ubuntuforums.org/showthread.php?t=1284914
On Thu, 17 Sep 2009 15:31:41 -0600, Matthew Burgess wrote:
On Thu, 17 Sep 2009 16:18:16 -0500, Bruce Dubbs bruce.du...@gmail.com
wrote:
#2412 Add more rationale to Toolchain Technical Notes
Who do we get to advise us on this one?
I'd appreciate it if Greg could help contribute on
On Thu, 17 Sep 2009 16:12:43 -0700, Nathan Coulson wrote:
I have been experimenting with a multilib LFS System (where /lib,
/usr/lib are used for 64bit, and /lib/32, and /usr/lib/32 are used for
32bit).
I advise against this. Not FHS compliant and not what the big distros do.
The toolchain
On Wed, 26 Aug 2009 18:58:53 -0500, Bruce Dubbs wrote:
bdu...@lfs6:/usr/sbin$ ldd grub
linux-gate.so.1 = (0xe000)
libncurses.so.5 = /lib/libncurses.so.5 (0xb7efd000) libc.so.6
= /lib/libc.so.6 (0xb7ddc000) /lib/ld-linux.so.2 (0xb7f59000)
Looks like it needs
On Wed, 26 Aug 2009 17:27:56 -0500, Bruce Dubbs wrote:
From a 64 bit system, we'd need to use cross compile techniques for
these files
so they don't try to use 64-bit addresses.
Umm, what's wrong with installing a 32-bit libc?
It's 1 extra package, it solves the grub problem, and it
On Wed, 26 Aug 2009 18:23:53 -0500, Bruce Dubbs wrote:
A 32-bit libc is a consideration. I don't know how to do that yet.
I lied. It's actually 2 extra packages :-/
One needs to build a 32-bit libc in Ch 5 too (so that GCC can be multilib)
This is all covered in the DIY Refbuild (packages
On Wed, 26 Aug 2009 18:32:28 -0500, William Immendorf wrote:
This has got me thinking: If we are going to build a 32-bit Glibc for
multilib LFS, why don't we do a fully multilib system for 64-bit, like
how CLFS does it?
Because that way lies madness (as has been discussed many times before).
On Wed, 29 Jul 2009 04:07:58 -0600, Matthew Burgess wrote:
On Wed, 29 Jul 2009 01:29:31 -0800, Rabbit rabbit8...@gmail.com wrote:
but I think we should use just only use i686-pc-linux-gnu because I
think it doesn't make sense to use i686-pc-lfs-gnu.
The 'i686-lfs-linux-gnu' came in
On Wed, 15 Apr 2009 14:50:10 -0600, Archaic wrote:
+#define PHOSTNAME /usr/bin/hostname /* How to get the host name */
Side note - FHS says hostname should be /bin/hostname
i.e. it's a bug.
Regards
Greg
--
http://www.diy-linux.org/
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
Hi,
Just stumbled across this. You will likely want to fix it:
http://lists.gnu.org/archive/html/m4-patches/2009-02/msg00010.html
Regards
Greg
--
http://www.diy-linux.org/
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the
Jim Gifford wrote:
Again Greg provide us more information about the ICA, it seems to be
your own creation?
1. Read this post from Dan Nicholson:
http://article.gmane.org/gmane.linux.lfs.devel/8120
2. Look at the comments in the gsbuild scripts from DIY
3. Look at the jhalfs
Matthew Burgess wrote:
In which case, all I can suggest is you follow the process yourself:
1) Compile CLFS from a non-CLFS host
2) Use the newly built CLFS to build a second CLFS system (obviously using
exactly the same commands and package versions)
No, that's not quite right. The second
Jeremy Huntwork wrote:
It
is a new approach compared to earlier versions of LFS in that the the
first pass of binutils and gcc we are creating cross compilers and the
chapter 5 glibc is cross compiled. It is a native build from that point
forward.
Some weeks ago, Ryan proposed a
is merely that the author was not Greg Schafer.
Wow, man, you're starting to lose it. Stay focused!
I put this build together *solely to prove a point*
No, you put this build together solely because someone finally came up
with something better then your beloved CLFS. Face it! You would never
Ryan Oliver wrote:
Look back into the clfs-lite that was proposed 4 years ago in the lfs wiki.
Referenced here
http://linuxfromscratch.org/pipermail/lfs-dev/2005-April/051171.html
Vapour.
4 years ago your opinion was markedly different with regards to using
cross-compilers for any part
Jeremy Huntwork wrote:
For those unfamiliar see:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532
For those not interested in reading the entire bug history, the last
comment by a dev was:
Using the sysroot flags is the solution for Greg's scenario. In fact I
would say it makes his
Jeremy Huntwork wrote:
No, sorry, I don't. In the comments of that bug report the dev suggests
using sysroot for pass 1 of gcc.
Yeah, and he also says create $sysroot/usr/include. If you're going to
hang your hat on the word of 1 junior GCC dev...
Also, haven't you noticed that making use
Ryan Oliver wrote:
We all know what sysroot is for.
All sysroot does is shift the search paths underneath the sysroot, no
more, no less.
Well, yes. But Sysroot is specifically for *root* file systems. Here's
another data point from the GCC man/info/web docs:
--sysroot=dir
Use dir as
Ryan Oliver wrote:
The sysroot build is misused in pretty much the same way the original
native plfs toolchain was misused.
Just another data point for the record.
Here, a senior toolchain person confirms how sysroot is meant to be used
(read the whole bug report for context):
Ryan Oliver wrote:
Except you then are placing tools compiled and linked against the host
in the directory that is supposed to be clean.
Huh? I'm grouping *temporary* tools together in the one dir. It's not the
dir that's supposed to be clean. It's the build method.
You unnecessarily
Ryan Oliver wrote:
No, I solve problems for which you have not catered for yet.
CLFS deals with building from non-linux hosts.
Off topic
Isn't your supposed goal technical perfection that us mere LFS mortals
can only aspire to?
Not at all. Get the job done as quickly and efficiently as
Jeremy Huntwork wrote:
I have been adapting Ryan's methods to LFS because I think that there
are certain improvements over what is currently in trunk. Specifically:
A quick glance shows you are bringing in one of CLFS's ugliest design
faults - the bizarre `/cross-tools' prefix. Let me
Jeremy Huntwork wrote:
As far as 'butchering the source' goes, there's nothing done in the
first pass of GCC to the source that isn't done in pass 2. Essentially
it's the same sort of stuff we've _always_ done in pass 2 to ensure that
the compiler uses only the libs and headers in /tools.
Ryan Oliver wrote:
Incorrect. The initial point of installing into a separate directory
And this is documented where? Another CLFS strong point!
Dude, you can blather on all you like. But none of your rhetoric can hide
the fact your builds are as ugly as sin and incomprehensible by mere
Ryan Oliver wrote:
# Sysroot based SANE multilib cross-compiler build for LFS style builds
Heh, this is hilarious. A new and improved build method goes into LFS and
CLFS folks awake from the dead :-) Feeling some pressure guys? :-)
Sorry mate, but this whole thing looks of very poor quality
Author: jim
Log:
Creating of CLFS Native Structure
Well, well, well. What have we here? What happened to the big `C' in CLFS
guys? Changing your name to NLFS?
I've seen some incredible stuff on the *LFS lists over the years but this
appears to be the most breathtaking act of arrogance I've
Ryan Oliver wrote:
Couple of minor things
1: Chapter 6.15 - If you aren't bootstrapping the compiler, you wont be
using the newly created binutils to build your new gcc.
Correct. DIY takes care of this with the `-B/usr/bin/' thing. Whether it
actually matters much is questionable. As per
Jeremy Huntwork wrote:
With revision 8755, the new build method from DIY is in place with the
exception of support for multilib. (More on that in a second.)
No. You've also omitted perhaps the most interesting feature of the whole
thing - the ability to migrate from a 32-bit system to a 64-bit
Jeremy Huntwork wrote:
Knock it off. I don't come to DIY and disparage your work.
Huh? Get over yourself dude. You've *always* taken things so personally.
Grow a thick skin.
Remember I'm trying to support *you* implementing *my* work. Watch your
tone and focus on the task at hand. Thanks.
Jeremy Huntwork wrote:
What do you think is likely to happen in future versions and/or what is
your plan?
GCC is not going to revert back, clearly.
Just continue to maintain the backport patch for future versions?
Pretty much. It's similar in principle to the current specs handling ie:
Jeremy Huntwork wrote:
1. Move to DIY's new build method in trunk. If we ignore multilib and
any extra arch support for this step, the changes required aren't
actually that many, and they all take place pretty early in chapter 5.
I realize you say this step, but LFS is already too far
Jeremy Huntwork wrote:
Greg, as I have your attention, I'm curious why the -fomit-frame-pointer
change is still present in your second pass of gcc. I thought the
purpose of this was to maintain compatibility between the first
bootstrapped pass of gcc and the second pass?
GCC is no longer
jhuntwork wrote:
Initial addition of support for x86_64
???
This is nothing like the new build method at all. It appears you've taken
stuff from the old jh branch, which is now completely outdated because
it's based on the old build method.. Ughh. Not sure where you're going
dude, but this is
Greg Schafer wrote:
In a (native) sysroot scenario, anything and _everything_ can be found
on the host.
Here's a Binutils thread about a sysrooted ld which touches upon what I'm
talking about:
http://sourceware.org/ml/binutils/2008-08/msg00060.html
Regards
Greg
--
http://www.diy-linux.org
Jeremy Huntwork wrote:
Upstream appears to think that using sysroot is the correct approach
sysroot is a complete non-starter for us. Think about it. Have you ever
tried a sysroot build? In our current build methods, we go to *great*
lengths to prevent stuff from being found on the host. In a
Jeremy Huntwork wrote:
We can simplify the sed expression and get rid of the note entirely if we
change it to:
-e 's@/tools@@g'
Anyone have any objections to this change?
I'd just like to make the following points:
1. You're introducing a distinct lack of clarity about what is
Ken Moffat wrote:
My box built gmp and the first part of chapter 6 during the night
without any apparent problem. The host system was LFS-6.3 with a
current kernel.
I just looked into this. It appears the bug only tickles when CFLAGS are
set. ie: if CFLAGS are set in the environment, it
Tobias Gasser wrote:
i had to add ABI=32 as my system was identified ad 64bit.
./configure ABI=32 --prefix=/usr --enable-cxx --enable-mpbsd
i'm using CFLAGS=-O3 -march=i486 as a global setting, overwritten for
some special cases mentionned in the book.
any idea why i have to add
DJ Lucas wrote:
Hey guys. Is there any recent documentation on the expectations of
farce or ICA?
Docs? What docs :-)
Doing only 2 passes of chapter6
with both comparison methods checked. What are the advantages of 3 or
more passes?
Huh? ICA by definition is 3 passes. No ifs, buts or
Bruce Dubbs wrote:
Umm, no. jhalfs parses the xml of the book and creates a Makefile that
builds
by the LFS book. Actually, it is quite convenient.
Umm, yes. It's *VERY* convenient. I should know..
(Me wonders if Bruce realizes the whole build straight from the doc
concept in jhalfs is
Em Wednesday 15 October 2008 16:42:37 Robert Connolly escreveu:
When GCC 4.1 released libssp, Glibc copied all of libssp in to Glibc, for
better performance.
Sorry, but that's rubbish. Glibc has *support* for ssp. Big difference.
Regards
Greg
--
http://www.diy-linux.org/
--
Dan Nicholson wrote:
Just for the record, I know guile can use an external libgmp:
http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=configure.in;h=e67e1d84;hb=HEAD#l820
Google shows that clamav and openswan use it, too. I don't know if
that's compelling enough, but I thought it
Randy McMurchy wrote:
Not sure why you're seeing it. In fact I had 0 (zero) failures on my
testsuite run. :-)
ext/Sys/Syslog/t/00-load..ok
ext/Sys/Syslog/t/constantsok
Randy McMurchy wrote:
I'm about to begin commits for package updates to LFS SVN.
I'm reviewing things first and I noticed in DJ's book that
the --disable-decimal-float parameter is passed in the GCC
Pass1 configure command.
This apparently is for the MPFR package which is built
during
Randy McMurchy wrote:
And if you follow Greg's link, you'll see that his workaround is:
cp -v ../glibc-$GLIBC_VER/iconvdata/gconv-modules iconvdata
and for what it's worth, it didn't help me. I did this before
running the tests and still got the iconv errors.
Umm, you also need a patch
Robert Connolly wrote:
On Sunday September 7 2008 06:00:55 pm Greg Schafer wrote:
Robert Connolly wrote:
I got rid of the iconvdata/bug-iconv6, and iconvdata/tst-iconv7, errors
by rebuilding Glibc a third time, without patches, after installing
Binutils-2.18 and GCC-4.1 in chapter 6. I'm
Robert Connolly wrote:
I got rid of the iconvdata/bug-iconv6, and iconvdata/tst-iconv7, errors by
rebuilding Glibc a third time, without patches, after installing
Binutils-2.18 and GCC-4.1 in chapter 6. I'm retrying with gcc-4.2. It looks
like a PATH issue... the testsuite is looking in
Robert Connolly wrote:
I'm curious if any of you have tried the Binutils test suite with gcc43. I
get
failures from binutils-2.18, and more failures from binutils-2.18.50.0.9.
Saw these failures back in Feb'. Binutils CVS HEAD checkout from around
that time resolved the failures. But I
Steve Crosby wrote:
FYI: building them in the tools directory is going to be problematic.
During the stage 1 build of gcc, the make system is unable to locate
the libmpfr.so.1 library, and so aborts.
Guys, this issue has already been solved. Just unpack the GMP and MPFR
tarballs into the
Alexander E. Patrakov wrote:
as explained in http://wiki.linuxfromscratch.org/lfs/ticket/2161 (a blocker),
due to recent changes in e2fsprogs, Grub-0.97 no longer works (cannot read
any
files from the resulting filesystem, cannot be installed into MBR, and the
book
is thus horribly
Alexander E. Patrakov wrote:
2008/3/4, Greg Schafer [EMAIL PROTECTED]:
[x] file conflict detection -- essential feature
[x] simple BLFS style dependencies -- essential feature
[x] pre/post install scripts -- essential feature
[x] ability to build the whole distro as non-root
Bryan Kadzban wrote:
Thomas Pegg wrote:
since su'ing to root even from the lfs user the path does not carry
over, /tools/bin is lost.
It will carry over unless your shell login scripts explicitly reset it.
Umm, not necessarily. It depends if the `su' comes from Coreutils or
Shadow, as I
Hi,
While we are talking about the evolution of LFS, now seems like a good
time to announce to the wider LFS community the availability of a Next
Generation build method.
The main advantages of the new method are:
- sane x86_64 bi-arch (aka Multilib)
- no more weird host issues like those
Ken Moffat wrote:
On Tue, Dec 11, 2007 at 08:41:06AM +1100, Greg Schafer wrote:
- when targeting x86_64, it doesn't matter whether the host is running
32-bit or 64-bit kernel or userland or combination of both, it just
works.
In best /. fashion, I haven't read the links yet
(dredging up an old thread)
Dan Nicholson wrote:
On 3/19/07, Dan Nicholson [EMAIL PROTECTED] wrote:
So, it seems this difference is embedded in cc1 and can't be stripped
out after the build. I'm assuming that the original difference is just
debugging symbols like would normally be the case.
Alexander E. Patrakov wrote:
The 2.6.24-rc2-mm1 kernel spams the log with messages like this:
fork(): process `artsd' used deprecated clone flags 0x40
Thread starts here: http://lkml.org/lkml/2007/11/13/577
According to the upstream author of glibc (see
Justin R. Knierim wrote:
It is
clear that supporting multiple arches is becoming more and more useful.
CLFS is a sub project of LFS and already has working and tested
implementations for so many arches, with 32bit, 64bit and multilib.
These are not all useful at this time in the main
Jeremy Huntwork wrote:
echo CFLAGS += -march=i686 configparms
snip
Everything went smoothly, so unless anyone has any objections, this is
the method I'll be dropping in, except using i486, of course. I won't
commit for the next hour or so, however, so that will give at least some
time
Robert Connolly wrote:
With HLFS I'm leaning towards bootstrapping the chroot toolchain. It's how
the
GCC developers would want it.
You cannot speak for the GCC developers, so please don't. IMHO you are WAY
off the mark anyway.
I don't know if LFS has also considered the top level
Author: jhuntwork
Date: 2007-09-15 14:45:13 -0600 (Sat, 15 Sep 2007)
New Revision: 8374
+screenuserinputfor file in $(find gcc/config -name linux64.h -o -name
linux.h)
+do
+ cp -uv $file{,.orig}
+ sed -e 's@/lib\(64\)\?\(32\)\?/ld@/toolsamp;@g' \
+ -e 's@/usr@/[EMAIL PROTECTED]'
Jeremy Huntwork wrote:
On Fri, Aug 31, 2007 at 04:54:50PM -0500, Bruce Dubbs wrote:
There also needs to be more explanation in the text interspersed with
the instructions. For instance in 5.4. GCC-4.2.1 - Pass 1 we have:
Also, the --with-arch flag is only necessary for x86 machines.
The
Alexander E. Patrakov wrote:
All these Invalid argument errors indicate that either parameters are
passed incorrectly to glibc functions, or the return codes of glibc
functions are misinterpreted. The guess is that gcc stage1 doesn't
understand Debian's multilib setup and picks up wrong
Jeremy Huntwork wrote:
On Fri, Aug 31, 2007 at 08:11:22AM +1000, Greg Schafer wrote:
PS - This addition seems like overkill as most multilib setups default to
m64. It appears Jeremy is catering to those unsupportable with current
build method non-standard 32/64-bit setups such as Alex's
Dan Nicholson wrote:
Except that you're still using the host grep, which may not have the
-q option (don't remember when it was added).
FWIW circa 2000 Red Hat 6.2 (grep-2.4) has it.
PS - This addition seems like overkill as most multilib setups default to
m64. It appears Jeremy is catering
Jeremy Huntwork wrote:
So far, I've left it as is, meaning that all three builds of gcc are
bootstrapped.
Say what? Ugh, that's just unnecessary in the extreme! We covered this
years ago..
This, certainly, is overkill, but as has been already
mentioned elsewhere, the fact that bootstrapping
Jeremy Huntwork wrote:
Does that not sound right?
It all sounds good and well but that's not the point.
what you are proposing is exactly how typical cross compilation scenarios
work. Cross compilation schemes, by definition, cannot bootstrap. Thus, a
*HUGE* advantage of a native build method
Jeremy Huntwork wrote:
$ echo 'main(){}' | ./gcc/xgcc -xc -v -
You have to give it a -B arg so it can find the sub-tools like cc1 etc.
Just look at the build log for an example.
Regards
Greg
--
http://www.diy-linux.org/
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ:
Jeremy Huntwork wrote:
$ echo 'main(){}' | ./gcc/xgcc -B./gcc/ -xc -v -
Reading specs from ./gcc/specs
xgcc: ./gcc/specs: Invalid argument
It appears there is something invalid in the specs. The trick will be
finding out what it is. Maybe you could hack the specs somehow.. sorta
like a binary
Jeremy Huntwork wrote:
Even after fixing this, there remains an issue with
bootstrapping GCC pass 1 (the actual error appears to be related to a
mis-generated spec file for stage 2 - I can set this up again if you
need to see the exact error), and the root cause is probably connected
to
Jeremy Huntwork wrote:
Alright, I've done some testing on this. (Greg, have you been able to
look at anything related on your end?)
No, sorry. Got busy (damn customers :-)
Let me just say first of all,
that the more I think about it, the saner it seems to save bootstrapping
GCC until
Alexander E. Patrakov wrote:
The first step would be to convert everything to DESTDIR-style
installation, and then adapt some existing (Slackware?) scripts to
package the result. IMHO, RPM would be overkill here.
Pacman rules!!! :-) Oops, sorry, back on topic. I guess Slackware
scripts
Greg Schafer wrote:
The facts are, our current native build method relies on the ability to
link against the host libc with the target ld. There is nothing inherently
wrong with this approach because it should always work in typical LFS
build scenarios (barring bugs of course). Yes, it would
Greg Schafer wrote:
I plan to start on x86_64 some time next week. Hopefully the problem is
reproducible on non-Debian setups.
Confirmed. I've just reproduced it here. I'll send a note upstream and try
to get an explanation as to why it affects only x86_64.
Regards
Greg
--
http://www.diy
Alexander E. Patrakov wrote:
Greg Schafer wrote:
Confirmed. I've just reproduced it here. I'll send a note upstream and try
to get an explanation as to why it affects only x86_64.
Many thanks. Could you please keep lfs-dev informed about your further
communication with upstream?
Sure
Alexander E. Patrakov wrote:
I'll wait for PPC results, and try to read the code of binutils in order
to answer the x86-related question.
ppc works.
Hm. It looks like an inconsistency in your attitude to such problems.
Huh? WTF does my attitude have to do with anything? Got some sort of
Alexander E. Patrakov wrote:
OK. However, I would like to see a simple and well-defined set of host
requirements for a native build in the DIY reference build document,
so that one knows where it is supposed to work and where it isn't. I.e.,
something that clearly judges the past
Alexander E. Patrakov wrote:
GNU hash. Found it by creating several dummy shared libraries of my own:
Finally! Some technical details. Yay. However, my understanding is that
these hash-style changes are supposed to be back compatible.
echo foo(){} | gcc -fPIC -x c -m64 -shared -o foo.so -
Alexander E. Patrakov wrote:
The problem looks specific to x86_64. I can't reproduce it on Debian x86
(32-bit).
Ok. If latest HJL binutils work, we can therefore conclude there was some
x86_64 bugfix made after binitils-2.17.
Mission - identify the fix, backport patch to 2.17, voila -
Alexander E. Patrakov wrote:
Not sure that it is possible. Reason: binutils-2.17.50.0.2 don't support
--hash-style=both and fail linking to Debian's glibc, while
binutils-2.17.50.0.3 support --hash-style=both and work. So a bugfix
is very likely to be just the addition of the GNU hash
Alexander E. Patrakov wrote:
I don't buy this explanation alone. The fact is that you can't build LFS
(or DIY) with FSF binutils if you are on x86_64 and start from a new
host such as Debian Lenny x86_64.
The LFS/DIY build method is only meant to work on sane build hosts, ie:
pure 32, pure
Alexander E. Patrakov wrote:
An untested idea: build binutils-pass1 and gcc-pass1 as cross-tools (as
explained in CLFS), cross-compile glibc as explained in CLFS, build
native-to-new-glibc binutils and gcc using our cross-tools, and continue
with the native method. This way (if this
Alexander E. Patrakov wrote:
1) FSF binutils 2.17 don't recognize 64-bit libc.so.6 on Debian Lenny
x86_64
Yes, but why? This is the kind of debugging I'm talking about. We need to
understand the technical details here and identify the root cause. Once
the issue is understood, only then can we
Greg Schafer wrote:
PS - According to my build logs, GCC-4.2 takes almost *double* the amount
of time of GCC-4.1 for a 3-stage bootstrap. This doesn't matter much on a
modern dual-core system (16m 45s vs 8m 41s) but it's very noticeable on an
older ppc mac mini (91m vs 43m). So maybe
Dan Nicholson wrote:
sed -i.bak '/THIS_SH/s,$, /dev/tty,' tests/run-test
Seems more appropriate. I was trying to avoid another command, but
it's the right thing to do. I'll try to push that in.
I wanted to ask you about this, though. What's the reason you don't
hit this in DIY?
Alexander E. Patrakov wrote:
I was trying to find a way to build some LFS-like x86_64 system from
Debian Lenny x86 (which has 32-bit userspace, a patched compiler that
accepts -m64 to produce 64-bit binaries, some multilib setup, and an
option to install a 64-bit kernel).
Hmm, sounds like
Dan Nicholson wrote:
A while back we changed the bash test suite to run as the nobody user
because it enables more tests to be run. Ken and I have each had a
pair of test failures building with 6.3-rc1. Looking closer, the test
is checking whether `test -r /dev/stdin' and `test -r /dev/fd/0'
Dan Nicholson wrote:
I would like to allow glibc-2.5.1 through a freeze if it happens. That
should be safe since we've been moving the snapshot along.
New Glibc's are now up.
Regards
Greg
--
http://www.diy-linux.org/
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ:
Greg Schafer wrote:
Indeed, but IMHO some of the Fedora rationale is questionable ie: dead
upstream is not quite true. That is, if you can believe the sysklogd
maintainer :-)
http://lists.infodrom.org/infodrom-sysklogd/2007/0011.html
A new release has been made after 6 years. Shock
1 - 100 of 229 matches
Mail list logo
