[EMAIL PROTECTED] wrote:
> Author: randy
> Date: 2008-10-12 09:09:40 -0600 (Sun, 12 Oct 2008)
> New Revision: 8649
>
> Modified:
>trunk/BOOK/appendices/dependencies.xml
>trunk/BOOK/chapter01/changelog.xml
>trunk/BOOK/chapter05/chapter05.xml
> Log:
> Moved the Chapter 5 M4 installation
Jeremy Huntwork wrote:
> Whichever way I look at it, it feels dirty. :/
Just as a followup, what I would suggest is:
* move m4 to a location similar to other packages in chapter 5 so that
it is linked against our temporary libs in /tools and will work
independently with /tools. (Let&#x
Chris Staub wrote:
> Another problem (not really related to this, but it does also involve
> m4) is that, as the book is now, m4 in /tools is not linked to /tools.
> Either m4 needs to be built again in /tools sometime after the toolchain
> adjustment, or the host system's m4 can be used for GCC
Bryan Kadzban wrote:
> I'd prefer to get rid of it. It wasn't there at all (since 2007 or so)
> until gcc's extra bits added it as a requirement...
I'd tend to agree, but, if it's not built at all in chapter 5, what do
you do in chapter 6 for final gcc?
--
JH
--
http://linuxfromscratch.org/ma
Chris Staub wrote:
> Bryan Kadzban wrote:
>>
>> I'd prefer to get rid of it. It wasn't there at all (since 2007 or so)
>> until gcc's extra bits added it as a requirement...
>
> You mean, don't put m4 in /tools at all, and just build it right before
> GMP in Chapter 6? Sounds like that could wor
Bruce Dubbs wrote:
> The oldest version on ftp.gnu.org is 1.4.1 dated June 2004.
The m4 on my RH 6.2 box says it's 1.4 and it seems to do fine.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Bruce Dubbs wrote:
> http://wiki.linuxfromscratch.org/lfs/ticket/2115
>
> I am starting to address the subject ticket. I propose to follow Chris'
> suggestion and move the 'Toolchain Technical Notes' section to the appendix
> between Acknowledgments and Dependencies. I will then change the
>
Hello,
First off, thanks to everyone for the comments given, they were very
helpful. Based in part on the comments, and upon my own estimation of
the project, I have a proposal to make wrt the future of the project.
I'll try to keep it as brief as possible, but here are the changes to
the goal
Hello all,
With the upgrade to gcc 4.3.2, I believe the section in the toolchain
adjustment in chapter 5 that deals with fixed includes is broken. For
those of you that have recently built with jhalfs, I'd appreciate it if
you'd look in your logs to verify that the following commands have
actu
DJ Lucas wrote:
> No, not good. Ignoring the fact that the command is broken, and no time
> to look right now, but the `dirname $(gcc
> -print-libgcc-file-name)`/include/limits.h file needs the
> ../include-fixed/syslimits.h, which includes this string. Removing the
> gcc version of limits.h
Jeremy Huntwork wrote:
> Then:
>
> root [ ~ ]# ls -l /tools/lib/gcc/i686-pc-linux-gnu/4.3.2/include-fixed/
> total 12
> -rw-r--r-- 1 root root 3470 2008-10-19 18:59 limits.h
> -rw-r--r-- 1 root root 750 2008-10-19 18:59 README
> -rw-r--r-- 1 root root 330 2008-10-19 18:5
DJ Lucas wrote:
> Jeremy Huntwork wrote:
>> The command I propose is:
>>
>> GCC_FIXED=`dirname $(gcc -print-libgcc-file-name)`/include-fixed &&
>> find ${GCC_FIXED}/* -maxdepth 0 -xtype d -exec rm -rvf '{}' \; &&
>> rm -vf `grep -l &q
Greg Schafer wrote:
> Jeremy Huntwork wrote:
>
>> I think this is the right answer. Greg, if you're reading, do you have
>> any comments to make on this topic?
>
> None at all, sorry. Next Gen build method utilizes cross compilation for
> the initial Pass 1 to
Hello,
So after some testing on a Redhat 6.2 system, I can say definitely that
our host pre-reqs are higher than they technically need to be. I'd like
to eventually drop all the below changes into the jh branch, but I just
wanted to give a little status report first, for those interested.
Firs
Bruce Dubbs wrote:
> That's interesting Jeremy, but as a minimum, I wouldn't want to make the
> changes
> for LFS 6.4. I don't think you are proposing that but I wanted to make it
> explicit.
Yes, I wasn't aiming for 6.4. As I said, these changes will be going
into the jh branch. The only thi
Ken Moffat wrote:
> On Mon, Oct 20, 2008 at 10:36:14AM -0400, Jeremy Huntwork wrote:
>> * "Gcc-3.0.1" can at _least_ become "Gcc-2.95" I don't know if you
>> want to mention "egcs-2.91.66" but it works.
>>
> Possibly, but if you have
Bryan Kadzban wrote:
> Ken Moffat wrote:
>> To me, 2.6.9 is ancient history! (4 years old). I think something
>> like 2.6.16 (purely because it is still getting long-term support
>> updates) is a better minimum, but also I think we should encourage
>> people to build a new kernel first (if they
Bryan Kadzban wrote:
[snip]
Thanks for the clarifications, they were very helpful.
> Forcing the user to build the kernel before they start may work
I would think that doing this would provide optimal build results for
glibc. If you do it after the first pass of gcc, but before glibc, then
yo
Randy McMurchy wrote:
> Anyway, it's because the headers_install process first completely
> removes everything in the target directory which would wipe out
> the stuff that is in there in Chapter 5.
>
> In Chapter 6 we could actually change it to go straight to
> /usr/include as there should be no
Bruce Dubbs wrote:
> Randy McMurchy wrote:
>> Bruce Dubbs wrote these words on 10/26/08 12:47 CST:
>>> DJ Lucas wrote:
Yeah. I forgot to bump the book version entity. I remembered around
12:35 AM CDT, but I'm not sure if it was too late to bump it.
>>> 0415 MST.
>> So, why didn't the b
Randy McMurchy wrote:
> Jeremy Huntwork wrote these words on 10/26/08 14:34 CST:
>
>> Before you go changing anything, see here:
>
> I didn't mean Bruce should actually change anything. My response was
> more on the technical side in that if it *were* changed, t
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.
ICA is in fact implemented as an optional feature of jhalfs. Which means
that when it's done building LFS by the book, it will try to build
Archaic wrote:
I'm on the fence about this one. I build a static bash and someother
static tools of which vim is one of them, for recovery needs, but I'm
not sure if the book should recommend that or install vim in /bin in the
first place. A somewhat valid argument would be sed for emergency
purpos
Steve Crosby wrote:
okay - so from Linux it is ;)
Instaling Aurora Linux now because it was handy, any other recommendations
for a host distro?
Just so happens that I'm working on a sparc install as well :) It's an
UltraSparcIIi in a Sun Netra T1 105. So far Gentoo has been working well
for me
s may cause, but hopefully you'll agree
that this is better than having "lost" posts that show up on the
newslists, but are not reflected in the mailman archives or to
email-only subscribers.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://ww
t's ready to go as well. It would nicely bring it all up-to-date
and fix a few bugs, notably, the strip bug and the 2.6.8.1 cd-writing bug.
I'd like to see a release happen now.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.o
, (the new release was
mostly just to get sysklogd back in) and as Matt just posted as well,
likely a testing phase before release would go through. I think that
should prove enough time to test the latest version of the scripts.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo
ld
like to see it listed somewhere for reference. ;)
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
#x27;ve got the book ready to change if it's deemed
that gnu.org is the better link.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Ken Moffat wrote:
Confirmed that 1.36 ran check ok, diffed it and realised this is a new
test. Google found one thread for e2fsprogs tst_ostype - the fix is at
http://www.diy-linux.org/pipermail/diy-linux-dev/2005-March/000490.html
Thanks, Greg. Did I miss the LFS editorial decision not to test
Puvi wrote:
configure: error: forced unwind support is required
See this thread:
http://archives.linuxfromscratch.org/mail-archives/lfs-hackers/2004-July/001835.html
The problem seems to lie in the way your host system is set up, though
after reading through that thread, I'm not sure if the exact
Andrew Benton wrote:
Sorry if this has been covered already, but I'm just looking at the page
7.4. Device and Module Handling on an LFS System in Linux From Scratch -
Version 6.1-testing-20050401 Chapter 7. Setting Up System Bootscripts
It has a section 7.4.3. Handling Hotpluggable/Dynamic Device
Allard Welter wrote:
At the end of the udev install it mutters:
killall udevd
udevd: no process killed
make: [install] Error 1 (ignored)
Obviously this is harmless, but perhaps somewhat disconcerting to
someone doing this the first time?
Perhaps. And noted. Thanks.
--
Jeremy H.
--
http://linuxfro
Allard Welter wrote:
Section 7.4, last sentence (grammar and spelling):
in negligable -> is negligible
>
Section 7.4.1, second paragraph (tense):
Last two sentences should be past tense again (from: The devfs file
system also suffers from race ...) unless of course these problems are
still manife
Bruce Dubbs wrote:
I would really like to find the problem and fix it however.
Bruce,
Did you ever get this sorted out? Just curious.
--
Jeremy H.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Bruce Dubbs wrote:
As an interesting note, from vim, do a :help Linux-backspace
That is exactly what I am running into.
Do you have a /etc/sysconfig/console file? Or did you leave it alone?
Guess I'm wondering if you have a keymap that needs fixing as is
mentioned here:
http://www.linuxfromscrat
Matthew Burgess wrote:
Mine's 0177 here. Is it maybe worth comparing config.log's offline?
Matt.
Likewise.
--
Jeremy H.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Bruce Dubbs wrote:
My typo. My fault. Sorry for all the effort. :((
I enjoyed it. I learned some stuff from this thread. And it's nice to
see I'm not the only one that makes silly mistakes. ;)
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
a few other general-use notes
there. Sound ok? Any ideas or suggestions as far as that goes?
Thanks,
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
text needs to be changed. It's been changed to dynamic builds
on the first pass to avoid a strip bug. We need to make an entry in
bugzilla about it...
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the
Perhaps it doesn't even need its own page (at least
with the next release or two) since not every release will be a printed
book. A good summary of the cd and a link to the cd's homepage would be
fine, perhaps in the 'How to Build an LFS System' section?
--
Jeremy Huntwork
Jeremy Huntwork wrote:
I suppose that would be fine, though I still would like to see a brief
summary about it.
Oh, and by summary, I really just mean the purpose of the cd - what it
does and why it exists. Just to give the users a reason for coming to
look at the cd and its independant page
Jeremy Utley wrote:
But there's still the lengthy community decision process to deal with
before it makes it into rendered XML. That was the whole crux of the
Unstable branch of LFS, so those of us who were interested in playing
with that stuff could do so easily. Now that's gone :( And the s
Jeremy Huntwork wrote:
Um. No... there's still the trunk branch
Did I just say 'trunk branch'? Ugh. Someone slap me upside the head
please...
--
Jeremy H.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
these comments don't come as a huge shock to the rest of the devs,
but just reading Jim's comments and thinking on how this will affect the
shape and direction of LFS and its related projects - I'm thinking maybe
we need to give some serious thought to avoiding those pitfalls
Jeremy Huntwork wrote:
In
fact, unless there is any technical benefit to rebooting into a fresh
kernel before chapter 6 on matching arch pairs, I think I'd rather see
the book continue to chroot by default and assume that the user is
building for the same arch, which would remove some o
Randy McMurchy wrote:
[EMAIL PROTECTED] wrote these words on 04/18/05 21:55 CST:
Your message did not help me understand the changes, Ryan. It came
off as a defensive, poorly phrased way of saying that building LFS
on the x86 platform is for sissys.
Ok, let's stop this right here. Are we really tha
O Mon, Apr 18, 2005 at 10:52:37PM -0500, Randy McMurchy wrote:
> Jeremy, this is a discussion. I was dismissed because I build
> x86 "biddy" builds (whatever that is). You are not a moderator,
> Jeremy, enter the discussion with something to contribute or let
> us continue it without your interfere
Jeremy Utley wrote:
Randy McMurchy wrote:
Cool!
But don't make it a hint, make it part of the book. :-)
Ideally, yes, it should be in the book. However, if for some reason
that's unfeasable, because of limitations in the XML or whatever the
case may be, then my feeling is it could be easily w
James Robertson wrote:
Education is always good IMO for the book. I always see this as a plus.
I also wanted interactive boot. I would like to see this as a feature
as well.
James!! Good to see you're still around. I was getting worried. :)
--
Jeremy Huntwork
--
http://linuxfromscratc
et Machine with New Kernel" - I know that's a bit long, but I'm open
to suggestions.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Bruce Dubbs wrote:
Boot Target System.
I like this one :)
Thanks
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
TheOldFellow wrote:
It's not a reboot, it's a boot, after a lot of faffing around to get it
on the right disk.
Right - I think in some circumstances it could be a reboot, but often it
wouldn't be. You could still choose to reboot when building a x86 > x86...
--
Jerem
gestion to unpack just the core tarball?
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
ut the separate tarballs and just keep
it to the one full package. Unless anyone has any objections, I'll be
doing that shortly.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
x27; \
gcc/Makefile.in
This sets the directory searched by the fixincludes process for
system headers, so it won't look at the hosts.
This can go just after the cppdefaults edit
Done, thanks.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfrom
Archaic wrote:
I don't hear any objections, I'm going to merge it into testing as well.
I object to objections!!
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
-lfs you can
always try to decipher Ryan Oliver's scripts yourself:
svn co svn://be-linux.org/cross-lfs/cross-lfs/trunk cross-lfs
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Erik-Jan wrote:
Hi there,
In cross-LFS, chapter 5.10 Glibc-2.3.5, configure, the book says:
--host=${LFS_HOST} --build=${LFS_TARGET}
Shouldn't that be the other way around?
--host=${LFS_TARGET} --build=${LFS_HOST}
You are correct, and it has been fixed, sorry for the delay.
--
Jeremy Hun
Norman J Heckscher wrote:
steve crosby wrote:
> The question is, with the new multi-choice cross-lfs book being worked
> on, how are we planning on producing a hardcopy version? Questions
> regarding the "linear" flow of the book are resolved by using smart
> XML processing, but I've yet to see
implied, likely because I haven't done any other cross-compiling on
this machine save for what the cross-lfs book does.
I'm not sure that this is a major concern - however I too would prefer
to see that it *always* find the libgcc_s.so in /cross-tools
I'll add your sed into the n
e are likely to be different opinions on this one,
but I wanted to put this forward for comments. Personally, it would make
me feel much more comfortable with where we're leading the reader.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
at it will answer a few questions about what
cross-lfs is and aims to be, making it possible for more to get involved
or interested in the book, offer comments, suggestions, etc.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
U
ed on.
See the other thread I just started, "Successful Build of Cross-LFS"
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
ts added to the auto-render scripts alongside the
other LFS books. Test the builds, submit errors, suggestions, etc.
Thanks!
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
right now, there wouldn't be much information in the book
to help you with x86_64, but that's just about next on our list of
things to implement. Thus, we'll need the help of testers and people
who have already successfully built on x86_64.
HTH,
--
Jeremy Huntwork
--
http://linuxfr
ts?
Thanks,
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
M.Canales.es wrote:
El Viernes, 6 de Mayo de 2005 17:34, Jeremy Huntwork escribió:
Nothing impossible, I think, but very difficult to implement.
Ok. Thanks Manuel for responding on that. :) Perhaps it's best then, to
leave this idea to mature for a while and re-visit it once we have the
u have an opinion or comment on the above,
*please* reply here. We *need* your feedback in order to make a decision.
Thanks!
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Matthew Burgess wrote:
Jeremy Huntwork wrote:
So, in a nutshell, my opinion is that we should do multilib as a
default for 64-bit archs with /lib and /lib64 directories.
Care to explain the basis on which you're forming that opinion for those
of us paupers not able to afford such e
M.Canales.es wrote:
Is there some "de facto" standard used by commercial distros?
Not sure. I just grabbed a gentoo stage3 tarball for amd64 and it seems
they have it layed out like this:
/lib -> /lib64
/lib32
/lib64
/usr/lib -> lib64
/usr/lib32
/usr/lib64
--
Jeremy
ng Virtual Kernel File Systems" the part with
creating the directories is missing. Please add 'mkdir -p
$LFS/{proc,sys}' to the document.
Fixed. The book is rendering now, so if you refresh that page in a few
minutes, you should see the change.
Thanks for the report.
-
for others to review it and comment
where appropriate.
Matt, Gerard, any objections?
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Matthew Burgess wrote:
Jeremy Huntwork wrote:
Matt, Gerard, any objections?
None at all, it's been on my TODO for ages, so I'd be glad for anyone to
commit anything to it at the moment :)
Great. :) Ok, just committed my changes and will start looking at the
text. (Commit was too lar
M.Canales.es wrote:
Many thanks for start that work :-)
No problem, I sure could use your help though ;)
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
sting where necessary, this ppc book is
fairly new.
I'll look over your comments and make the changes as I have a free minute.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
o, I hope.
Sounds fair enough...
Though if we have a multilib book and a uni-arch book, we can cater for
both straight64 and multilib...
Let me get at least the first way down and in book form and we'll see
what happens after that. ;) Can't really comment on your XML ideas
because I&#x
here.
Matt, Gerard, can you guys look over what I have there and start making
edits or, at the very least, post changes here so I can make them?
Again, the book is rendered here for your convenience:
http://linuxfromscratch.org/~jhuntwork/editor-manual/
Thanks,
--
Jeremy Huntwork
--
http://
# of the GNU General Public License as published by the Free Software
# Foundation; either version 2 of the License, or (at your option) any later
# version.
# --- T2-COPYRIGHT-NOTE-END ---
Thanks,
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linu
l the horizontal and the vertical! (and the mini!) :D
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
described there. If you want, I can describe the current layout, etc.
Sounds good to me. :) Thanks, Justin.
--
Jeremy Huntwork.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
hough.
I, for one, would like to see the cross-lfs book take this type of layout.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
.
--disable-multilib? or --enable-multilib=no? Is there a difference?
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
). The other
is the set of commands to run if one of those args is passed.
These expressions receive an $enableval variable. If --disable-X is
passed, then $enableval is equal to no. If --enable-X=blah is passed,
then $enableval is equal to blah.
Nice. Thanks for the explanation, Bryan. :)
--
Jeremy
-m32 tag appended to the CC variable. It was thought that if
we could have the user define the gcc tags needed to build for 32 or 64
in the book for each arch, we could generalize the pages more and keep
it less arch specific. How does the community feel about this?
--
Jeremy Huntwork
--
http
on't see why we couldn't do that.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Hey all,
I've just put up a new livecd iso. This is version x86-6.1-1-pre3. There
are still a few known missing items that we will put in the next iso,
and hopefully that one will be a release candidate. However, there are
some substantially new features with this cd, so we wanted to give the
Jeremy Huntwork wrote:
ftp://ftp.lfs-matrix.net/pub/lfs-livecd/lfslivecd-x86-6.1-1.pre3.iso
Grr.
A small typo in that url above:
Should be:
ftp://ftp.lfs-matrix.net/pub/lfs-livecd/lfslivecd-x86-6.1-1-pre3.iso
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http
Matthew Burgess wrote:
Jim/Jeremy, could you audit all occurences of 'sed' prior to chapter
6.17 (sed-4.1.4 installation) and remove the '-i' flag please? Either
that or we need to have modern 'sed' built really early on.
I'll keep that in mind and work it in as I make other edits, if that'
ention, I'll fix it in
just a minute.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Jeremy Huntwork wrote:
Actually, we do have it correct, (look at the sparc64 book), but
apparently the x86 book was mangled a little bit with our recent
re-structuring. Thanks for bringing this to my attention, I'll fix it in
just a minute.
There. Take a look:
http://linuxfromscratc
Matthew Burgess wrote:
Jeremy Huntwork wrote:
Well then, we need to fix the LFS rules file because the cd just uses
the default rules from that. No changes have been made.
Hmm, kinda shot myself in the foot there didn't I!
bash-3.00$ ls -l /dev/input/*
crw-r--r-- 1 root root 13, 63 20
John Profic wrote:
I'm continue trying to build lfs by intructions from cross-lfs on x86_64.
Currently I finish temp-tools part, and have some notices:
1) Gcc, compiled by instructions from cross-lfs-x86 uses /lib64 even
build with enable-multilib=no, so no one just compiled program cannot
run
LFS without flex and
build as many BLFS packages as possible too. Perhaps give that new BLFS
profile for nALFS a test all at once. :)
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
John Profic wrote:
Sorry, for confusion, but I mean book titled i386/x64_64 not standalone
x86_64 (which I notice is *broken* :))
You mean this one?
http://linuxfromscratch.org/~jhuntwork/cross-lfs/x86/
If so, the title for that one is 'Intel/AMD x86' and it's assumed that
you're building 32-
Bruce Dubbs wrote:
There are more developers for LFS than for BLFS, but the package count
is about 6 to 1 in favor of BLFS.
Actually, I don't think there are more for LFS atm. But your point is
still valid.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxf
David Jensen wrote:
I'm guessing current development has moved to fsf, but the download link
is still to kernel.org which i think is hjl?
It should be fixed?
Fixed. Thanks for that, David.
--
Jeremy Huntwork
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ:
Archaic wrote:
In an attempt to get this info both archived, and presented to the
larger community, I am writing up a synopsis of ideas that have been
floating around on IRC as to how to handle the chroot/reboot phase of
the cross-lfs book. I will list them and give a brief pro/con for each
as I
Jim Gifford wrote:
Matt, that was one of the purposes of the cross-lfs was the
multi-architecture build, the reboot section is needed. I have it
working and have been making the changes. It's just at the reboot point
where there seems to be an issue.
I think that's what he was saying - Keep i
TheOldFellow wrote:
> I must start by saying that I have not been interested enough in this
thread to have read every contribution in detail.
Having built a couple of POX86S (plain old X86 system) with cross-lfs
instructions, I've decided to take a copy of the latest svn
non-cross-lfs book and
901 - 1000 of 1449 matches
Mail list logo
