path modifications on gcc-3.3.1-specs-1.patch
gschafer at zip.com.au
Fri Sep 19 20:16:19 PDT 2003
On Sat, Sep 20, 2003 at 12:02:57AM -0300, Anderson Lizardo wrote:
> Greg Schafer wrote:
> > I am tempted to just pull the stuff for the architectures where
> > nobody has tested, from the specs patch, until they can be confirmed
> > by a clueful LFS'er with access to the hardware in question.
> > Thoughts?
> I'm feeling that this specs modification thing will become the "weak
> point" of the current implementation, regarding architecture
> independency. It's too arch-dependent, and there are many specs
> variants (like the ones you listed) to take care of.
> Anyway, I agree with you. We have to make only the changes we know it's
> necessary to resolve the problem in question. IMHO, doing just a
> "s@/lib@/tools/lib at g", in this case, is unclean and somewhat obscure.
> Just some thoughts.
Thanks for your thoughts :-)
I think what I'll do is this:-
- make a new specs patch (I have to make one anyway to add the new
- I'll assume that USE_GNULIBC_1 is not in use. My understanding is
USE_GNULIBC_1 means libc5 which is surely NOT any modern Glibc using
Linux system on any arch. i.e. LFS does not support libc5 at all.
- I'll fix the other bits and pices like the -YP thing to the best of my
- I'll also stick a warning in the patch header along the lines of:
"This patch makes modifications to some architecture backends that have
not been properly tested due to unavailability of the hardware. If you
notice any problems with this patch for your architecture, please report
them to lfs-dev at linuxfromscratch.org"
More information about the lfs-dev