Dan Nicholson wrote:
>>I also ended up with multiple copies of the compilers (not symlinked) as in:
>>g++
>>i686-pc-linux-gnu-g++
>>(IIRC, there were 3 variants for g++ all the same size, a couple gcc, ..)
>
> That seems normal to me. On my current system I have
>
> $ ls -l /usr/bin/*{c,g}++
>
On Saturday 18 February 2006 21:29, Dan Nicholson wrote:
> On 2/18/06, Jeremy Herbison <[EMAIL PROTECTED]> wrote:
> > > If you want to keep testing after this, I suggest changing the test to
> > >
> > > grep "/usr/.*/crt.*" dummy.log
> > >
> > > Because we really just want to make sure it's not loo
On 2/18/06, Jeremy Herbison <[EMAIL PROTECTED]> wrote:
> > If you want to keep testing after this, I suggest changing the test to
> >
> > grep "/usr/.*/crt.*" dummy.log
> >
> > Because we really just want to make sure it's not looking in /tools
> > anymore.
>
> Okay, and that works fine. Should cha
Dan Nicholson wrote:
On 2/18/06, Jeremy Byron <[EMAIL PROTECTED]> wrote:
I get the 'Requesting program interpreter: /lib/ld-linux.so.2,' 'attempt
to open /lib/libc.so.6 succeeded,' and 'found ld-linux.so.2 at
/lib/ld-linux.so.2' lines but not the 'attempt to open /usr/lib/crt?.o
succeeded' lines
> If you want to keep testing after this, I suggest changing the test to
>
> grep "/usr/.*/crt.*" dummy.log
>
> Because we really just want to make sure it's not looking in /tools
> anymore.
>
> --
> Dan
Okay, and that works fine. Should change the text in ch6 gcc though
because it suggests re-
On 2/18/06, Jeremy Herbison <[EMAIL PROTECTED]> wrote:
>
> Getting the same thing here on my scripted builds... the ch.6 sanity checks
> pass, but after building ch.6 gcc and then redoing the tests, the
>
> grep "/usr/lib/crt.* " dummy.log
>
> test doesn't find anything.
As I said in the o
On 2/18/06, Jeremy Byron <[EMAIL PROTECTED]> wrote:
>
> I get the 'Requesting program interpreter: /lib/ld-linux.so.2,' 'attempt
> to open /lib/libc.so.6 succeeded,' and 'found ld-linux.so.2 at
> /lib/ld-linux.so.2' lines but not the 'attempt to open /usr/lib/crt?.o
> succeeded' lines.
>
> If I cha
> I assume neither the presence of /../../../ nor the additional
> compilers is really a problem, I've just never noticed them before. The
> /../../../ certainly isn't necessary and I wouldn't think the multiple
> copies are either. When I stumbled upon this in the final ch6 sanity
> check, I fig
Matthew Burgess wrote:
/tools/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../../i686-pc-linux-gnu/bin/ld:
Sorry for the noise if this is my own doing, but the above line caught
my eye.
I just finished building the latest svn and noticed much the same after
installing GCC in ch6. Running the san
On 2/18/06, Matthew Burgess <[EMAIL PROTECTED]> wrote:
> Dan Nicholson wrote:
>
> > I believe you may have inadvertantly left the --enable-shared in the
> > configuration of binutils-pass2.
>
> And so right you are. The switch was indeed in my scripts, and I've
> just seen r7308 which took it out.
Dan Nicholson wrote:
I believe you may have inadvertantly left the --enable-shared in the
configuration of binutils-pass2.
And so right you are. The switch was indeed in my scripts, and I've
just seen r7308 which took it out. I'll kick off another build
tomorrow, but am pretty confident th
On 2/18/06, Matthew Burgess <[EMAIL PROTECTED]> wrote:
>
> Now, the only odd thing I've noticed is that after building
> binutils-pass2 in chapter 5, ld-new (which gets copied to /tools/bin/ld
> then symlinked to /tools/i686-pc-linux-gnu/bin/ld) is a shell script, as
> opposed to a binary (ld is an
12 matches
Mail list logo
