回复: 回复: [8u]RFR: 8263061: copy wrong unpack200.diz to bin directory on linux after 8252395(Internet mail)

[kalinshi(施慧)]

Could some committer help sponsor this commit?

Regards
Hui

-----邮件原件-----
发件人: Severin Gehwolf <sgehwolf at redhat.com> 
发送时间: 2021年3月8日 17:26
收件人: kalinshi(施慧) <kalinshi at tencent.com>; jdk8u-dev at openjdk.java.net
主题: Re: 回复: [8u]RFR: 8263061: copy wrong unpack200.diz to bin directory on linux after 8252395(Internet mail)

Hi,

On Sat, 2021-03-06 at 10:49 +0000, kalinshi(施慧) wrote:
> Thanks Severin!
> 
> It's more reasonable to keep same copy way in Makefile. Tested with 
> both --with-native-debug-symbols=external --with-native-debug- 
> symbols=zipped Updated Webrev: 
> http://cr.openjdk.java.net/~hshi/8263061/webrev_v2

This looks good. Thanks!

> Another finding is that debuginfo files (not zipped) are executable 
> and this fails VersionCheck.java test.
> Instead of porting JDK-8237192 changes to filter these debuginfo 
> files, is it more reasonable to make them not executable on 
> linux/solaris?
> Making following changes in top level mercurial jdk8u repository.
> 
> diff -r 8006ef1eeba6 make/common/NativeCompilation.gmk
> --- a/make/common/NativeCompilation.gmk Mon Mar 01 20:02:56 2021 +0000
> +++ b/make/common/NativeCompilation.gmk Sat Mar 06 18:45:29 2021 +0800
> @@ -480,6 +480,7 @@
>                         $(OBJCOPY) --only-keep-debug $$< $$@
>                         $(CD) $$(@D) && $(ADD_GNU_DEBUGLINK) 
> $(LOG_INFO) $$(@F) $$<
>                         $(TOUCH) $$@
> +                       $(CHMOD) a-x $$@
>              endif
>            else ifeq ($(OPENJDK_TARGET_OS), linux)
>              ifneq ($$($1_STRIP_POLICY), no_strip) @@ -489,6 +490,7 @@
>                         $(OBJCOPY) --only-keep-debug $$< $$@
>                         $(CD) $$(@D) && $(OBJCOPY) 
> --add-gnu-debuglink=$$(@F) $$<
>                         $(TOUCH) $$@
> +                       $(CHMOD) a-x $$@
>              endif
>            endif # No MacOS X support

I haven't made up my mind about it. It feels like we should do something similar to a partial port of JDK-8237192 to JDK 8u so as to keep trees in sync. Either way, this is for a separate bug/discussion.

Thanks,
Severin