Unreviewed build patches
Rainer Orth
ro@CeBiTec.Uni-Bielefeld.DE
Mon May 23 14:30:00 GMT 2011
DJ Delorie <dj@redhat.com> writes:
>> [build] More --enable-threads cleanup
>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00059.html
>>
>> This might well be obvious.
>
> Also, we usually leave those up to the target maintainers, since
> they're target specific. But if it's just a correlation between the
True, but finding maintainers for obsolete/removed ports might be
difficult :-)
> script and a list of source file options, go for it.
I did, thanks.
>> Besides, it would be helpful if a build maintainer could have a look at
>>
>> [build] Move Solaris 2 startup files to toplevel libgcc
>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00098.html
>>
>> either to state that I don't need approval or to make suggestings for
>> improvements. This is not yet the final patch, but the remainder is
>> tuning.
>
> We normally let target maintainers manage anything in the build that's
> target-specific. However, you've mixed in target patches with
I know and usually act on that rule. I wasn't asking so much for
approval but rather for suggestions for the build side of things.
> target-independent patches. I have no problem with you checking in
> your own target changes, but if you could split out the rest for
> review, it would make it easier on us.
I can try if the build maintainers need that. So far, I can only see
use of the new generic libgcc/config/t-crtfm on sparc targets other
than Solaris, and $< instead of pathnames in libgcc/config/i386/t-crtfm,
gld detection and substitution of cpu_type.
> Also, mention if you tested it on any ix86 non-solaris platform
> (linux, bsd, etc).
I didn't since apart from the t-crtfm stuff (which has been tested on
Solaris already), there's nothing that could affect them.
Thanks.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
More information about the Gcc-patches
mailing list