date:20180813

Re: [12] RFR(XS) 8208463: jdk.internal.vm.compiler's module-info.java.extra contains duplicated provides of the same service interface

2018-08-13 Thread Vladimir Kozlov


Thank you, Mandy

Vladimir

On 8/13/18 8:00 PM, mandy chung wrote:

Hi Vladimir,

This looks good.  I verified with my patch that enforces non-duplicate
provides check and it builds successfully.  Thanks for fixing it.

thanks
Mandy

On 8/13/18 5:06 PM, Vladimir Kozlov wrote:

https://bugs.openjdk.java.net/browse/JDK-8208463

Before we did not care how module-info.java.extra is generated. The code in Gensrc-jdk.internal.vm.compiler.gmk  make 
file simple ordered 'providers' files (which are packages names) by name and then use their contents to generate 
'provides' instructions. If following file in sorted list reference the same package it will be added to the same 
'provides' as for previous file. But it did not guarantee that all referenced packages are listed in the same 
'provides' command.


The fix is to sort files not by their name but by their content. It guarantee that files with the same content will be 
listed together.


Run tier1-3 testing. It included Graal JIT testing and AOT (which uses Graal) 
testing.

Thanks,
Vladimir

diff -r ae001a1deb74 make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk
--- a/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk
+++ b/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk
@@ -124,7 +124,7 @@
  ($(CD) $(GENSRC_DIR)/META-INF/providers && \
  p=""; \
  impl=""; \
-    for i in $$($(LS) | $(SORT)); do \
+    for i in $$($(GREP) '^' * | $(SORT) -t ':' -k 2 | $(SED) 's/:.*//'); 
do \
    c=$$($(CAT) $$i | $(TR) -d '\n\r'); \
    if test x$$p != x$$c; then \
  if test x$$p != x; then \

Re: [12] RFR(XS) 8208463: jdk.internal.vm.compiler's module-info.java.extra contains duplicated provides of the same service interface

2018-08-13 Thread mandy chung


Hi Vladimir,

This looks good.  I verified with my patch that enforces non-duplicate
provides check and it builds successfully.  Thanks for fixing it.

thanks
Mandy

On 8/13/18 5:06 PM, Vladimir Kozlov wrote:

https://bugs.openjdk.java.net/browse/JDK-8208463

Before we did not care how module-info.java.extra is generated. The code 
in Gensrc-jdk.internal.vm.compiler.gmk  make file simple ordered 
'providers' files (which are packages names) by name and then use their 
contents to generate 'provides' instructions. If following file in 
sorted list reference the same package it will be added to the same 
'provides' as for previous file. But it did not guarantee that all 
referenced packages are listed in the same 'provides' command.


The fix is to sort files not by their name but by their content. It 
guarantee that files with the same content will be listed together.


Run tier1-3 testing. It included Graal JIT testing and AOT (which uses 
Graal) testing.


Thanks,
Vladimir

diff -r ae001a1deb74 make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk
--- a/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk
+++ b/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk
@@ -124,7 +124,7 @@
  ($(CD) $(GENSRC_DIR)/META-INF/providers && \
  p=""; \
  impl=""; \
-    for i in $$($(LS) | $(SORT)); do \
+    for i in $$($(GREP) '^' * | $(SORT) -t ':' -k 2 | $(SED) 
's/:.*//'); do \

    c=$$($(CAT) $$i | $(TR) -d '\n\r'); \
    if test x$$p != x$$c; then \
  if test x$$p != x; then \

[12] RFR(XS) 8208463: jdk.internal.vm.compiler's module-info.java.extra contains duplicated provides of the same service interface

2018-08-13 Thread Vladimir Kozlov


https://bugs.openjdk.java.net/browse/JDK-8208463

Before we did not care how module-info.java.extra is generated. The code in 
Gensrc-jdk.internal.vm.compiler.gmk  make file simple ordered 'providers' files (which are packages 
names) by name and then use their contents to generate 'provides' instructions. If following file in 
sorted list reference the same package it will be added to the same 'provides' as for previous file. 
But it did not guarantee that all referenced packages are listed in the same 'provides' command.


The fix is to sort files not by their name but by their content. It guarantee that files with the 
same content will be listed together.


Run tier1-3 testing. It included Graal JIT testing and AOT (which uses Graal) 
testing.

Thanks,
Vladimir

diff -r ae001a1deb74 make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk
--- a/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk
+++ b/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk
@@ -124,7 +124,7 @@
($(CD) $(GENSRC_DIR)/META-INF/providers && \
p=""; \
impl=""; \
-   for i in $$($(LS) | $(SORT)); do \
+   for i in $$($(GREP) '^' * | $(SORT) -t ':' -k 2 | $(SED) 
's/:.*//'); do \
  c=$$($(CAT) $$i | $(TR) -d '\n\r'); \
  if test x$$p != x$$c; then \
 if test x$$p != x; then \

Re: RFR (S) 8208665: Amend cross-compilation docs with qemu-debootstrap recipe

2018-08-13 Thread Aleksey Shipilev

On 08/13/2018 05:16 PM, Martin Buchholz wrote:
> Aleksey, your use of "base" platform seems a bit unusual.  Elsewhere in the 
> same document, it's
> referred to as "build".  Otherwise looks good (thanks for documenting).

Right. Got mixed up with Debian's "base system". Fixed here:
 http://cr.openjdk.java.net/~shade/8208665/webrev.03/

-Aleksey

Re: RFR (S) 8208665: Amend cross-compilation docs with qemu-debootstrap recipe

2018-08-13 Thread Martin Buchholz

Aleksey, your use of "base" platform seems a bit unusual.  Elsewhere in the
same document, it's referred to as "build".  Otherwise looks good (thanks
for documenting).

On Mon, Aug 13, 2018 at 3:26 AM, Aleksey Shipilev  wrote:

> RFE:
>   https://bugs.openjdk.java.net/browse/JDK-8208665
>
> Webrev:
>   http://cr.openjdk.java.net/~shade/8208665/webrev.02/
>
> Not sure if building.html is supposed to be generated automatically?
>
> This is the recipe I have been using for creating artifacts on my personal
> CI server [1], and it
> seems to work reliably starting from jdk11. It is partially applicable for
> building jdk{8,9,10}, but
> freetype and friends still need to be pointed out explicitly there.
> Nevertheless, this seems to be
> the most straightforward way to cross-compile to foreign architectures if
> there are no devkit
> bundles available.
>
> Thanks,
> -Aleksey
>
> [1] https://builds.shipilev.net/
>
>

RE: [RFR]: 8209115: adjust libsplashscreen linux ppc64le builds for easier libpng update - was : RE: RFR 8195615 : libsplashscreen linux ppc64le build error after libpng update

2018-08-13 Thread Baesken, Matthias

Thanks for the review!

> -Original Message-
> From: David Holmes 
> Sent: Montag, 13. August 2018 09:00
> To: Baesken, Matthias ; Phil Race
> 
> Cc: awt-...@openjdk.java.net; 'build-dev@openjdk.java.net'  d...@openjdk.java.net>
> Subject: Re: [RFR]: 8209115: adjust libsplashscreen linux ppc64le builds for
> easier libpng update - was : RE: RFR 8195615 : libsplashscreen linux ppc64le
> build error after libpng update
> 
> Hi Matthias,
> 
> On 13/08/2018 4:41 PM, Baesken, Matthias wrote:
> > Thank‘s !
> > Can I have a second review please ?
> 
> As the build team seem to be on vacation right now I can add that second
> Review. :)
> 
> Cheers,
> David
> 
> > Best regards, Matthias
> >
> >
> > From: Phil Race 
> > Sent: Freitag, 10. August 2018 20:12
> > To: Baesken, Matthias 
> > Cc: 'build-dev@openjdk.java.net' ; awt-
> d...@openjdk.java.net
> > Subject: Re: [RFR]: 8209115: adjust libsplashscreen linux ppc64le builds for
> easier libpng update - was : RE: RFR 8195615 : libsplashscreen linux ppc64le
> build error after libpng update
> >
> > +1 from me.
> >
> > -phil.
> > On 08/10/2018 08:18 AM, Baesken, Matthias wrote:
> > Hello  , here is a new webrev :
> >
> >
> http://cr.openjdk.java.net/~mbaesken/webrevs/8209115.1/ jdk.java.net/%7Embaesken/webrevs/8209115.1/>
> >
> > I set PNG_POWERPC_VSX_OPTnow only on the  linux ppc  platforms .
> >
> > Best regards, Matthias
> >
> >
> > From: Baesken, Matthias
> > Sent: Donnerstag, 9. August 2018 08:48
> > To: 'Philip Race' 
> > Cc: 'build-dev@openjdk.java.net'
> ; awt-
> d...@openjdk.java.net
> > Subject: RE: [RFR]: 8209115: adjust libsplashscreen linux ppc64le builds for
> easier libpng update - was : RE: RFR 8195615 : libsplashscreen linux ppc64le
> build error after libpng update
> >
> >
> > Ø  Seems like the ARM one has been harmless for an x64 build
> >
> >*   so we could for now assume the PPC one is too
> >
> > Hi Phil ,
> >I  will  guard  the define  for   the platform  where  we want to use  
> > it -   I
> think this is better for the future than just setting it  on all platforms .
> >
> > And btw.  it has to be
> >
> > PNG_POWERPC_VSX_OPT   not  PNG_POWERPC_VSX
> >
> > ☹  - my mistake .
> >
> > For some reason the current setting still builds on our ppc64 (le) test
> machinein the current codebase , strange !
> >
> > Best regards, Matthias
> >
> >
> > From: Philip Race
> mailto:philip.r...@oracle.com>>
> > Sent: Donnerstag, 9. August 2018 04:09
> > To: Baesken, Matthias
> mailto:matthias.baes...@sap.com>>
> > Cc: 'build-dev@openjdk.java.net'
> mailto:build-dev@openjdk.java.net>>; awt-
> d...@openjdk.java.net
> > Subject: Re: [RFR]: 8209115: adjust libsplashscreen linux ppc64le builds for
> easier libpng update - was : RE: RFR 8195615 : libsplashscreen linux ppc64le
> build error after libpng update
> >
> >
> > The only comment I have is about this
> >
> > -  LIBSPLASHSCREEN_CFLAGS += -DSPLASHSCREEN -
> DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0
> >
> > +  LIBSPLASHSCREEN_CFLAGS += -DSPLASHSCREEN -
> DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0 -
> DPNG_POWERPC_VSX=0
> >
> >
> >
> > I suppose these platform defines are harmless and un-referenced unless
> building for
> >
> > the specified platform. Seems like the ARM one has been harmless for an
> x64 build
> >
> > so we could for now assume the PPC one is too.
> >
> > Or you could use jdk-submit to prove this :-)
> >
> >
> >
> > -phil.
> >
> > On 8/8/18, 12:59 AM, Baesken, Matthias wrote:
> > Hello ,
> > please review this small adjustment for  the build of libsplashscreen ,
> especially the libpng parts .
> > Back then,  we had to fix the  build of  the libpng parts  in 
> > libsplashscreen
> on linux ppc64le   with  “8195615 : libsplashscreen linux ppc64le build error
> after libpng update”  .
> >
> > However this introduced a small adjustment to pngpriv.h  that needs to be
> kept every time libpng  is updated   (happened recently when Phil updated
> the lib).
> > So I better want to remove the adjustment  to  pngpriv   from   8195615 ,
> and instead change the build settings to fix the compilation  on linuxppc64 
> le .
> >
> > Webrev/bug :
> >
> >
> http://cr.openjdk.java.net/~mbaesken/webrevs/8209115.0/ jdk.java.net/%7Embaesken/webrevs/8209115.0/>
> >
> > https://bugs.openjdk.java.net/browse/JDK-8209115
> >
> > Thanks ,
> >Matthias
> >
> >
> >
> > From: Philip Race
> 
> > Sent: Dienstag, 7. August 2018 17:15
> > To: Baesken, Matthias
> 
> > Cc: Doerr, Martin
> ; 2d-
> d...@openjdk.java.net; Simonis, Volker
> ; Lindenmaier,
> Goetz 
> > Subject: Re:

