On Aug 20, 2012, at 3:03 PM, Randy McMurchy ra...@linuxfromscratch.org wrote:
Anyway, I'm glad to be back and I look forward to getting back working
on the BLFS book again.
I must really have stopped paying attention, I thought you were still
leading the BLFS effort!
Anyway, welcome back! I'm
On Aug 16, 2012, at 12:37 PM, Bruce Dubbs bruce.du...@gmail.com wrote:
Sigh.
It looks like we will need to add a section to Chapter 5 for shadow:
pushd libmisc; make libmisc.a;popd
pushd lib; make libshadow.la; popd
pushd src; make su ; popd
cp src/su /tools/bin
Oh no! I'm so sorry to hear that!
I always enjoyed reading Andy's posts and seeing the contributions he
made to the projects. He will definitely be greatly missed.
Please convey my deepest sympathy to his family.
JH
On Jul 31, 2012, at 5:25 PM, Bruce Dubbs bruce.du...@gmail.com wrote:
With
On Jun 14, 2012, at 5:06 PM, Bruce Dubbs bruce.du...@gmail.com wrote:
youlys...@riseup.net wrote:
Hey all!
I'm new to LFS, and I started skimming though the book, and I found this.
Linux Kernel
This package is the Operating System. It is the Linux in the GNU/Linux
environment.
-
We have the switch --disable-perl-regexp which is fine, but the
explanation is no longer correct. It says:
This ensures that the grep program does not get linked against a Perl
Compatible Regular Expression (PCRE) library that may be present on the
host but will not be available once we enter
On 6/6/12 3:24 PM, Matt Burgess wrote:
Surely if we can't find/link against host libs at this point, that flag
is at best superfluous and at worst a potential danger as it may mask us
being able to link against host libs when we shouldn't be able to?
Yep - agreed on all points. Superfluous.
On 6/6/12 7:27 PM, Ken Moffat wrote:
1. It may encourage the people who are resurrecting the drop
autotools from LFS suggestion :)
Too late, I'm already encouraged! :P
Seriously though, I really didn't intend to bring up that discussion
again. I only wanted to get rid of popt. :) But that may
On 6/6/12 9:21 PM, Bruce Dubbs wrote:
Jeremy Huntwork wrote:
(Major tangent now) My main motive for wanting to keep a very
lightweight base system isn't so much size on disk as image size (a
complete base system image). This is a somewhat important consideration
if you want to be easily
On Jun 6, 2012, at 10:47 PM, Bruce Dubbs bruce.du...@gmail.com wrote:
It's a neat exercise to get it as small as possible. Not very critical
though when RAM is $4/G, disk is $0.50/G, and even SSDs are down to $1/G.
Again, it's not just about disk space or available RAM. It's about (as
one
On 6/5/12 2:05 AM, g@free.fr wrote:
This make me smile a lot.
There is much more dependencies in perl than just glibc and linux packages.
Check a bit your log with
grep -rl 'perl 'logdirectory
Getting perl hits in your logs does not always equate to actual
dependency. Configure scripts
On 5/28/12 6:54 PM, Jeremy Huntwork wrote:
Maybe let's wait before updating anything again, just to be 100% certain
on what the right path is here, and I'll try to reach out to upstream in
the meantime to see if someone there is willing to give me an answer we
can work with.
Well, I posted
I thought popt was already removed from pkg-config in git? If so, why
did we add it into the book now instead of at least applying Dan's patch
to remove that dependency?
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the
On 6/4/12 3:06 PM, Bruce Dubbs wrote:
Jeremy Huntwork wrote:
I thought popt was already removed from pkg-config in git? If so, why
did we add it into the book now instead of at least applying Dan's patch
to remove that dependency?
Other packages use popt. If it works (appears to be ok
On 6/4/12 3:28 PM, Bruce Dubbs wrote:
hd2u.xml:para role=requiredxref linkend=popt//para
libbonobo.xml:xref linkend=popt//para
libdv.xml:para role=optionalxref linkend=popt/,
rsync.xml:para role=optionalxref linkend=popt/,
samba3.xml:para role=optionalxref linkend=popt/,
inkscape.xml:xref
On 6/4/12 5:20 PM, DJ Lucas wrote:
On 06/04/2012 02:35 PM, Jeremy Huntwork wrote:
(perl is another one I'd love to see removed, but I'm not going to
seriously recommend that one :) )
Just curiosity, what are the necessary steps? I was pretty sure that
something obscure in either gcc or glibc
On 6/4/12 7:52 PM, Andrew Benton wrote:
So maybe it should just be installed in Chapter 5 and the Chapter 6
page could move to BLFS?
If you removed the dependency in glibc and linux, you wouldn't need to
do either.
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ:
On 6/4/12 7:54 PM, Jeremy Huntwork wrote:
On 6/4/12 7:52 PM, Andrew Benton wrote:
So maybe it should just be installed in Chapter 5 and the Chapter 6
page could move to BLFS?
If you removed the dependency in glibc and linux, you wouldn't need to
do either.
Oh, I see what you mean though
On 6/4/12 8:52 PM, Bruce Dubbs wrote:
As stated earlier, the goal of LFS is to build a complete and usable
foundation-level system. This includes all packages needed to replicate
itself while providing a relatively minimal base from which to customize
a more complete system based on the
On 6/4/12 10:51 PM, Bryan Kadzban wrote:
OK. Your distro, your rules. :)
For the record, perl is also required for automake. Half of its
installed files (or so) are perl modules, and /usr/bin/automake is a
perl script.
That's another package I would personally remove from LFS (along with
On 5/25/12 8:55 AM, Armin K. wrote:
I want to add that I've experimented with the /usr merge since I use
one partition for everything.
I don't believe anyone commented on this part, but I'm curious. What did
you do exactly to achieve the /usr merge? For my own experiments in
LightCube I've
On 6/1/12 9:31 AM, James Robertson wrote:
Sure. Lets take sudo as an example. What could be considered a simple
program has 8 optional dependencies with 4 being off book. I think we
ignore those 4 and worry only for the 4 in book optional
dependencies. The build instructions in the main
On 5/31/12 5:32 PM, Andrew Benton wrote:
pkk-config
glib (required)
Since when does glib require Python? Are you using glib2? IIRC,
pkg-config up until recently shipped with glib1 sources and built that
in its own build system. In fact pkg-config's page says it uses
glib-1.2.10 - that's
On 5/31/12 6:01 PM, Armin K. wrote:
pkg-config 0.26 uses glib2 and does not ship glib1 anymore. And since
LFS/BLFS tends to use latest stuff, glib 2.32 requires python for gdbus
stuff and libffi for some other stuff ... Do note that pkg-config 0.25
can be still built flawlessly. It can be
On 5/31/12 6:10 PM, Andrew Benton wrote:
On Thu, 31 May 2012 22:38:21 +0100
Jeremy Huntworkjhuntw...@lightcubesolutions.com wrote:
Since when does glib require Python?
I think Python's been a required dep since glib-2.32. It may be
possible to build glib without python but it will need
On 5/31/12 4:41 PM, James Robertson wrote:
I have been watching this thread and it seems to have gone a bit dormant
so maybe now is a good time to add my thoughts. First off - Jeremy,
your contributions to this project continue to amaze me. Keep it up buddy.
Thanks James, :)
1. Adding PM
On 5/31/12 6:17 PM, Jeremy Huntwork wrote:
It still amazes me that pkg-config requires any other external library.
glib1 wasn't bad since it was shipped alongside it and had no other
deps, fairly lightweight. But switching to glib2 was just ridiculous.
All that pkg-config is doing is parsing
On 5/28/12 2:52 PM, Bruce Dubbs wrote:
The problem is that none of these libraries are used for udev. On a
recent blfs system, where the systemd dependent libraries are installed,
I as able to build and looked at the executables and libraries. AFAIK,
the only ones are /bin/udevadm,
On 5/9/12 4:29 PM, Matt Burgess wrote:
On Wed, 2012-05-09 at 16:24 -0400, Jeremy Huntwork wrote:
I'll dig a bit and get back to you.
Note that I'm busy digging too. Having fixincludes run in chapter 5
looks safe; GCC only searches for headers under /mnt/lfs/tools/include
or /tools/include
On 5/28/12 6:15 PM, Jeremy Huntwork wrote:
I think we may have been too quick on the draw with removing this
command entirely. The reason being that this script was originally added
into gcc to fix non-ANSI headers in various packages.
http://gcc.gnu.org/viewcvs/trunk/fixincludes/README
On 5/28/12 6:37 PM, Matt Burgess wrote:
On Mon, 2012-05-28 at 18:16 -0400, Jeremy Huntwork wrote:
On 5/28/12 6:15 PM, Jeremy Huntwork wrote:
It's probably safer to add back the command that disables this script
but just make sure that our explanation for it is accurate.
Oh, and sorry
On 5/25/12 12:51 PM, Bruce Dubbs wrote:
I suppose we will need to do a minimal install in LFS and a more
complete install with all the bells and whistles in BLFS. Sigh.
There are dev alternatives, like mdev from busybox. It may at least be
worth investigation to see if we can avoid the
On 5/20/12 7:09 PM, Ken Moffat wrote:
The more I think about this, the less happy I am. Point 2 doesn't
really help editing BLFS as far as I can see (upgrading a package
usually needs several builds - typically, for me, a first to see if
it actually works when I use it, then others to get
On 5/20/12 2:18 PM, Bryan Kadzban wrote:
In other words, I think it'd help to only use packages to simplify
(mostly BLFS) testing, but make them semi-public for people who really
want them. Don't use them at all in the actual build instructions (what
would be the point? :-) ), but generate
On 5/20/12 5:34 PM, Bruce Dubbs wrote:
OK, then what's wrong with a tarball of binaries that we have created
for this purpose? There could be a tarball of the base LFS system and
then additional tarballs for certain packages or groups (e.g. xorg) of
packages.
This method does not collect and
On 5/20/12 7:09 PM, Ken Moffat wrote:
[snip - a number of good, thoughtful questions]
I'm going to have to let your questions brew for a while before I can
reply to them. Perhaps someone else will have an opinion regarding them
in the meantime...
JH
--
On 5/19/12 1:15 PM, DJ Lucas wrote:
What separates LFS from say Arch, Gentoo, T2... at that point? No mile
long USE flags or complex switching scripts I presume, but I know little
about the other two. I've included some of their work in BLFS in the
past, but that is about it.
Well, the way I
On 5/19/12 1:21 PM, Baho Utot wrote:
I have in the past worked on LFS-6.8 and have a completed pacman build
for it. I wanted to build a desktop system from LFS/BLFS but it was too
much work for me. I have not gone further because BLFS is a beast as
you say. I completed a server using
On 5/19/12 1:15 PM, DJ Lucas wrote:
My hope is that build order is still a manual process where the user
determines build order herself. Dependency checking is done only at
build time and that optional deps remain optional. If there will be
automation, how do we determine what optional deps to
On May 19, 2012, at 5:04 PM, Bruce Dubbs bruce.du...@gmail.com wrote:
It's easy to create a tarball of binaries for a specific
architecture (686, x86_64, etc) and extract that to an empty partition.
A rebuild of the kernel, setting up grub, and a script to handle some
specific things (fstab,
On May 19, 2012, at 5:03 PM, Bruce Dubbs bruce.du...@gmail.com wrote:
DJ Lucas wrote:
I have long suggested that LFS and BLFS move to installations
from DESTDIR (or equivalent)
I do use DESTDIR to check the installation of most packages, but there
are some where it just doesn't work.
On 5/19/12 7:29 PM, Bruce Dubbs wrote:
Certainly you have the privs, but I would like to have the capability of
doing make DESTDIR=$DEST without being root. I don't particularly like
the developer saying you have to be root to run install. It's my
system, not the developer's.
I believe that
On 5/18/12 11:37 AM, Bruce Dubbs wrote:
Jeremy, I think you overstate the issues. To me, LFS is a leading edge
system,
but not a bleeding edge system. On one hand we try to keep up to date with
the
current package releases, but we try to stay away from intermediate versions
that lie in
On 5/18/12 3:36 PM, Qrux wrote:
I'll let you and Bruce continue on about experimentation, etc. I would
ordinarily chime in (and suggest probably more flame-worthy stuff like
moving to git would foster more experimentation, because the effort of
merging would be front-loaded on forkers--not
Greetings all,
Consider two things:
1. We all hate long build times. Anything we can (reasonably and
accurately do) to speed up the build we do.
2. Chapter 5 are a set of throwaway tools (in some cases we only build
just what we want out of those tools, again, for sake of speed, i.e.,
On 5/8/12 2:54 AM, Matt Burgess wrote:
If so, then all that section about fixincludes can be dropped from pass 2.
Are we only talking about changing pass 2 here? We also have a sed in
the final build of GCC in chapter 6 with the following explanatory text:
The fixincludes script is known to
On 5/9/12 4:29 PM, Matt Burgess wrote:
On Wed, 2012-05-09 at 16:24 -0400, Jeremy Huntwork wrote:
I'll dig a bit and get back to you.
Note that I'm busy digging too. Having fixincludes run in chapter 5
looks safe; GCC only searches for headers under /mnt/lfs/tools/include
or /tools/include
On 5/9/12 4:38 PM, Matt Burgess wrote:
The only concern I would have is whether or not the use of busybox will
alter the results of any configure scripts. Assuming testing shows it
doesn't, then I've no objections at all to a mockup with a view to
getting this merged relatively quickly.
Yes,
On 5/9/12 4:43 PM, Bruce Dubbs wrote:
Total 5 minutes + 42 seconds
Yes, the actual machine time is not as great a savings as I would like,
however it does make a huge dent in user time for manual builds - no
matter what, everyone goes through the manual build process of LFS at
least once
Looks like I missed some necessary text changes. At the bottom of
chapter 5 glibc, in the sanity check box, the following sentences are
no longer accurate and can be removed:
Something may have gone wrong with the specs file amendment above. In
this case, redo the specs file amendment, being
On May 5, 2012, at 10:24 AM, Jeremy Huntwork
jhuntw...@lightcubesolutions.com wrote:
Looks like I missed some necessary text changes.
There's also this statement made regarding the fixincludes script in GCC
pass 2: In fact, running this script may actually pollute the build
environment
On 26 Apr 2012, at 14:02, Ken Moffat wrote:
Compare
http://www.linuxfromscratch.org/lfs/view/development/chapter06/readjusting.html
to
http://www.linuxfromscratch.org/lfs/view/jh/chapter06/adjusting.html
I think it was a bad svn merge.
Let me see if I can fix.
JH
--
On 26 Apr 2012, at 15:10, Ken Moffat wrote:
I've got a diff of chapter06/adjusting.xml from trunk/BOOK to
branches/jh which looks as if it will do the right thing. I can
apply it if you like ?
Sure - there's also these two minor ones:
Index: chapter05/gcc-pass2.xml
On 4/23/12 11:42 PM, Bruce Dubbs wrote:
That's it. I think Jeremy has done a great job.
Thanks :) glad it worked well for you.
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On 4/22/12 11:36 PM, Bruce Dubbs wrote:
gcc-pass2
[snip]
Configure:
Remove -B/tools/lib/ from CC
Remove configure options
--with-native-system-header-dir=/tools/include
--without-ppl
--without-cloog
The
On 4/23/12 12:28 PM, Bruce Dubbs wrote:
I also think we will need a paragraph or two in the What's New section
explaining the changes.
Yeah, that might be good. Also a review of section 5.2 to make sure all
statements there are still correct.
JH
--
This changelog entry on 2012-04-05 isn't quite correct. It reads:
[matthew] - Use su from chapter 6 Coreutils in the Bash instructions,
instead of the one from chapter 5. Install su as su rather than su-tools
in chapter 5. Fixes #3057.
coreutils in chapter 6 doesn't install su. So the su
On 4/23/12 12:45 PM, Jeremy Huntwork wrote:
This changelog entry on 2012-04-05 isn't quite correct. It reads:
[matthew] - Use su from chapter 6 Coreutils in the Bash instructions,
instead of the one from chapter 5. Install su as su rather than su-tools
in chapter 5. Fixes #3057.
coreutils
On 4/23/12 1:11 PM, Pierre Labastie wrote:
The reason is that /tools/bin/su cannot work for a normal user,
because the setuid bit cannot be set at install in chapter 5 (if
installing as user lfs). Hence the choice of naming it su-tools, to
prevent it to run (and fail) if the lfs user (who has
On 4/23/12 4:33 PM, Matt Burgess wrote:
The fix for this is to add
--with-native-system-header-dir=/tools/include to GCC's pass1 and pass2
builds so that it doesn't look at /usr/include at all.
For the current build method, I think it's only required for pass 2.
Given the difference of our
On 4/22/12 11:33 AM, LFS Trac wrote:
#3066: Chapter 5 ncurses fails with (old?) gpm on host
-+--
Reporter: dj@… | Owner: lfs-book@…
Type: task | Status: new
On 4/22/12 2:23 PM, DJ Lucas wrote:
As it turns out, it was a problem with the host. /usr/lib64/libgpm.so is
not a symlink, but rather a linker script that points to another linker
script that points to an invalid destination (ie: no 64bit libgpm). I
was going to close as invalid, but then I
On 4/22/12 2:25 PM, Jeremy Huntwork wrote:
On 4/22/12 2:23 PM, DJ Lucas wrote:
As it turns out, it was a problem with the host. /usr/lib64/libgpm.so is
not a symlink, but rather a linker script that points to another linker
script that points to an invalid destination (ie: no 64bit libgpm). I
On 4/22/12 2:35 PM, Bruce Dubbs wrote:
It only makes a difference if we are going to actually use ncurses
functionality
between the time we bould it in Chapter 5 and Chapter 6. Otherwise we are
just
linking to the libraries.
However, I don't have a problem with adding --without-gpm to
On 4/22/12 2:35 PM, Jeremy Huntwork wrote:
On 4/22/12 2:25 PM, Jeremy Huntwork wrote:
On 4/22/12 2:23 PM, DJ Lucas wrote:
As it turns out, it was a problem with the host. /usr/lib64/libgpm.so is
not a symlink, but rather a linker script that points to another linker
script that points
On 4/22/12 2:52 PM, Jeremy Huntwork wrote:
On 4/22/12 2:49 PM, Pierre Labastie wrote:
Solution:
add the switch --with-native-system-header-dir=/tools/include to
gcc-pass2 configure command.
I've been building ten times on various (virtual) hosts with this switch
without a problem.
I
On 4/22/12 3:48 PM, Pierre Labastie wrote:
cp gcc/Makefile.in{,.orig}
sed '/^CROSS_SYSTEM_HEADER_DIR/s@= .*@= /tools/include@' \
gcc/Makefile.in.orig gcc/Makefile.in
cp gcc/cppdefault.c{,.orig}
sed '/#define STANDARD_INCLUDE_DIR/s@/usr/include@0@g' \
gcc/cppdefault.c.orig
On 4/22/12 3:48 PM, Pierre Labastie wrote:
I think the sysroot method can be simplified if using the switch above:
you do not even need the part:
cp gcc/Makefile.in{,.orig}
sed '/^CROSS_SYSTEM_HEADER_DIR/s@= .*@= /tools/include@' \
gcc/Makefile.in.orig gcc/Makefile.in
cp
On 4/22/12 4:09 PM, Jeremy Huntwork wrote:
So CROSS_SYSTEM_HEADER_DIR should get set correctly if we've already
specified NATIVE_SYSTEM_HEADER_DIR, which is what gets set via your switch.
I'll just fix up the jh branch source and give another run and compare
results.
Looks good, committing
On 4/22/12 5:59 PM, DJ Lucas wrote:
On 04/22/2012 04:35 PM, Jeremy Huntwork wrote:
So, I'm seeing that you have the aforementioned switches in both pass 1
and pass 2 gcc and I'm trying to understand exactly why.
In pass1 it simply speeds up the build
How does it speed up the build?
JH
On 4/22/12 6:00 PM, Matt Burgess wrote:
Given your reasoning, I don't see why they're needed either, but #2723
explicitly mentioned link errors (although conveniently failed to copy
and paste them). Now, admittedly, I never saw those errors myself, but
then I only test on one arch on one host
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On 4/22/12 6:41 PM, Jeremy Huntwork wrote:
woops, that wasn't supposed to send. Turned out to be a very minor
thread after all. :)
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On 4/22/12 6:44 PM, DJ Lucas wrote:
I'm not entirely positive, it's been a few years, but there was no need
to compile unnecessary additions that eat up time. Granted, it is a very
small savings in the grand scheme. That was the goal of those switches
and several others at the time that GCC
On Mar 28, 2012, at 9:37 PM, DJ Lucas d...@linuxfromscratch.org wrote:
Drop is better for the book.
+1
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On 3/29/12 3:54 PM, Pierre Labastie wrote:
Le 29/03/2012 19:13, Pierre Labastie a écrit :
Hi,
#include ... search starts here:
#include... search starts here:
/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include
On 3/22/12 6:01 PM, Pierre Labastie wrote:
Why do you use :
+ make install_root=/tools install?
With --prefix=/tools, all the files are installed in
/tools/tools/{lib,include}
Of course the sanity check fails, because it looks for files in
/tools/{lib,include}
Yep, thanks, I think
On 3/18/12 6:44 PM, Bryan Kadzban wrote:
Well, from the comments in the book, it's not libc; it's crt1/crt0/crtn,
or whatever the files are named these days.
Yes, you are correct, it's the start files it can't find. I was just
being imprecise.
One other thing I'm concerned about is enabling
On 3/17/12 12:26 PM, Bruce Dubbs wrote:
Jeremy Huntwork wrote:
Everyone else, please do review all of the links and posts that Greg
provided. It was mostly reading those (and bits of the source) as well
as the tests/experimentation that convinced me that the proposed method
is solid
On 3/14/12 11:32 PM, Bryan Kadzban wrote:
It *almost* looks like sysroot is the equivalent of a DESTDIR install,
where all the libs are installed intosysroot prefix/whatever/path,
but ask for /whatever/path at runtime (e.g. when ld.so is looking for
DT_NEEDED entries, or in DT_RPATH entries in
On 3/16/12 3:22 AM, Bryan Kadzban wrote:
Removing the need for adjusting the toolchain does seem to hurt
teaching; we're using some magic flags instead of editing the specs
file. (OTOH the specs file is now more of a builtin thing in the gcc
driver. I do still think it's useful to know about
On 3/17/12 5:38 PM, Bruce Dubbs wrote:
Until gcc-4.7 comes out I'm recommending we use the exiting jh branch of
lfs and go ahead and put in these changes now with the release candidate
packages. Then we can do some jhalfs style builds and test things out
from there. When the new tool chain
On 3/17/12 8:25 PM, Bruce Dubbs wrote:
Jeremy Huntwork wrote:
I killed the jh branch some weeks back (I don't think I had touched it
since 2008) but we could re-create it again, if you like.
Sure. I just re-created it.
Great, thanks.
Do you want me to set up a daily build?
Not just yet
On 3/15/12 4:51 PM, Greg Schafer wrote:
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
On 3/8/12 4:24 PM, Bruce Dubbs wrote:
Jeremy Huntwork wrote:
On 3/2/12 11:10 AM, Bruce Dubbs wrote:
--- binutils-build-sysroot-libdir/ld/eelf_x86_64.c 2012-03-01
23:31:31.789317951 -0500
+++ binutils-build-nosysroot-nolibdir/ld/eelf_x86_64.c 2012-03-02
00:29:16.117697363 -0500
Yes, I
On 3/14/12 7:20 PM, Matt Burgess wrote:
On Wed, 2012-03-14 at 23:11 +, Andrew Benton wrote:
With the full gcc-4.6.3 tarball I get the same results as everybody
Wonderful! I'll sleep easier tonight now :-) I'm glad this has finally
been solved.
Nice! Glad we got that one nailed down.
On 3/13/12 12:27 PM, Pierre Labastie wrote:
Le 13/03/2012 16:18, Andrew Benton a écrit :
I was unwilling to use jhalfs as I dislike sudo. However, needs must,
and the result?
[...]
This was using Jeremy's sysroot.diff on top of the LFS xml files. I
think vanilla LFS will work for me as it
On 3/13/12 1:21 PM, Andrew Benton wrote:
... and then I tried jhalfs with the vanilla LFS svn book and of
course, I was wrong again, it failed in exactly the same way! Looking
at the differences between the book and the scripts that work for me,
the book has --disable-target-libiberty
On Mar 13, 2012, at 6:03 PM, Andrew Benton a...@benton.eu.com wrote:
On Tue, 13 Mar 2012 17:40:03 +
Bruce Dubbs bruce.du...@gmail.com wrote:
I'm having a problem with why this is happening.
Me too...
The jhalfs vanilla LFS
svn build worked perfectly for me.
On 3/12/12 7:25 AM, Pierre Labastie wrote:
Le 12/03/2012 10:18, Andrew Benton a écrit :
I've only just woken up so I've not had time to check, but looking at
the output above I'm pretty sure ${LFS_TGT} is set because I can see
lots of `x86_64-lfs-linux-gnu'. I also think it's doing a bootstrap
On 3/12/12 7:24 AM, Andrew Benton wrote:
I mainly use my current LFS install, I get the same errors if I use a
Fedora or Ubuntu live CD.
Which version specifically? If I get a chance, I'll download an iso and
fire up a virtual machine to see if I can replicate.
JH
--
On 3/12/12 11:14 AM, Andrew Benton wrote:
Fedora-16-x86_64-Live-Desktop.iso
FWIW I can do you sysroot method if I patch gcc with the cross_compile
patch and add these options to configure:
--without-ppl --without-cloog \
--without-target-libiberty --without-target-zlib
I'm not sure
On Mar 11, 2012, at 8:15 PM, Andrew Benton a...@benton.eu.com wrote:
On Sun, 11 Mar 2012 23:54:44 +
Matt Burgess matt...@linuxfromscratch.org wrote:
On Fri, 2012-03-02 at 00:39 +, Andrew Benton wrote:
On Sat, 25 Feb 2012 19:40:49 +
Matt Burgess matt...@linuxfromscratch.org
On Mar 11, 2012, at 8:19 PM, Matt Burgess matt...@linuxfromscratch.org wrote:
On Mon, 2012-03-12 at 00:11 +, Andrew Benton wrote:
I get the same error if I use scripts or if I copy and paste the
commands from the book. It is a bootstrapped build of gcc, and it fails
during the second or
On 3/5/12 6:57 PM, Qrux wrote:
On Mar 4, 2012, at 7:10 AM, Jeremy Huntwork wrote:
On 3/1/12 4:27 PM, Jeremy Huntwork wrote:
And because of the pre-adjusting there's even less chance to bring in
something from the host system. The limits.h file is an example. The
first pass of GCC doesn't
On 3/2/12 11:10 AM, Bruce Dubbs wrote:
--- binutils-build-sysroot-libdir/ld/eelf_x86_64.c 2012-03-01
23:31:31.789317951 -0500
+++ binutils-build-nosysroot-nolibdir/ld/eelf_x86_64.c 2012-03-02
00:29:16.117697363 -0500
Yes, I saw that. Reviewing.
How is that coming along?
JH
--
On 3/5/12 11:56 AM, Andrew Benton wrote:
Sorry for being slow to respond, I've been busy :)
I remember reading that gcc bug last year when I first hit the problem.
I spent some time trying to implement the solutions proposed there but
none of them worked. Reading through it again now I noticed
On 3/1/12 4:27 PM, Jeremy Huntwork wrote:
And because of the pre-adjusting there's even less chance to bring in
something from the host system. The limits.h file is an example. The
first pass of GCC doesn't install a full-featured limits.h file because
it can't find one in the include paths
On 3/4/12 10:10 AM, Jeremy Huntwork wrote:
For the proposed build method, this does not appear to be the case:
Fixing headers into /mnt/lfs/sources/gcc-build/gcc/include-fixed for
x86_64-unknown-linux-gnu target
Forbidden identifiers: linux unix
Finding directories and links to directories
On 3/3/12 1:11 PM, Qrux wrote:
The security issues with production has been mentioned several times. I've
sort of just assumed it was a friendly caveat emptor, and filtered it out.
But, it's now come up often enough where it seem to be implying something
stronger than the assumption
On 3/3/12 6:01 PM, Bruce Dubbs wrote:
Jeremy Huntwork wrote:
I think the reason this comes up is because LFS is made up of a
limited number of developers (essentially hobbyists) that don't have
the time and resources to track down all security issues.
I think the term hobbyist as used here
1 - 100 of 1158 matches
Mail list logo
