patches for tools?

Chakkaradeep C C chaks.lfs at gmail.com
Tue Jun 14 20:37:31 PDT 2005


Hi all,

>  Heh, last time I looked at an SRPM was for X.org, just after the gentoo
> patches picked up a ton of stuff from RedHat - from memory, many of
> those patches were very old and for very obscure hardware (and none of
> them solved my problem).  But, if the big-name rpm distros are now
> mostly patching to fix test failures, I guess that is a good sign.

i have checked in several systems and gcc does report a test failure
in libstdc++ tests, and the test_summary produced will not be accurate
but very near.These kinda things should be taken into consideration
because, gcc might work with these test failures,but what if other
tool depending upon this feature of gcc complain at a later stage?..so
my first step is to look for the patches available for gcc-3.4.1.i
think i have to look into other distros src.rpm as you have mentioned
above.
 
>  BUT, what you have to remember is that _toolchain_ problems are often
> specific to particular binutils/gcc/glibc/kernel combinations (e.g.
> glibc-2.3.4 nptl started to fail with the pipe [?] changes in kernel
> 2.6.11, I believe), and undoubtedly some distros build far more
> languages than just c,c++ in gcc and may hit bugs most of us never see.

yeah,the problems are specific to the toolchain versions being used..
 
>  And now the big problem: you've got the situation slightly twisted
> around - the RPM distros provide patches in their SRPMs, there is not
> generally a standard set of patches that distros apply :)  So, for each
> issue that you care about and for which there is a known fix, you have
> to extract a relevant patch (or, sometimes, upgrade to a later version).
> Once you've done that and confirmed that it fixes the problem, please
> submit each patch to patches.linuxfromscratch.org :)  You might also
> want to look at debian, ubuntu, [ .diff.gz in their download sites ] and
> even gentoo [ who sometimes have patches in the 'files' sub-directories
> of the individual packages on their mirrors ].
> You will often need to edit distro patches to strip out stuff that
> doesn't affect us - particularly for debian patches - and you may need
> to rediff it so that we can apply it with our standard -p1 patch option.
> But, how many failures are you seeing ?  These days, binutils should be
> ok on _most_ architectures, gcc usually has a handful of different
> failures in each release/arch, and released glibc should only have a
> couple of failures.  Certainly, fedora tends to pick up on gcc bugfixes
> a bit ssooner than most other distros, but these aren't always related
> to test failures, and anyway fedora is often bleeding-edge.

as far as now,i dont think binutils (lfs version) has got problems
because they themselves are providing some patches and also glibc is
better than gcc :-( in terms of failures,eventhough we may have to
tweak some timeout variables or the test may fail if there is no
genuine intel or athlon as mentioned in the docs.but are they
safe?....when i had my P4 machine with a Mercury Motherboard, i got
some problems with glibc's make check,mainly math tests.now i have
upgraded my machine to original ASUS board and AMD Sempron , and when
i built lfs,i didnt get ANY error with glibc's make check.so,how do we
come out of this or is this the nature of glibc?

thanks in advance,

with regards,
C.C.Chakkaradeep



More information about the lfs-support mailing list