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
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 sin
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
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
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
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
On Sat, 2006-01-28 at 14:36 -0800, Dan Nicholson wrote:
> On 1/27/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19353
> >
> > Our longtime Toolchain Maintainer, Ryan Oliver, still prefers to use
> > this method.
>
> Um, the decision might be mad
On Sat, 2006-01-28 at 08:32 -0800, Dan Nicholson wrote:
> On 1/27/06, Greg Schafer <[EMAIL PROTECTED]> wrote:
> > Ever looked at a build log of GCC itself? Guess what? -B.
>
> /tools/src/build/gcc-build/gcc/xgcc -B/tools/src/build/gcc-build/gcc/
> -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux
On Sat, 2006-01-28 at 13:07 +1100, Greg Schafer wrote:
> Jeremy Huntwork wrote:
>
> > Isn't using -B to find libraries an abuse as well?
>
> Huh? Using a documented switch for a documented purpose?
> RTFM :-)
>
The purpose of the -B flag is to override GCC_EXEC_PREFIX, the path the
gcc driver u
On 1/27/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19353
>
> Our longtime Toolchain Maintainer, Ryan Oliver, still prefers to use
> this method.
Um, the decision might be made for us:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00507.html
Spec
On 1/27/06, Greg Schafer <[EMAIL PROTECTED]> wrote:
> Ever looked at a build log of GCC itself? Guess what? -B.
/tools/src/build/gcc-build/gcc/xgcc -B/tools/src/build/gcc-build/gcc/
-B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ ...
Seems gcc thinks it's OK to search for libraries wi
Matthew Burgess wrote:
> In the interests of getting this issue off your/our plates I'd say we
> choose whatever method is most suited to LFS as it is now. That is,
> whichever works on x86 native compilations and is officially
> supported/documented upstream. Yes, I understand people's desires t
Greg Schafer wrote:
IMHO multilib is quite complicated. I cannot say anything authoritative
about it because I personally haven't had a need for it and therefore
haven't researched or tested it. That'll change if someone sends me an
AMD64 box :-)
Get a free (but slow) x86_64 box either from h
Jeremy Huntwork wrote:
Obviously '-B' works for you, and obviously, Ryan's methods work for
him. Is there a 'best for LFS' in all of that?
In the interests of getting this issue off your/our plates I'd say we
choose whatever method is most suited to LFS as it is now. That is,
whichever work
Jeremy Huntwork wrote:
> Obviously '-B' works for you, and obviously, Ryan's methods work for
> him. Is there a 'best for LFS' in all of that?
When in doubt, play the multilib card! :-)
But seriously, I dunno. I fail to see how you can equate the 2. Comparing
cross compilation to native compilat
Greg Schafer wrote:
> Jeremy Huntwork wrote:
>
>
>>Isn't using -B to find libraries an abuse as well?
>
>
> Huh? Using a documented switch for a documented purpose?
> RTFM :-)
:/ I have read the man pages on gcc. I was asking for a bit more, if you
have it. The problem comes in the form that w
Jeremy Huntwork wrote:
> Isn't using -B to find libraries an abuse as well?
Huh? Using a documented switch for a documented purpose?
RTFM :-)
Regards
Greg
--
http://www.diy-linux.org/
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe
Greg Schafer wrote:
> Not exactly. That bug report is about startfile_prefix_spec being a faulty
> spec. It coincidentally highlighted the fact that GCC devs want it removed.
Yes, you're right. I didn't word it correctly. Anway, the point is made.
> It's there in the current stable book and doin
Jeremy Huntwork wrote:
> There is a bug open to remove this feature from gcc. But, it is a year
> old now and still open.
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19353
Not exactly. That bug report is about startfile_prefix_spec being a faulty
spec. It coincidentally highlighted the fact
Jeremy Huntwork wrote:
Hello Everyone
As I mentioned in another thread, my intention is to re-add this method
into the LFS book.
Jeremy, this is primarily so as you know I've read your email! I'm far
too ignorant about the toolchain to possibly comment on the suitability
or otherwise of you
Jeremy Huntwork wrote:
Couple of typos in the attached patch. Just letting you know that I've
noticed them, will fix them, and will also render/validate these changes
before I commit. I've made several careless mistakes recently, and I'm
going to be putting much more care into my work in the futur
Hello Everyone
As I mentioned in another thread, my intention is to re-add this method
into the LFS book. I've done a test build using this, and everything
works as expected. Using Greg's extended tests, we know for certain that
binutils and gcc will be linking against the right Glibc in chapter 6
50 matches
Mail list logo
