Greg Schafer wrote:
> Ryan Oliver wrote:
>
>
>> Don't mix up explanation with example.
>>
>> This merely re-enforces the point I made above.
>>
>
> What? That you're using sysroot incorrectly?
>
>
No, that a sysroot is merely a target sytem root and cares not for what
is under a target system root.
Repeating the words "sysroot" and "incorrect" and excising the preceding
arguments doesn't make your case any better.
See again sample text re-iterated.
>> FHS standard under the _logical root directory_ is not implied.
>>
>
> Huh? It's written in black and white. You're ignoring reality.
>
>
The example to describe what sysroot does stated (again emphasis is mine)
"--sysroot=dir
Use _dir_ as the logical root directory for headers and libraries.
_For_
_example_, *if* the compiler would *normally* search for headers in
/usr/include and libraries in /usr/lib, it will instead search
*dir*/usr/include and *dir*/usr/lib*"
The point being shown here is what happens with regards to search path
handling when using sysroot.
Use of the /usr example is the easiest example folks would understand
because that is what by default any unmodified native compiler does.
Again. sysroot provides a relocation of search paths under a target
system root. That is its sole job.
Itself, it cares not what those search paths are it relocates under the
target system root.
>> Exactly as was done for plfs, lfs and DIY.
>>
>> Hell, you are already hacking *_THE EXACT SAME MACROS_*.
>>
>
> Huh? plfs or lfs has never tinkered with STANDARD_STARTFILE_PREFIX_{1,2}
> up until now.
The purpose of the toolchains in those builds was to alter include and
library search paths to cater to our perceived view of what the standard
include and library search paths should be for our purposes.
You have an objection for doing the same thing in a sysroot, but not in
a native build.
Hypocrisy.
> I first started using them about a year ago to prevent host
> searching. You're making stuff up.
>
>
>> I am using the sysroot feature for a target system root.
>>
>
> Yes, but for a *non-root* filesystem, in violation of the docs.
>
WTF is a non-root filesystem. the term you are looking for is *non-fhs
root filesystem*
>
>> Methinks the difference between
>> "l337 super new mega clfs-killing second-coming toolchain build method
>> !!!11!!1!"
>> and
>> "GAH OH NOES gcc source edits, sysroot misuse, FUD FUD unsubstantiated FUD"
>> is merely that the author was not Greg Schafer.
>>
>
> Wow, man, you're starting to lose it. Stay focused!
>
>
>> I put this build together *solely to prove a point*
>>
>
> No, you put this build together solely because someone finally came up
> with something better then your beloved CLFS. Face it! You would never
> have showed up here to share your knowledge had we not dented your pride.
>
>
Your build is better than CLFS? So you can build from BSD and Solaris etc?
Assume for a moment that CLFS is not meant as a method for building
linux from scratch across architectures and operating systems.
Even if we limit the scope of it to the narrow field of OS == OS, host
== target builds we still produce a sane toolchain capable of by itself
producing binaries and linking in correct libraries
I looked at the abortion that was being proposed and gave you some hints
to at least make it sane, I like the LFS project too much to see
technical folks pointing and laughing at it.
>> Hell, I even "fixed" up your "-B binary search path doesn't use
>> multilibs" problem for you.
>> I've offered to even "fix" up the "broken gcc -specs switch handling
>> "bug"" for you (even easier "fix" than the -B multilib handling).
>>
>
> Ok, now we've heard everything. Ryan has become a GCC developer! Looking
> forward to you submitting patches!
>
>
I will when there is something that *actually does* need fixing.
I can code to solve my problems, and understand the driver code pretty
well enough to do whatever I want with it.
Just because *you* cannot code to fix your imagined bugs and
mis-features and cannot therefore contribute anything back to gcc
doesn't mean I can't when required.
>> You have had 4 years of clfs to look at
>>
>
> You have had 4 years of clfs to try and get a new build into LFS. You
> failed.
>
>
We didn't bother. We would have been shouted down by ignorant tards like
you with your baseless FUD and arguments.
Who has the time to deal with that. I've burnt enough already.
If we had been approached by LFS to help we would have, and had the
build done in a day.
>> Why the hell should anyone take any credence in what *your opinion*
>>
>
> Well, at least I don't disappear for years on end.
>
>
Not touching that one.
>> Hell at the very least use some symlinks such as
>>
>
> Good idea.
>
>
How could you not have tried this first?
>> What is this "mainstream build" of which you speak.
>>
>
> Mainstream, as in your typical Joe Sixpack who simply wants to build his
> own system ie: typical LFS reader. Not your uber power tech nerd who
> enjoys pulling teeth by wanting to bootstrap from Solaris.
>
I'd think a typical "Joe Sixpack" user would prefer not to edit specs
with seds or append -B switches and have a good amount of faith that
their toolchain will actually work all by itself all the time, every time.
A "mainstream build" should minimise the ability of the user to make
mistakes.
[R]
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
