in Chapter 7. If You Are Going to Boot, I get a
-gcc not found error, upon closer inspection I see a ${TARGET} in the
make command which I don't believe exists. I changed it to
${LFS_TARGET} and everything seemed happy.
-Doug
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://w
On 8/11/05, Dermot Bradley <[EMAIL PROTECTED]> wrote:
> It hit the same problems as a few other people with building uClibc HLFS
> Development version - shadow 4.0.11.1 gave problems with login_pam
> (innetgr) and then with missing l64a code in uClibc.
>
I was one of those people ... I'll test it
On 8/11/05, Jim Gifford <[EMAIL PROTECTED]> wrote:
> Please give me any details you can so I can help diagnose your issue.
> Here are some of the questions that I use to trouble shoot these issues.
>
> What does LFS_TARGET, LFS_TARGET32, and LFS_HOST show?
> What is your host architecture?
> What
Please give me any details you can so I can help diagnose your issue.
Here are some of the questions that I use to trouble shoot these issues.
What does LFS_TARGET, LFS_TARGET32, and LFS_HOST show?
What is your host architecture?
What is your host distro?
Was there any error message with the gcc
Linux From Scratch - Version 7.0-cross-lfs-20050811-x86_64
When configuring Glibc-2.3.5 for the first time , I get an error
saying that it couldn't compute the sizeof a long int. The file that
it failed was looking for crt1.o wich apparently doesn't appear until
after you build
On Thu, Aug 11, 2005 at 06:48:20PM +0200, M.Canales.es wrote:
>
> Then, at least for consistency, I will prefer an homogeneous solution for all
> archs. If that implies to build some 32 bits tools to can compile the
> bootloaders, go for it.
We still can't achieve one bootloader for all arches
My current conclusion is that my clock problem is something more
serious than just a drift (the system clock gains a lot, and not
constant amounts), maybe involving acpi, timers (hpet++), rtc,
interrupts and whatnot, all of which I have just a limited
understanding.
(Probably not much of an LFS-i
Jeremy Huntwork wrote:
In the chapter 6 build of gcc there are two symlinks made after 'make
install':
ln -s ../usr/bin/cpp /lib
ln -s gcc /usr/bin/cc
The LiveCD scripts currently error out because those commands fail. It
appears that make install already does this, but again, I haven't looked
El Miércoles, 10 de Agosto de 2005 23:18, Jim Gifford escribió:
> I've been working on our cross-lfs build methods quite a bit lately, but
> have ran into some dead ends when it comes to the bootloaders for all
> the architectures we support. None of them will build properly on a Pure
> 64 bit syst
On Thu, Aug 11, 2005 at 11:32:26AM -0500, Randy McMurchy wrote:
> Jeremy Huntwork wrote these words on 08/11/05 10:58 CST:
>
> > Is someone in a position to verify that those symlinks are still
> > necessary?
>
> I believe the commands to create those symlinks are still necessary.
>
> My build s
Jeremy Huntwork wrote these words on 08/11/05 10:58 CST:
> Is someone in a position to verify that those symlinks are still
> necessary?
I believe the commands to create those symlinks are still necessary.
My build script uses 'ln -v -s' *not* ln -v -sf, and I log everything.
The install.log sho
On Thu, Aug 11, 2005 at 09:58:02AM -0600, Jeremy Huntwork wrote:
> ln -s ../usr/bin/cpp /lib
> ln -s gcc /usr/bin/cc
>
> The LiveCD scripts currently error out because those commands fail. It
> appears that make install already does this, but again, I haven't looked
Rereading what I said, I can s
Heya,
I've encountered a minor error when testing the latest LiveCD scripts and
I'm trying to track down if this is an error in LFS trunk or if it's a
problem with our scripts.
In the chapter 6 build of gcc there are two symlinks made after 'make
install':
ln -s ../usr/bin/cpp /lib
ln -s gcc /us
Richard A Downing wrote:
> Bruce Dubbs wrote:
>
>
>>Do you mean something like this? :)
>>
>
>
>
> Horrible! :-)
>
> Seriously, I'm sure it works for you, but everyone should roll their own
> (Here Richard seeks to dominate the world with his own opinion - as
> usual :). I see LFS as teach
> I believe you are correct, but I'd have to direct this back to Nathan.
> If you want to add it for yourself, it's real easy three
> lines in killproc:
Could you give some line numbers for that patch? :) Sorry, I'm just not
QUITE sure where to put them. :)
Dave
--
http://linuxfroms
Matthew Burgess wrote:
> Archaic wrote:
>
>> That just seems silly. Warn was much nicer and still allowed things to
>> proceed.
>
>
> Can we not still warn, but just leave the exit status as '0'. The spec
> (from the quote given) doesn't appear to forbid output, it just mandates
> what the exit
Matthew Burgess wrote:
> Archaic wrote:
>
>> That just seems silly. Warn was much nicer and still allowed things to
>> proceed.
>
>
> Can we not still warn, but just leave the exit status as '0'. The spec
> (from the quote given) doesn't appear to forbid output, it just mandates
> what the exit
17 matches
Mail list logo