RFR (S) 8208665: Amend cross-compilation docs with qemu-debootstrap recipe

2018-08-13 Thread Aleksey Shipilev

RFE:
  https://bugs.openjdk.java.net/browse/JDK-8208665

Webrev:
  http://cr.openjdk.java.net/~shade/8208665/webrev.02/

Not sure if building.html is supposed to be generated automatically?

This is the recipe I have been using for creating artifacts on my personal CI 
server [1], and it
seems to work reliably starting from jdk11. It is partially applicable for 
building jdk{8,9,10}, but
freetype and friends still need to be pointed out explicitly there. 
Nevertheless, this seems to be
the most straightforward way to cross-compile to foreign architectures if there 
are no devkit
bundles available.

Thanks,
-Aleksey

[1] https://builds.shipilev.net/

Re: [RFR]: 8209115: adjust libsplashscreen linux ppc64le builds for easier libpng update - was : RE: RFR 8195615 : libsplashscreen linux ppc64le build error after libpng update

2018-08-13 Thread David Holmes


Hi Matthias,

On 13/08/2018 4:41 PM, Baesken, Matthias wrote:

Thank‘s !
Can I have a second review please ?


As the build team seem to be on vacation right now I can add that second 
Review. :)


Cheers,
David


Best regards, Matthias


