Hi Erik,

On Wed, 2018-07-18 at 18:10 +0200, Severin Gehwolf wrote:
> webrev with info line removed:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8036003/webrev.03/
> 
> HG-export:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8036003/JDK-8036003.jdk8.export.patch
> 
> Could you please sponsor this change once [I] gets approved? I'd then
> close JDK-8207234 as a duplicate of the 8036003 8u-backport bug.

Rob approved the enhancement backport request[a] and the actual
backport request[b]. Could you please sponsor this patch as it needs to
include generated-configure as well which needs to be done by an Oracle
sponsor, AFAIK?

Thanks,
Severin

[a] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-July/007697.html
[b] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-July/007698.html

> Thanks,
> Severin
> 
> [I] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-July/007670.html
> 
> > /Erik
> > 
> > 
> > On 2018-07-18 06:42, Severin Gehwolf wrote:
> > > Hi Erik,
> > > 
> > > Latest webrev with default param over changes in the jdk tree:
> > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8036003/webrev.0
> > > 2/
> > > 
> > > Thanks,
> > > Severin
> > > 
> > > 
> > > On Tue, 2018-07-17 at 09:16 -0700, Erik Joelsson wrote:
> > > > That should work, but if it doesn't, please try double dollar
> > > > on
> > > > $(STRIP_POLICY). Then it gets evaluated when the macro is
> > > > called instead
> > > > of when it is defined.
> > > > 
> > > > /Erik
> > > > 
> > > > 
> > > > On 2018-07-17 09:01, Severin Gehwolf wrote:
> > > > > Hi Erik,
> > > > > 
> > > > > On Tue, 2018-07-17 at 07:24 -0700, Erik Joelsson wrote:
> > > > > > Good work backporting the proper fix!
> > > > > 
> > > > > Thanks for the review!
> > > > > 
> > > > > > I think it would be good if you could make $1_STRIP_POLICY
> > > > > > default to
> > > > > > $(STRIP_POLICY) in SetupNativeCompilation instead of
> > > > > > setting it as
> > > > > > parameter basically everywhere. That shouldn't change the
> > > > > > default
> > > > > > behavior anywhere I think?
> > > > > 
> > > > > How would I do that? No values from spec.gmk seem to be
> > > > > available in
> > > > > SetupNativeCompilation. For example, this doesn't work (with
> > > > > the params
> > > > > passed in in the jdk repo reverted):
> > > > > 
> > > > > diff --git a/make/common/NativeCompilation.gmk
> > > > > b/make/common/NativeCompilation.gmk
> > > > > --- a/make/common/NativeCompilation.gmk
> > > > > +++ b/make/common/NativeCompilation.gmk
> > > > > @@ -260,6 +260,10 @@
> > > > >        $1_CC:=$(CC)
> > > > >      endif
> > > > >    
> > > > > +  ifeq ($$($1_STRIP_POLICY),)
> > > > > +    $1_STRIP_POLICY:=$(STRIP_POLICY)
> > > > > +  endif
> > > > > +
> > > > >      # Make sure the dirs exist.
> > > > >      $$(eval $$(call MakeDir,$$($1_OBJECT_DIR)
> > > > > $$($1_OUTPUT_DIR)))
> > > > >      $$(foreach d,$$($1_SRC), $$(if $$(wildcard
> > > > > $$d),,$$(error SRC specified to SetupNativeCompilation $1
> > > > > contains missing directory $$d)))
> > > > > 
> > > > > Thanks,
> > > > > Severin
> > > > > 
> > > > > > On 2018-07-17 05:54, Severin Gehwolf wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > This work started as a patch for JDK-8207234[1], but
> > > > > > > turned out to
> > > > > > > become a 8-backport of JDK-8036003[2] using the old build
> > > > > > > logic and
> > > > > > > with backwards-compatibilty. We are facing an issue where
> > > > > > > .gnu_debuglink sections get generated unconditionally on
> > > > > > > the various
> > > > > > > JDK libs (serviceability, security, nio, awt, etc.).
> > > > > > > That's an issue,
> > > > > > > since for our distro builds the stripping happens outside
> > > > > > > the OpenJDK
> > > > > > > build post-factum. The result of adding debug links
> > > > > > > unconditionally is
> > > > > > > that our binaries would have two links, one pointing to a
> > > > > > > file which
> > > > > > > doesn't exist.
> > > > > > > 
> > > > > > > What's more, there is no real support for the kind of
> > > > > > > debug-info build
> > > > > > > we need as downstream distribution consumers: Have all
> > > > > > > debug symbols
> > > > > > > present, but leave them in the binary/library itself
> > > > > > > without any
> > > > > > > stripping. That's basically what JDK 11's --with-native-
> > > > > > > debug-
> > > > > > > symbols=internal does. This patch ports that configure
> > > > > > > flag to JDK 8u
> > > > > > > and keeps backward-compatibility with --disable-debug-
> > > > > > > symbols and --
> > > > > > > disable-zip-debug-info flags. More info on this in [1].
> > > > > > > 
> > > > > > > Bug(s): https://bugs.openjdk.java.net/browse/JDK-8207234
> > > > > > >            https://bugs.openjdk.java.net/browse/JDK-80360
> > > > > > > 03
> > > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> > > > > > > 8207234/01/
> > > > > > > 
> > > > > > > Testing:
> > > > > > > 
> > > > > > > Tested all build configs that I could think of (on Linux
> > > > > > > x86_64):
> > > > > > >     * Old config is being preserved (default build of
> > > > > > > debug symbols +
> > > > > > >       zipped; no --disable-zip-debug-info, --disable-
> > > > > > > debug-symbols, --
> > > > > > >       with-native-debug-symbols flags)
> > > > > > >     * Plain external debug symbols (flag --disable-zip-
> > > > > > > debug-info)
> > > > > > >     * No debug-symbols build (flags --disable-zip-debug-
> > > > > > > info, --disable-
> > > > > > >       debug-symbols)
> > > > > > >     * Only using --with-native-debug-
> > > > > > >       symbols={none,zipped,external,internal} (no flags
> > > > > > > --disable-zip-
> > > > > > >       debug-info, --disable-debug-symbols). Where
> > > > > > > "internal" passes tests
> > > > > > >       in JDK-8207234
> > > > > > > 
> > > > > > > Examples:
> > > > > > > 
> > > > > > > configure output post-patch with flags --disable-zip-
> > > > > > > debug-info, --
> > > > > > > disable-debug-symbols:
> > > > > > > 
> > > > > > > [...]
> > > > > > > checking if we should generate debug symbols... false
> > > > > > > checking if we should zip debug-info files... no
> > > > > > > checking what type of native debug symbols to use (this
> > > > > > > will override previous settings)... not specified
> > > > > > > configure: --with-native-debug-symbols not specified.
> > > > > > > Using values from --disable-debug-symbols and --disable-
> > > > > > > zip-debug-info
> > > > > > > [...]
> > > > > > > 
> > > > > > > configure output post-patch with flags --with-native-
> > > > > > > debug-
> > > > > > > symbols=internal:
> > > > > > > 
> > > > > > > [...]
> > > > > > > checking if we should generate debug symbols... true
> > > > > > > checking if we should zip debug-info files... yes
> > > > > > > checking what type of native debug symbols to use (this
> > > > > > > will override previous settings)... internal
> > > > > > > [...]
> > > > > > > 
> > > > > > > configure output post-patch with flags --with-native-
> > > > > > > debug-
> > > > > > > symbols=foobar:
> > > > > > > 
> > > > > > > [...]
> > > > > > > checking if we should generate debug symbols... true
> > > > > > > checking if we should zip debug-info files... yes
> > > > > > > checking what type of native debug symbols to use (this
> > > > > > > will override previous settings)... foobar
> > > > > > > configure: error: Allowed native debug symbols are: none,
> > > > > > > internal, external, zipped
> > > > > > > configure exiting with result code 1
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Severin
> > > > > > > 
> > > > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8207234
> > > > > > > [2] https://bugs.openjdk.java.net/browse/JDK-8036003
> > 
> > 

Reply via email to