On Sun, 2006-01-29 at 19:25 -0600, Randy McMurchy wrote:
>
> I was just hoping that there could be a good discussion. And when
> someone (especially one of Greg's stature in the toolchain foodchain
> ladder) says something is bad, and gives what sounds like good reasons
> (I am not qualified to ag
Dan Nicholson wrote:
> In the adjustment, though, he uses `gcc -dumpmachine`, though. This
> is probably wise since you don't know what MACHTYPE is from the host's
> bash. In fact, this might be a good idea for both adjustments. I
> don't know how reliable MACHTYPE is, but I'm speculating since
On 1/29/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Jeremy Huntwork wrote:
>
> > +mv -v /tools/bin/{ld,ld-old}
> > +mv -v /tools/$MACHTYPE/bin/{ld,ld-old}
> > +mv -v /tools/bin{ld-new,ld}
> > +ln -v /tools/bin/ld /tools/$MACHTYPE/bin/ld
>
> Any reason why something similar can't be done for th
Jeremy Huntwork wrote:
> +mv -v /tools/bin/{ld,ld-old}
> +mv -v /tools/$MACHTYPE/bin/{ld,ld-old}
> +mv -v /tools/bin{ld-new,ld}
> +ln -v /tools/bin/ld /tools/$MACHTYPE/bin/ld
Any reason why something similar can't be done for the first pass of
binutils? I forgot about that one.
--
JH
--
http://
Dan Nicholson wrote:
> My fault, I missed the > in the xml. It works as you say, even
> running it repeatedly. It would make sense to drop the -i anyway,
> though. We're not actually supplying perl with a file for the -i.
Yep, agreed. I think the -i is a leftover from stable where we *are*
edi
On 1/29/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
>
> We're covered, because I do this first:
>
> mv -v /tools/$MACHTYPE/bin/{ld,ld-old}
Yeah, sorry. Missed that one.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See th
On 1/29/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
>
> It doesn't fail. I've tested it again here and it's fine. Try directing
> it to a temporary location that you know doesn't exist, and look at the
> finished product.
>
> gcc -dumpspecs | \
> perl -pi -e 's@/tools/lib/ld@/lib/[EMAIL PROTECTE
Dan Nicholson wrote:
> Now that I think about this more, the pipe and redirect *without* -i
> is much better. This way, you're always editing starting from the
> default -dumpspecs instead of editing the existing file. Then you can
> run the command as many times as you want. You don't have to w
Dan Nicholson wrote:
> And another. We're trying to make a symbolic link at
> /tools/$MACHTYPE/bin/ld, but a file already exists there. It seems
> we'd need to add -f to the ln statement:
>
> ln -svf /tools/bin/ld /tools/${MACHTYPE}/bin/ld
>
> or it'll fail with a File exists error.
Look at th
Dan Nicholson wrote:
> Hey, Jeremy, just a little nit. The new specs readjustment will fail
> because we're piping input to perl, but then using the -i parameter to
> work on the `dirname ...`/specs file. This fails if that file doesn't
> exist. Probably, we should drop -i and redirect the outpu
On 1/29/06, Dan Nicholson <[EMAIL PROTECTED]> wrote:
> On 1/29/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> >
> > So. Exepect a commit in ~ 5 minutes.
>
> Probably, we should drop -i and redirect the output:
Now that I think about this more, the pipe and redirect *without* -i
is much better.
On 1/29/06, Dan Nicholson <[EMAIL PROTECTED]> wrote:
> On 1/29/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> >
> > So. Exepect a commit in ~ 5 minutes.
>
> Hey, Jeremy, just a little nit.
And another. We're trying to make a symbolic link at
/tools/$MACHTYPE/bin/ld, but a file already exists th
On 1/29/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
>
> So. Exepect a commit in ~ 5 minutes.
Hey, Jeremy, just a little nit. The new specs readjustment will fail
because we're piping input to perl, but then using the -i parameter to
work on the `dirname ...`/specs file. This fails if that fil
Randy McMurchy wrote:
> Could you point me to that post where Ryan refuted some of Greg's
> points? I saw a post where Ryan described why a particular method
> was good, but from the best I could tell, didn't address any of
> Greg's points why a method was bad.
So far, Ryan has given us the most
Jeremy Huntwork wrote these words on 01/29/06 19:13 CST:
> Ryan did that already.
Could you point me to that post where Ryan refuted some of Greg's
points? I saw a post where Ryan described why a particular method
was good, but from the best I could tell, didn't address any of
Greg's points why a
Randy McMurchy wrote:
> Should we not wait until there is *some* sort of explanation by
> somebody about Greg's points? Jeremy, since you've taken it upon
> yourself to take lead in this, could you address some of Greg's
> points, please?
Ryan did that already. Or haven't you read what he said? P
Jeremy Huntwork wrote these words on 01/29/06 18:47 CST:
> Right. And, again, we're familiar with the spec. We have used it; *are*
> using it in stable and cross-lfs. Our tests and experience are based on
> it. To introduce a new method now would also mean we're introducing a
> whole new thing to
Hi all,
As discussed, I'm proposing to implement a new section to the "Notes on
Building Software" part of Chapter 2. The section could be titled
"Automation Procedures for Building BLFS Packages", or something similar.
Then, removing the automated agreeing to the licenses in the three Sun
package
Dan Nicholson wrote:
> The way I see it, both ways achieve the desired effect of finding the
> startfiles and libraries in /usr/lib. It's out of mine (and most
> people's) jurisdiction to say which one is technically more accurate
> although both Greg and Ryan have done some nice education here.
On 1/29/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
>
> I have given some major thought to this. And I waited to hear comments.
> I think at this point, everyone that wanted to, or is able to comment,
> has done so.
The way I see it, both ways achieve the desired effect of finding the
startfile
Ryan Oliver wrote:
> When you are doing an old style cross-toolchain build
Nobody sane uses old style cross-toolchain build procedures these days :-)
> (ie: not using a sysroot, all target libraries and includes installed
> under /prefix/target/lib /prefix/target/lib64
> /prefix/target/{include
On 1/28/06, Ryan Oliver <[EMAIL PROTECTED]> wrote:
> On Sat, 2006-01-28 at 14:36 -0800, Dan Nicholson wrote:
> >
> > Um, the decision might be made for us:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00507.html
>
> Yup, and its still there 1 year later.
Oops, sorry. I thought that post w
Ryan Oliver wrote:
G'day Ryan, good to see you alive and kicking on the list :-)
Unfortunately, all you've done is told us why you don't like -B. You
haven't addressed the core issue of this thread ie: startfile_prefix_spec.
We'd all appreciate it if you could address the concerns that I've rai
Greg Schafer wrote:
> Personally, I don't believe in it and will never use it because:
>
> - the spec is faulty. It doesn't work when placed into an external file
>for use by "gcc -specs=..." (luckily LFS is not using it externally).
>Every other spec I've tried works properly when place
Alexander E. Patrakov wrote:
> Bryan Kadzban wrote:
>
>> This is NOT safe if either of those library files are currently
>> linked into any process that's running!
>>
> They are not used. Certainly :)
>
> The used file may be /lib/libncursesw.so.5 (which is a symlink
> pointing to 5.5).
If it's
Dan Nicholson wrote:
> We should also think about what happens when crtbegin.o and crtend.o
> come under /usr after gcc is installed since the answer you get will
> not be the same as shown in the book.
>
> In this case, the following regex will always return what's in the book.
>
> grep "/usr/.
Jeremy Huntwork wrote:
> Thank you Ryan. When I asked you several times before to give technical
> reasons why we should use the *startfile_prefix_spec, *this* is what I
> was after. Nothing so concise existed in previous threads.
I have given some major thought to this. And I waited to hear comm
On 1/28/06, Chris Staub <[EMAIL PROTECTED]> wrote:
> Before you
> install GCC into /usr, the check for "/usr/lib/crt.*" will work, but
> after you do it will not because GCC will actually be using
> "/usr/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../crt1.o"
Good catch, Chris. What about
grep "/usr/.
Bryan Kadzban wrote:
Chris Staub wrote:
The Chapter 6 ncurses instructions in the LFS dev book have this
construction:
for lib in curses ncurses form panel menu ; do \
rm -vf /usr/lib/lib${lib}.so ; \
echo "INPUT(-l${lib}w)" >/usr/lib/lib${lib}.so ; \
ln -sfv lib${lib}w
Ryan Oliver wrote:
[snip]
> Which method do you want to use to link in the correct startfiles
> 1: misuse the -B flag, overriding GCC_EXEC_PREFIX and setting isystem et
> al
> 2: set the location of the startfiles in the spec provided just for this
> purpose.
Thank you Ryan. When I asked you sev
Chris Staub wrote:
> The Chapter 6 ncurses instructions in the LFS dev book have this
> construction:
>
> for lib in curses ncurses form panel menu ; do \
> rm -vf /usr/lib/lib${lib}.so ; \
> echo "INPUT(-l${lib}w)" >/usr/lib/lib${lib}.so ; \
> ln -sfv lib${lib}w.a /usr/lib
Hi, all!
I'm joining the effort started here:
http://linuxfromscratch.org/pipermail/lfs-dev/2006-January/055025.html
Current setup: LFS+6.1.1 (but with old LFS-6.0 bootscripts).
Upgrades:
kernel-2.6.15.1
udev-081
Jim's udev rules: http://ftp.jg555.com/udev/udev-cross-lfs.tar.bz2
The way I work:
32 matches
Mail list logo