From: Phil Race 
Sent: Freitag, 10. August 2018 20:12
To: Baesken, Matthias 
Cc: 'build-dev@openjdk.java.net' ; 
awt-...@openjdk.java.net
Subject: Re: [RFR]: 8209115: adjust libsplashscreen linux ppc64le builds for 
easier libpng update - was : RE: RFR 8195615 : libsplashscreen linux ppc64le 
build error after libpng update

+1 from me.

-phil.
On 08/10/2018 08:18 AM, Baesken, Matthias wrote:
Hello  , here is a new webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8209115.1/

I set PNG_POWERPC_VSX_OPTnow only on the  linux ppc  platforms .

Best regards, Matthias


From: Baesken, Matthias
Sent: Donnerstag, 9. August 2018 08:48
To: 'Philip Race' 
Cc: 'build-dev@openjdk.java.net' 
; 
awt-...@openjdk.java.net
Subject: RE: [RFR]: 8209115: adjust libsplashscreen linux ppc64le builds for 
easier libpng update - was : RE: RFR 8195615 : libsplashscreen linux ppc64le 
build error after libpng update


Ø  Seems like the ARM one has been harmless for an x64 build

   *   so we could for now assume the PPC one is too

Hi Phil ,
   I  will  guard  the define  for   the platform  where  we want to use  it -  
 I think this is better for the future than just setting it  on all platforms .

