On Aug 20, 2012, at 3:03 PM, Randy McMurchy 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 certain the various proj
On Aug 16, 2012, at 12:37 PM, Bruce Dubbs 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
Crazy overkill.
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 wrote:
> With great sadness, I have
On Jun 14, 2012, at 5:06 PM, Bruce Dubbs 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.
>>>
>>>
On Jun 6, 2012, at 10:47 PM, Bruce Dubbs 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 example) the time it tak
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 consi
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
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.
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 t
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 '
Getting perl hits in your logs does not always equate to actual
dependency. Configure scripts may check
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
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 ch
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 eit
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: http://www.
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
&g
On 6/4/12 3:28 PM, Bruce Dubbs wrote:
> hd2u.xml:
> libbonobo.xml:
> libdv.xml:,
> rsync.xml:,
> samba3.xml:,
> inkscape.xml:,
>
> You too can learn grep.
Har har - I don't have the sources anywhere that I can grep and I
figured you'd know. *shrug*
Anyway, I think popt is kind of silly and I hop
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 p
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 abo
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
> c
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 m
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'
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-c
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
On 5/31/12 6:10 PM, Andrew Benton wrote:
> On Thu, 31 May 2012 22:38:21 +0100
> Jeremy Huntwork 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 wi
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 i
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
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 f
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/
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 /mn
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, /usr/l
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 syste
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 ge
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
--
http://linuxfromscratch.org/mailman/li
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
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 generat
On 5/20/12 3:10 PM, Bruce Dubbs wrote:
>> This exact reason, for the record, is why I really dislike binary
>> distros. I *never* choose the same set of dependencies that are
>> optional in the source, as the distro does. And because when they ran
>> ./configure, they added a --with-foo flag, the
On 5/19/12 5:27 PM, lfs-dev.neophyte_...@ordinaryamerican.net wrote:
> The "pacman" reference here is to https://wiki.archlinux.org/index.php/Pacman
> not http://pacman.com/en/
> Correct?
Haha. Yes, that's right. Unless you can find a way to package up
distributable packages with the arcade game.
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
On May 19, 2012, at 5:03 PM, Bruce Dubbs 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. Actually, any pac
On May 19, 2012, at 5:04 PM, Bruce Dubbs 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, ip address, etc)
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
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 LF
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've been holding back bringing this up on-list for a while because I
intended to do the bulk of the work and then present a working system to
the community for comment and review. I still intend to do that, but
given some recent discussions, I think the time is right to bring this
up and see w
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
On 5/18/12 12:34 PM, Jeremy Huntwork wrote:
> I agree with all these points, but being stable and
> re-thinking/experimenting are not mutually exclusive. Again, it's a
> matter of process and organization. But the typical behavior I've seen
> is to nay-say new ideas because i
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
On 5/18/12 5:22 AM, Qrux wrote:
> But, let's not make it a crime to clarify. If Ken would rather assert
> that I'm not "new" to the community, then to the extent that his
> assertion is valid I'd say that I see a lot of GroupThink(TM) in LFS.
> Most is probably good. But there are often ruffled f
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
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.
Y
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 /mn
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 k
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.,
gettext)
On 5/7/12 7:04 PM, Matt Burgess wrote:
> There's a comment in linux/a.out.h that it fixed
> up /tools/include/a.out.h so that looks OK. syslimits.h just includes
> limits.sh, so that looks fine too. limits.h has been fixed but there's
> no indication of which limits.h was used as input to it. I
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 buil
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 care
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 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
--
http://linuxfromscra
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/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/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 h
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 ch
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 you're
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
--
http://linuxfromscratch.org/mailman/lis
On 4/23/12 12:00 PM, Jeremy Huntwork wrote:
> The --with-native-system-header-dir=/tools/include option is actually an
> addition, not a removal. Everything else looks like it's correct, Bruce.
> (I think I forgot to remove the startfiles patch from chapter 3 and the
> patches.e
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 --with-native-syste
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 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
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
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 h
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
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.
Here's the changeset that introduced them:
http://wiki.linuxfromscratch.org/lfs/changeset/9349
And here's the ticket that started that ball rolling:
http://wiki.linuxf
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
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 gcc/
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.or
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
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 believe the proposed sysroot method also fixes
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 ano
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
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 dest
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
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 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
>>
>> /mnt/lfs/tools/bin/../lib/gcc/x86
On Mar 28, 2012, at 9:37 PM, DJ Lucas 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/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 th
On 3/22/12 5:43 PM, Thierry Nuttens wrote:
> In file included from /mnt/lfs/tools/include/features.h:382:0,
> from /mnt/lfs/tools/include/limits.h:27,
> from
> /mnt/lfs/tools/bin/../lib/gcc/x86_64-lfs-linux-gnu/4.7.0/include-fixed/limits.h:169,
>
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 enablin
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
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 chai
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 ab
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 into/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 libs thems
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 t
On Mar 17, 2012, at 11:11 AM, Thierry Nuttens wrote:
> It's not easy to find the right mail about Jeremy's new build method.
http://linuxfromscratch.org/pipermail/lfs-dev/2012-February/065826.html
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/f
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 ord
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 d
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-nolibd
On Mar 13, 2012, at 6:03 PM, Andrew Benton wrote:
> On Tue, 13 Mar 2012 17:40:03 +
> Bruce Dubbs wrote:
>
>> I'm having a problem with why this is happening.
>
> Me too...
>
>> The jhalfs vanilla LFS
>> svn build worked perfectly for me.
>>
>> http://www.linuxfromscratch.org/~bdubbs/033-gcc
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 --dis
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 fo
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
1 - 100 of 1449 matches
Mail list logo
