Alexander Kabaev kabaev at gmail.com on Sat Apr 15 00:20:40 UTC 2017 wrote: . . .
> it was suggested multiple times that the whole fixinc step is > ultimately harmful and serves no useful purpose and probably should be > disabled in built packages outright. Is there a reason not to do it? > Even Redhat appears to do the slimming in their rpms: > > mv $FULLPATH/include-fixed/syslimits.h $FULLPATH/include/syslimits.h > mv $FULLPATH/include-fixed/limits.h $FULLPATH/include/limits.h > for h in `find $FULLPATH/include -name \*.h`; do > if grep -q 'It has been auto-edited by fixincludes from' $h; then > rh=`grep -A2 'It has been auto-edited by fixincludes from' $h | > tail -1 | sed 's|^.*"\(.*\)".*$|\1|'` diff -up $rh $h || : > rm -f $h > fi > done I'll note that: http://www.linuxfromscratch.org/lfs/view/7.1/chapter06/gcc.html reports as one of its steps (quote): The fixincludes script is known to occasionally erroneously attempt to "fix" the system headers installed so far. As the headers up to this point are known to not require fixing, issue the following command to prevent the fixincludes script from running: sed -i 's@\./fixinc\.sh@-c true@' gcc/Makefile.in (End quote) So seems that disabling fixinc.sh's use is fairly common when the headers are known to "not require fixing" (i.e., are known to already be gcc compliant). === Mark Millard markmi at dsl-only.net _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