And btw.  it has to be

PNG_POWERPC_VSX_OPT   not  PNG_POWERPC_VSX

☹  - my mistake .

For some reason the current setting still builds on our ppc64 (le) test machine 
   in the current codebase , strange !

Best regards, Matthias


From: Philip Race mailto:philip.r...@oracle.com>>
Sent: Donnerstag, 9. August 2018 04:09
To: Baesken, Matthias 
mailto:matthias.baes...@sap.com>>
Cc: 'build-dev@openjdk.java.net' 
mailto:build-dev@openjdk.java.net>>; 
awt-...@openjdk.java.net
Subject: Re: [RFR]: 8209115: adjust libsplashscreen linux ppc64le builds for 
easier libpng update - was : RE: RFR 8195615 : libsplashscreen linux ppc64le 
build error after libpng update


The only comment I have is about this

-  LIBSPLASHSCREEN_CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE 
-DPNG_ARM_NEON_OPT=0

+  LIBSPLASHSCREEN_CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE 
-DPNG_ARM_NEON_OPT=0 -DPNG_POWERPC_VSX=0



I suppose these platform defines are harmless and un-referenced unless building 
for

the specified platform. Seems like the ARM one has been harmless for an x64 
build

so we could for now assume the PPC one is too.

Or you could use jdk-submit to prove this :-)



-phil.

On 8/8/18, 12:59 AM, Baesken, Matthias wrote:
Hello ,
please review this small adjustment for  the build of libsplashscreen ,  
especially the libpng parts .
Back then,  we had to fix the  build of  the libpng parts  in libsplashscreen  
on linux ppc64le   with  “8195615 : libsplashscreen linux ppc64le build error 
after libpng update”  .

