Jeremy Huntwork wrote these words on 01/30/06 19:25 CST:
> Where would the right place be? Since, as Dan said, we have a whole
> Stripping section later in the book, this would kinda be pointless
> unless we drop that section.
We are talking about Chapter 5 right? I looked and the -s flags are
on
Bruce Dubbs wrote:
> Perhaps its not the right place, but passing the -s or --strip-all flag
> to ld seems to be an interesting educational example.
Where would the right place be? Since, as Dan said, we have a whole
Stripping section later in the book, this would kinda be pointless
unless we drop
Jeremy Huntwork wrote:
> Dan Nicholson wrote:
>
>> On 1/29/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
>>
>>> So. Exepect a commit in ~ 5 minutes.
>>
>>
>> Anyway, since we're not passing -s anywhere else in the book, then it
>> shouldn't be passed here for consistency. Or, it should be added
Dan Nicholson wrote:
On 1/29/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
So. Exepect a commit in ~ 5 minutes.
Anyway, since we're not passing -s anywhere else in the book, then it
shouldn't be passed here for consistency. Or, it should be added to
everything and we can drop the Stripping s
Dan Nicholson wrote:
I'm issuing a standing 8 count. How many fingers am I holding up?
How did you get 23 fingers?
Maybe you could use one of those "Hang in there, kitty" posters right now.
Hehe. Um, no thanks. This email was good enough. ;)
--
JH
--
http://linuxfromscratch.org/mailman/l
On 1/30/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
>
> *sigh* I suppose the right thing to do here is pick myself up and try
> again. But I'm getting pretty bruised. :/
I'm issuing a standing 8 count. How many fingers am I holding up?
Maybe you could use one of those "Hang in there, kitty" p
Dan Nicholson wrote:
The LDFLAGS="-s" won't hurt anything since it's the strip all symbols
input parameter for ld. From ld --help:
-s, --strip-all Strip all symbols
Oh, duh. Good catch, Dan. Since I started working with this I kept
seeing it and remembering it as the option fo
On 1/29/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
>
> So. Exepect a commit in ~ 5 minutes.
Sorry, one more nit, though this has to do with Binutils-Pass 1 & 2.
I didn't notice it until it was rendered today.
Currently, the make command on the rebuild has
make LDFLAGS="-s" LIB_PATH="/new/pa
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:
> 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
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
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
25 matches
Mail list logo
