path modifications on gcc-3.3.1-specs-1.patch

Greg Schafer 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
   STANDARD_INCLUDE_PATH thingamy)

 - 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
   guessing ability.

 - 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"

Greg



More information about the lfs-dev mailing list