However this introduced a small adjustment to pngpriv.h  that needs to be kept 
every time libpng  is updated   (happened recently when Phil updated the lib).
So I better want to remove the adjustment  to  pngpriv   from   8195615 ,  and 
instead change the build settings to fix the compilation  on linuxppc64 le .

Webrev/bug :

http://cr.openjdk.java.net/~mbaesken/webrevs/8209115.0/

https://bugs.openjdk.java.net/browse/JDK-8209115

Thanks ,
   Matthias



From: Philip Race 
Sent: Dienstag, 7. August 2018 17:15
To: Baesken, Matthias 

Cc: Doerr, Martin ; 
2d-...@openjdk.java.net; Simonis, Volker 
; Lindenmaier, Goetz 

Subject: Re: libsplashscreen compilation on ppc64 ( le) - was : RE: RFR 8195615 
: libsplashscreen linux ppc64le build error after libpng update

Works for me. Include build-dev on the review.
And splashscreen is considered an AWT feature so it should be awt-dev not 2d-dev
although you may want to reference back to this earlier exchange.

-phil.

On 8/7/18, 8:04 AM, Baesken, Matthias wrote:
Hello,  should  I  prepare a change  setting the  -DPNG_POWERPC_VSX=0   flag  
in the makefile  (see below) ?
Might  make future  libpng updates  more simple .

Best regards, Matthias

From: Baesken, Matthias
Sent: Donnerstag, 2. August 2018 17:28
To: 'Phil Race' ; Doerr, Martin 

Cc: Simonis, Volker ; Lindenmaier, 
Goetz 
Subject: RE: RFR 8195615 : libsplashscreen linux

RE: [RFR]: 8209115: adjust libsplashscreen linux ppc64le builds for easier libpng update - was : RE: RFR 8195615 : libsplashscreen linux ppc64le build error after libpng update

2018-08-13 Thread Baesken, Matthias

Thank‘s !
Can I have a second review please ?

Best regards, Matthias

From: Phil Race 
Sent: Freitag, 10. August 2018 20:12
To: Baesken, Matthias 
Cc: 'build-dev@openjdk.java.net' ; 
awt-...@openjdk.java.net
Subject: Re: [RFR]: 8209115: adjust libsplashscreen linux ppc64le builds for 
easier libpng update - was : RE: RFR 8195615 : libsplashscreen linux ppc64le 
build error after libpng update

+1 from me.

-phil.
On 08/10/2018 08:18 AM, Baesken, Matthias wrote:
Hello  , here is a new webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8209115.1/

I set PNG_POWERPC_VSX_OPTnow only on the  linux ppc  platforms .

Best regards, Matthias

From: Baesken, Matthias
Sent: Donnerstag, 9. August 2018 08:48
To: 'Philip Race' 
Cc: 'build-dev@openjdk.java.net' 
; 
awt-...@openjdk.java.net
Subject: RE: [RFR]: 8209115: adjust libsplashscreen linux ppc64le builds for 
easier libpng update - was : RE: RFR 8195615 : libsplashscreen linux ppc64le 
build error after libpng update

Ø  Seems like the ARM one has been harmless for an x64 build

  *   so we could for now assume the PPC one is too

Hi Phil ,
  I  will  guard  the define  for   the platform  where  we want to use  it -   
I think this is better for the future than just setting it  on all platforms .

And btw.  it has to be

PNG_POWERPC_VSX_OPT   not  PNG_POWERPC_VSX

☹  - my mistake .

For some reason the current setting still builds on our ppc64 (le) test machine 
   in the current codebase , strange !

Best regards, Matthias

From: Philip Race mailto:philip.r...@oracle.com>>
Sent: Donnerstag, 9. August 2018 04:09
To: Baesken, Matthias 
mailto:matthias.baes...@sap.com>>
Cc: 'build-dev@openjdk.java.net' 
mailto:build-dev@openjdk.java.net>>; 
awt-...@openjdk.java.net
Subject: Re: [RFR]: 8209115: adjust libsplashscreen linux ppc64le builds for 
easier libpng update - was : RE: RFR 8195615 : libsplashscreen linux ppc64le 
build error after libpng update

