Looks good.
craig

----- [email protected] wrote:

> 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
_______________________________________________
userland-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/userland-discuss

Reply via email to