Greg Schafer wrote:
>> Also, haven't you noticed that making use of sysroot in pass one
>> eliminates the scenario that is causing you trouble in pass 2, thereby
>> removing the need for the patch?
>
> Huh? Not at all. Please, JH, explain how this is so.
I'm not a gcc internals expert, so I'm n
Jeremy Huntwork wrote:
> No, sorry, I don't. In the comments of that bug report the dev suggests
> using sysroot for pass 1 of gcc.
Yeah, and he also says create $sysroot/usr/include. If you're going to
hang your hat on the word of 1 junior GCC dev...
> Also, haven't you noticed that making use
Greg Schafer wrote:
> Umm, that bug report is about Pass 2. Your using the sysroot feature in
> Pass 1. See a problem?
No, sorry, I don't. In the comments of that bug report the dev suggests
using sysroot for pass 1 of gcc.
Also, haven't you noticed that making use of sysroot in pass one
elimin
Jeremy Huntwork wrote:
> For those unfamiliar see:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532
>
> For those not interested in reading the entire bug history, the last
> comment by a dev was:
>
> "Using the sysroot flags is the solution for Greg's scenario. In fact I
> would say it mak
-compilers for any part of the lfs toolchain.
Yes. This is true. But I now leverage cross compilation where it's
actually useful.
> You entirely miss the point of cross-lfs
Nobody here wants to bootstrap from Solaris.
>> if (*cross_compile == '0' || target_system_root)
&g
Greg Schafer wrote:
> You're making the changes in *both* passes. Unnecessary hackery and you
> know it. Stop blurring the truth.
I fail to see how I could blur the truth about something that is
publicly available for all to read. Of course the changes are there in
both passes, I never said othe
Greg Schafer wrote:
> Jeremy Huntwork wrote:
>> This method uses sysroot functionality in GCC and Binutils to help
>> 'mask' off the host system further.
>
> Huh? No! It's quite the opposite! This clearly demonstrates you don't
> understand the sysroot feature at all. I'm surprised that I have t
nd jumping on board of the basic
> idea actually *vindicates* what I've been saying for years - that CLFS is
> massive overkill for those wanting a 64-bit multiarch toolchain.
4 years ago your opinion was markedly different with regards to using
cross-compilers for any part of the lfs toolch
2009/1/19 Greg Schafer :
> Jeremy Huntwork wrote:
>> Some weeks ago, Ryan proposed a somewhat alternative method
>> that does not require any adjustment of the toolchain in chapter 5
>
> I think this is a regression, actually, at least from an educational POV.
Could you please explain why? (note:
Jeremy Huntwork wrote:
> It
> is a new approach compared to earlier versions of LFS in that the the
> first pass of binutils and gcc we are creating cross compilers and the
> chapter 5 glibc is cross compiled. It is a native build from that point
> forward.
>
> Some weeks ago, Ryan proposed a
Gerard Beekmans wrote:
> Can somebody do me a favour and give me both a high overview and a
> detailed technical nitty-gritty overview of those three (are there
> more?) methods - how they compare to each other.
You've summarized it pretty well. What is currently in trunk is based on
current DI
Hi,
I'm finding myself a little lost in the most recent discussion (subject
"Adapting LFS SVN for multilib"). After a couple of tangents I think we
can stand to take a few steps back and get back to the matter at hand.
Allow me to summarize what I think is going on. It'll likely help
explain w
12 matches
Mail list logo