The only comment I have is about this

-  LIBSPLASHSCREEN_CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE 
-DPNG_ARM_NEON_OPT=0

+  LIBSPLASHSCREEN_CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE 
-DPNG_ARM_NEON_OPT=0 -DPNG_POWERPC_VSX=0

I suppose these platform defines are harmless and un-referenced unless building 
for

the specified platform. Seems like the ARM one has been harmless for an x64 
build

so we could for now assume the PPC one is too.

Or you could use jdk-submit to prove this :-)

-phil.

On 8/8/18, 12:59 AM, Baesken, Matthias wrote:
Hello ,
please review this small adjustment for  the build of libsplashscreen ,  
especially the libpng parts .
Back then,  we had to fix the  build of  the libpng parts  in libsplashscreen  
on linux ppc64le   with  “8195615 : libsplashscreen linux ppc64le build error 
after libpng update”  .

However this introduced a small adjustment to pngpriv.h  that needs to be kept 
every time libpng  is updated   (happened recently when Phil updated the lib).
So I better want to remove the adjustment  to  pngpriv   from   8195615 ,  and 
instead change the build settings to fix the compilation  on linuxppc64 le .

Webrev/bug :

http://cr.openjdk.java.net/~mbaesken/webrevs/8209115.0/

https://bugs.openjdk.java.net/browse/JDK-8209115

Thanks ,
  Matthias

From: Philip Race 
Sent: Dienstag, 7. August 2018 17:15
To: Baesken, Matthias 

Cc: Doerr, Martin ; 
2d-...@openjdk.java.net; Simonis, Volker 
; Lindenmaier, Goetz 

Subject: Re: libsplashscreen compilation on ppc64 ( le) - was : RE: RFR 8195615 
: libsplashscreen linux ppc64le build error after libpng update

Works for me. Include build-dev on the review.
And splashscreen is considered an AWT feature so it should be awt-dev not 2d-dev
although you may want to reference back to this earlier exchange.

-phil.

On 8/7/18, 8:04 AM, Baesken, Matthias wrote:
Hello,  should  I  prepare a change  setting the  -DPNG_POWERPC_VSX=0   flag  
in the makefile  (see below) ?
Might  make future  libpng updates  more simple .

Best regards, Matthias

From: Baesken, Matthias
Sent: Donnerstag, 2. August 2018 17:28
To: 'Phil Race' ; Doerr, 
Martin 
Cc: Simonis, Volker ; 
Lindenmaier, Goetz 
Subject: RE: RFR 8195615 : libsplashscreen linux ppc64le build error after 
libpng update - was : RE: jdk-hs ppc64le build error, probably related to 
libpng update

Hi Phil,  I added  -DPNG_POWERPC_VSX=0   to

Re: [12] RFR(XS) 8208463: jdk.internal.vm.compiler's module-info.java.extra contains duplicated provides of the same service interface

Re: [12] RFR(XS) 8208463: jdk.internal.vm.compiler's module-info.java.extra contains duplicated provides of the same service interface

[12] RFR(XS) 8208463: jdk.internal.vm.compiler's module-info.java.extra contains duplicated provides of the same service interface

Re: RFR (S) 8208665: Amend cross-compilation docs with qemu-debootstrap recipe

Re: RFR (S) 8208665: Amend cross-compilation docs with qemu-debootstrap recipe

RE: [RFR]: 8209115: adjust libsplashscreen linux ppc64le builds for easier libpng update - was : RE: RFR 8195615 : libsplashscreen linux ppc64le build error after libpng update

RFR (S) 8208665: Amend cross-compilation docs with qemu-debootstrap recipe

Re: [RFR]: 8209115: adjust libsplashscreen linux ppc64le builds for easier libpng update - was : RE: RFR 8195615 : libsplashscreen linux ppc64le build error after libpng update

RE: [RFR]: 8209115: adjust libsplashscreen linux ppc64le builds for easier libpng update - was : RE: RFR 8195615 : libsplashscreen linux ppc64le build error after libpng update

9 matches

Site Navigation

Mail list logo

Footer information