Hi, Could I please get a code review for the fix for:
7157429 gzip 1.4 integration still has a couple of problems http://monaco.us.oracle.com/detail.jsf?cr=7157429 Webrev is at: http://jurassic.us.oracle.com/~richb/7157429-v1/ x86 Userland workspace (with just gzip built) is at: /net/stard.us.oracle.com/tank/ws/UL/7157429/ Build/publish log is: /net/stard.us.oracle.com/tank/ws/UL/7157429/components/gzip/publish-trans.txt "gmake test" output is: /net/stard.us.oracle.com/tank/ws/UL/7157429/components/gzip/test-trans.txt SPARC Userland workspace (with just gzip built) is at: /net/wonderland.us.oracle.com/builds/richb/7157429/ Build/publish log is: /net/wonderland.us.oracle.com/builds/richb/7157429/components/gzip/publish-trans.txt "gmake test" output is: /net/wonderland.us.oracle.com/builds/richb/7157429/components/gzip/publish-trans.txt I also checked that each of the gz<whatever> scripts now has a bindir line of /usr/bin. See the Bugster CR for more details. Thanks to Petr Sumbera for doing all the hard work here. Petr did suggest in the bug: "If we are going to have more and more 64bit binaries in /usr/bin then it would nice to be able to force make-rules/configure.mk so that it sets CONFIGURE_BINDIR.64 to /usr/bin and CONFIGURE_SBINDIR.64 to /usr/sbin. E.g via something like CONFIGURE_DEFAULT_DIRS is used in configure.mk. I believe it would solve this problem." I did discuss this with Mike (Sullivan) and we did not believe a generic solution had an advantage here, when the individual component change is only the addition of one line to the Makefile (sans the comment), and because each component might want to do something slightly different. If a generic solution is really required, it is suggested that a separate RFE should be filed against solaris/consolidation/userland to handle it. Thanks. _______________________________________________ userland-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/userland-discuss
