On 3/22/06, Richard Melville <[EMAIL PROTECTED]> wrote:
>
> readelf -l /tools/bin/gcc | grep 'ld-linux'
>
> The output is /lib/ld-linux.so.2 rather than /tools/lib/ld-linux.so.2.
> Is this the problem, and if so how could it have happened?
Richard,
Please try to reply to the previous email. Each
OK, I pretty stumped. One last thing. Make sure that gcc itself is
actually linked correctly.
readelf -l /tools/bin/gcc | grep 'ld-linux'
This should be /tools/lib/ld-linux.so.2 or obviously it won't
reference the correct location in the chroot.
--
Dan
The output is /lib/ld-linux.so.2 rathe
On 3/22/06, Richard Melville <[EMAIL PROTECTED]> wrote:
> OK. How about trying those commands outside the chroot. Then they'll
> be able to run, and we should be able to see what's happened.
>
> This is the output from the souped-up sanity check outside the chroot:-
OK, I pretty stumped. One l
OK. How about trying those commands outside the chroot. Then they'll
be able to run, and we should be able to see what's happened.
--
Dan
This is the output from the souped-up sanity check outside the chroot:-
[requesting program interpreter: /tools/lib/ld-linux.so.2]
attempt to open /tools/
On 3/22/06, Richard Melville <[EMAIL PROTECTED]> wrote:
>
> Third, let's try a souped up sanity check similar to the one in the SVN book.
> http://www.linuxfromscratch.org/lfs/view/development/chapter06/readjusting.html
>
> echo 'main(){}' > dummy.c
> cc dummy.c -Wl,--verbose &> dummy.log
>
> reade
On 3/22/06, Richard Melville http://linuxfromscratch.org/mailman/listinfo/lfs-support>> wrote:
/
/>/ The sanity check fails, as does gcc -dumpmachine. However, if I exit
/>/ the chroot environment and run the sanity check again, all is well. The
/>/ sanity check returns /tools/lib/ld-linux.so
On Wed, 22 Mar 2006, Richard Melville wrote:
Inside the chroot environment dummy.c will not compile and returns
*/tools/bin/cc: no such file or directory*, but it does, in reality, exist.
From outside chroot, 'ldd /tools/bin/gcc' - this sounds as if gcc is
linked against a library on the ho
On 3/21/06, R. Giskard <[EMAIL PROTECTED]> wrote:
> >From: "Henry christenson" <[EMAIL PROTECTED]>
> >
> >im pretty sure this is a problem with redhat but im wondering if there
> >is a work around. Primarly because there is a limited source of
> >x86_64 operating systems.
> >
> >there are others b
/ Chapter 5 seems to have built OK, but glibc, the first package to be
/>/ compiled in chapter 6,
/>/ fails to configure, complaining that there is no such file as
/>/ /tools/bin/gcc, when there clearly is.
/>/
/>/ The sanity check fails, as does gcc -dumpmachine. However, if I exit
/>/ the c
On 3/22/06, Nikolai <[EMAIL PROTECTED]> wrote:
> The first one is that I can't make bash warp the lines. When I type a
> command that is longer than the terminal width (or sometimes I don't
> even need to reach the screen edge), instead of continuing on the next
> line bash starts to overwrite the
On 3/22/06, Richard Melville <[EMAIL PROTECTED]> wrote:
>
> The sanity check fails, as does gcc -dumpmachine. However, if I exit
> the chroot environment and run the sanity check again, all is well. The
> sanity check returns /tools/lib/ld-linux.so.2 and gcc -dumpmachine
> returns i686-pc-linux-
>Chapter 5 seems to have built OK, but glibc, the first package to be
>compiled in chapter 6,
>fails to configure, complaining that there is no such file as
>/tools/bin/gcc, when there clearly is.
>
>The sanity check fails, as does gcc -dumpmachine. However, if I exit
>the chroot environment an
Richard Melville escreveu:
Hi
I'd really appreciate some help from somebody. I'm trying to build
LFS 6.1 with errata.
Chapter 5 seems to have built OK, but glibc, the first package to be
compiled in chapter 6,
fails to configure, complaining that there is no such file as
/tools/bin/gcc, when
Hi
I'd really appreciate some help from somebody. I'm trying to build LFS
6.1 with errata.
Chapter 5 seems to have built OK, but glibc, the first package to be
compiled in chapter 6,
fails to configure, complaining that there is no such file as
/tools/bin/gcc, when there clearly is.
The san
The first one is that I can't make bash warp the lines. When I type a
command that is longer than the terminal width (or sometimes I don't
even need to reach the screen edge), instead of continuing on the next
line bash starts to overwrite the first one. And if I backspace or
delete any charach
On 3/22/06, Kevin Monceaux <[EMAIL PROTECTED]> wrote:
> The install wrapper can't change the ownership of a file or change the
> setuid/setgid settings of a file. Part of it's job is to strip those
> options from the install parameters passed to it and then hand everything
> else over to /usr/bin/
On Wed, Mar 22, 2006 at 10:48:09AM +0100, Luca Dionisi wrote:
> I think the real problem is that /bin/su is owned by Shadow. It must be
> owned by root, else the setuid flag is useless.
> You have to do from root:
> chown root /bin/su
> chmod 4555 /bin/su
> I don't think that the wrapper of ins
On 3/22/06, Kevin Monceaux <[EMAIL PROTECTED]> wrote:
> through building LFS 6.1.1 also. The Package User install wrapper should
> have taken care of any setuid and/or setgid problems.
>
> >4. PATH = /bin:/usr/bin:/sbin:/usr/sbin:/tools/bin
>
> That might be the problem. A Package User's path
18 matches
Mail list logo
