Discussion:
[OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library
Severin Gehwolf
2018-01-26 16:10:50 UTC
Permalink
Hi,

Could I please get a review for this rather small patch which
originally occurred for us on JDK 8 (Fedora) which recently switched to
building with "-Wl,-z,defs" linker flags. The result was a build
failure, due to unresolved symbols. Indeed libfontmanager.so should
have -lawt_headless in the list of dependent libs as symbols such as
AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. Some
more details are on the bug.

webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8196218

Testing: Build fails with configure option
--with-extra-ldflags="-Xlinker -z -Xlinker defs"
prior the fix. Succeeds after.

Question for 2d-folks/build-dev folks:

There is this snippet in the libfontmanager block in
make/lib/Awt2dLibraries.gmk, line 686:

LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) $(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \

It's my understanding that this is supposed to filter "-Wl,-z,defs"
from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a legit
reason when unresolved symbols at link time are OK? Besides, why does
it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 it's the
other way round. Xlinker flags are filtered, but -Wl,-z,defs is not.
Thoughts?

Thanks,
Severin
Erik Joelsson
2018-01-26 16:27:35 UTC
Permalink
Hello Severin,

If adding the -lawt_headless makes the code compile with -Wl,-z,defs,
then I would also like to see that filtering removed in the same patch.
However, I think someone from 2d needs to shed some light on the origin
of this. I would assume that at some point there was a reason for not
adding -lawt_headless to libfontmanager, and for that to work, someone
removed the -Wl,-z,defs from that linker command line. Tracing this
back, the removal of -z defs was there in the initial Mercurial commit,
so someone needs to go back into the really old archives to find answers
here.

Regarding -Xlinker vs -Wl, I believe we tried to unify usage to one or
the other at some point.

/Erik
Post by Severin Gehwolf
Hi,
Could I please get a review for this rather small patch which
originally occurred for us on JDK 8 (Fedora) which recently switched to
building with "-Wl,-z,defs" linker flags. The result was a build
failure, due to unresolved symbols. Indeed libfontmanager.so should
have -lawt_headless in the list of dependent libs as symbols such as
AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. Some
more details are on the bug.
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8196218
Testing: Build fails with configure option
--with-extra-ldflags="-Xlinker -z -Xlinker defs"
prior the fix. Succeeds after.
There is this snippet in the libfontmanager block in
LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) $(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
It's my understanding that this is supposed to filter "-Wl,-z,defs"
from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a legit
reason when unresolved symbols at link time are OK? Besides, why does
it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 it's the
other way round. Xlinker flags are filtered, but -Wl,-z,defs is not.
Thoughts?
Thanks,
Severin
Severin Gehwolf
2018-01-26 16:53:31 UTC
Permalink
Hi Erik,

Thanks for the feedback!
Post by Erik Joelsson
Hello Severin,
If adding the -lawt_headless makes the code compile with -Wl,-z,defs,
then I would also like to see that filtering removed in the same patch.
Agreed.
Post by Erik Joelsson
However, I think someone from 2d needs to shed some light on the origin
of this. I would assume that at some point there was a reason for not
adding -lawt_headless to libfontmanager, and for that to work, someone
removed the -Wl,-z,defs from that linker command line. Tracing this
back, the removal of -z defs was there in the initial Mercurial commit,
so someone needs to go back into the really old archives to find answers
here.
Interested to hear the answer to this. If that's still possible, that
is.
Post by Erik Joelsson
Regarding -Xlinker vs -Wl, I believe we tried to unify usage to one or
the other at some point.
Fair enough. It's still sub-optimal that it might fail for one variant
but not the other. If it's filtering, it should do it for both
variants. W discovered this in the first place because the flags that
get set are -Wl,-z,defs yet the JDK 8 filter is for -Xlinker. Now with
JDK 11 it's the other way around.

With that being said, this discussion is a moot point if we can remove
this.

Thanks,
Severin
Post by Erik Joelsson
/Erik
Post by Severin Gehwolf
Hi,
Could I please get a review for this rather small patch which
originally occurred for us on JDK 8 (Fedora) which recently switched to
building with "-Wl,-z,defs" linker flags. The result was a build
failure, due to unresolved symbols. Indeed libfontmanager.so should
have -lawt_headless in the list of dependent libs as symbols such as
AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. Some
more details are on the bug.
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8196218
Testing: Build fails with configure option
--with-extra-ldflags="-Xlinker -z -Xlinker defs"
prior the fix. Succeeds after.
There is this snippet in the libfontmanager block in
LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) $(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
It's my understanding that this is supposed to filter "-Wl,-z,defs"
from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a legit
reason when unresolved symbols at link time are OK? Besides, why does
it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 it's the
other way round. Xlinker flags are filtered, but -Wl,-z,defs is not.
Thoughts?
Thanks,
Severin
Phil Race
2018-01-26 16:44:05 UTC
Permalink
When this was fixed for Solaris
https://bugs.openjdk.java.net/browse/JDK-8071710
the observed problem was not building (although it could have been) but
at runtime.
I think you can verify what you've done with "ldd" ..

This patch adds awt_headless.so, but does not remove awt.so.

Perhaps the line

LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX)
After your fix I expect "ldd" should not need to show awt .. just awt_headless

ie linux should not have this -lawt dependency any more and the -lawt dependency should be specific to windows + mac ..
Post by Severin Gehwolf
Hi,
Could I please get a review for this rather small patch which
originally occurred for us on JDK 8 (Fedora) which recently switched to
building with "-Wl,-z,defs" linker flags. The result was a build
failure, due to unresolved symbols. Indeed libfontmanager.so should
have -lawt_headless in the list of dependent libs as symbols such as
AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. Some
more details are on the bug.
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8196218
Testing: Build fails with configure option
--with-extra-ldflags="-Xlinker -z -Xlinker defs"
prior the fix. Succeeds after.
I don't know about this, build folks probably know.

-phil.
Post by Severin Gehwolf
There is this snippet in the libfontmanager block in
LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) $(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
It's my understanding that this is supposed to filter "-Wl,-z,defs"
from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a legit
reason when unresolved symbols at link time are OK? Besides, why does
it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 it's the
other way round. Xlinker flags are filtered, but -Wl,-z,defs is not.
Thoughts?
Thanks,
Severin
Erik Joelsson
2018-01-26 16:54:31 UTC
Permalink
Post by Phil Race
When this was fixed for Solaris
https://bugs.openjdk.java.net/browse/JDK-8071710
the observed problem was not building (although it could have been)
but at runtime.
I think you can verify what you've done with "ldd" ..
This patch adds awt_headless.so, but does not remove awt.so.
Perhaps the line
LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX)
After your fix I expect "ldd" should not need to show awt .. just awt_headless
ie linux should not have this -lawt dependency any more and the -lawt
dependency should be specific to windows + mac ..
So we already use -lawt_headless on solaris and aix, then I really can't
see a reason not to do the same for linux.
Post by Phil Race
Post by Severin Gehwolf
Hi,
Could I please get a review for this rather small patch which
originally occurred for us on JDK 8 (Fedora) which recently switched to
building with "-Wl,-z,defs" linker flags. The result was a build
failure, due to unresolved symbols. Indeed libfontmanager.so should
have -lawt_headless in the list of dependent libs as symbols such as
AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. Some
more details are on the bug.
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8196218
Testing: Build fails with configure option
          --with-extra-ldflags="-Xlinker -z -Xlinker defs"
          prior the fix. Succeeds after.
I don't know about this, build folks probably know.
This is from way ahead of my time. The filtering is simply the
build-infra way of achieving the same thing as in the old build system.
Here is the corresponding code in jdk7:

$ hg annotate make/sun/font/Makefile
...
   0: #
   0: # Created without -z defs on linux
   0: #
   0: ifeq ($(PLATFORM), linux)
   0:   LDFLAGS_DEFS_OPTION =
   0: endif
...

/Erik
Post by Phil Race
-phil.
Post by Severin Gehwolf
There is this snippet in the libfontmanager block in
     LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))
$(LDFLAGS_CXX_JDK) \
         $(call SET_SHARED_LIBRARY_ORIGIN), \
It's my understanding that this is supposed to filter "-Wl,-z,defs"
from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a legit
reason when unresolved symbols at link time are OK? Besides, why does
it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 it's the
other way round. Xlinker flags are filtered, but -Wl,-z,defs is not.
Thoughts?
Thanks,
Severin
Severin Gehwolf
2018-01-26 17:02:22 UTC
Permalink
Post by Erik Joelsson
Post by Phil Race
When this was fixed for Solaris
https://bugs.openjdk.java.net/browse/JDK-8071710
the observed problem was not building (although it could have been)
but at runtime.
I think you can verify what you've done with "ldd" ..
This patch adds awt_headless.so, but does not remove awt.so.
Perhaps the line
LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX)
After your fix I expect "ldd" should not need to show awt .. just awt_headless
ie linux should not have this -lawt dependency any more and the -lawt
dependency should be specific to windows + mac ..
Thanks for the review, Phil. I'll post an updated webrev shortly.

Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on
platforms that need it? solaris, linux, aix should already be fine
without filtering.

Thanks,
Severin
Post by Erik Joelsson
So we already use -lawt_headless on solaris and aix, then I really can't
see a reason not to do the same for linux.
Post by Phil Race
Post by Severin Gehwolf
Hi,
Could I please get a review for this rather small patch which
originally occurred for us on JDK 8 (Fedora) which recently switched to
building with "-Wl,-z,defs" linker flags. The result was a build
failure, due to unresolved symbols. Indeed libfontmanager.so should
have -lawt_headless in the list of dependent libs as symbols such as
AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. Some
more details are on the bug.
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8196218
Testing: Build fails with configure option
--with-extra-ldflags="-Xlinker -z -Xlinker defs"
prior the fix. Succeeds after.
I don't know about this, build folks probably know.
This is from way ahead of my time. The filtering is simply the
build-infra way of achieving the same thing as in the old build system.
$ hg annotate make/sun/font/Makefile
...
0: #
0: # Created without -z defs on linux
0: #
0: ifeq ($(PLATFORM), linux)
0: LDFLAGS_DEFS_OPTION =
0: endif
...
/Erik
Post by Phil Race
-phil.
Post by Severin Gehwolf
There is this snippet in the libfontmanager block in
LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))
$(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
It's my understanding that this is supposed to filter "-Wl,-z,defs"
from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a legit
reason when unresolved symbols at link time are OK? Besides, why does
it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 it's the
other way round. Xlinker flags are filtered, but -Wl,-z,defs is not.
Thoughts?
Thanks,
Severin
Erik Joelsson
2018-01-26 17:15:39 UTC
Permalink
Post by Severin Gehwolf
Post by Erik Joelsson
Post by Phil Race
When this was fixed for Solaris
https://bugs.openjdk.java.net/browse/JDK-8071710
the observed problem was not building (although it could have been)
but at runtime.
I think you can verify what you've done with "ldd" ..
This patch adds awt_headless.so, but does not remove awt.so.
Perhaps the line
LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX)
After your fix I expect "ldd" should not need to show awt .. just awt_headless
ie linux should not have this -lawt dependency any more and the -lawt
dependency should be specific to windows + mac ..
Thanks for the review, Phil. I'll post an updated webrev shortly.
Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on
platforms that need it? solaris, linux, aix should already be fine
without filtering.
I would say try removing the filtering. The affected flags are currently
only set on linux and solaris. I will do a test build on the latter and
see if the filtering is actually needed.

/Erik
Post by Severin Gehwolf
Thanks,
Severin
Post by Erik Joelsson
So we already use -lawt_headless on solaris and aix, then I really can't
see a reason not to do the same for linux.
Post by Phil Race
Post by Severin Gehwolf
Hi,
Could I please get a review for this rather small patch which
originally occurred for us on JDK 8 (Fedora) which recently switched to
building with "-Wl,-z,defs" linker flags. The result was a build
failure, due to unresolved symbols. Indeed libfontmanager.so should
have -lawt_headless in the list of dependent libs as symbols such as
AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. Some
more details are on the bug.
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8196218
Testing: Build fails with configure option
--with-extra-ldflags="-Xlinker -z -Xlinker defs"
prior the fix. Succeeds after.
I don't know about this, build folks probably know.
This is from way ahead of my time. The filtering is simply the
build-infra way of achieving the same thing as in the old build system.
$ hg annotate make/sun/font/Makefile
...
0: #
0: # Created without -z defs on linux
0: #
0: ifeq ($(PLATFORM), linux)
0: LDFLAGS_DEFS_OPTION =
0: endif
...
/Erik
Post by Phil Race
-phil.
Post by Severin Gehwolf
There is this snippet in the libfontmanager block in
LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))
$(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
It's my understanding that this is supposed to filter "-Wl,-z,defs"
from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a legit
reason when unresolved symbols at link time are OK? Besides, why does
it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 it's the
other way round. Xlinker flags are filtered, but -Wl,-z,defs is not.
Thoughts?
Thanks,
Severin
Erik Joelsson
2018-01-26 17:23:41 UTC
Permalink
This patch builds on Solaris:

diff -r 50cd89fe209f make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk
+++ b/make/lib/Awt2dLibraries.gmk
@@ -683,15 +683,15 @@
         hidevf w_novirtualdescr arrowrtn2, \
     DISABLED_WARNINGS_microsoft := 4267 4244 4018 4090 4996 4146 4334
4819 4101, \
     MAPFILE := $(BUILD_LIBFONTMANAGER_MAPFILE), \
-    LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))
$(LDFLAGS_CXX_JDK) \
+    LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
         $(call SET_SHARED_LIBRARY_ORIGIN), \
     LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \
     LDFLAGS_macosx := -undefined dynamic_lookup, \
     LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \
     LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX), \
-    LIBS_linux := -lc, \
+    LIBS_linux := -lawt_headless -lc, \
     LIBS_solaris := -lawt_headless -lc, \
     LIBS_aix := -lawt_headless,\

I could not remove -lawt however.

/Erik
Post by Erik Joelsson
Post by Severin Gehwolf
Post by Erik Joelsson
Post by Phil Race
When this was fixed for Solaris
https://bugs.openjdk.java.net/browse/JDK-8071710
the observed problem was not building (although it could have been)
but at runtime.
I think you can verify what you've done with "ldd" ..
This patch adds awt_headless.so, but does not remove awt.so.
Perhaps the line
LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX)
After your fix I expect "ldd" should not need to show awt .. just awt_headless
ie linux should not have this -lawt dependency any more and the -lawt
dependency should be specific to windows + mac ..
Thanks for the review, Phil. I'll post an updated webrev shortly.
Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on
platforms that need it? solaris, linux, aix should already be fine
without filtering.
I would say try removing the filtering. The affected flags are
currently only set on linux and solaris. I will do a test build on the
latter and see if the filtering is actually needed.
/Erik
Post by Severin Gehwolf
Thanks,
Severin
Post by Erik Joelsson
So we already use -lawt_headless on solaris and aix, then I really can't
see a reason not to do the same for linux.
Post by Phil Race
Post by Severin Gehwolf
Hi,
Could I please get a review for this rather small patch which
originally occurred for us on JDK 8 (Fedora) which recently switched to
building with "-Wl,-z,defs" linker flags. The result was a build
failure, due to unresolved symbols. Indeed libfontmanager.so should
have -lawt_headless in the list of dependent libs as symbols such as
AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. Some
more details are on the bug.
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8196218
Testing: Build fails with configure option
           --with-extra-ldflags="-Xlinker -z -Xlinker defs"
           prior the fix. Succeeds after.
I don't know about this, build folks probably know.
This is from way ahead of my time. The filtering is simply the
build-infra way of achieving the same thing as in the old build system.
$ hg annotate make/sun/font/Makefile
...
     0: #
     0: # Created without -z defs on linux
     0: #
     0: ifeq ($(PLATFORM), linux)
     0:   LDFLAGS_DEFS_OPTION =
     0: endif
...
/Erik
Post by Phil Race
-phil.
Post by Severin Gehwolf
There is this snippet in the libfontmanager block in
      LDFLAGS := $(subst
-Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))
$(LDFLAGS_CXX_JDK) \
          $(call SET_SHARED_LIBRARY_ORIGIN), \
It's my understanding that this is supposed to filter "-Wl,-z,defs"
from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a legit
reason when unresolved symbols at link time are OK? Besides, why does
it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 it's the
other way round. Xlinker flags are filtered, but -Wl,-z,defs is not.
Thoughts?
Thanks,
Severin
Phil Race
2018-01-26 17:44:08 UTC
Permalink
Post by Erik Joelsson
I could not remove -lawt however.
Ah yes, Erik sent me the errors and yes there are some 2D functions that are
defined in libawt that fontmanager needs for text rendering support, so
we can't remove that.

libawt on these platforms with separate headless and xawt libraries
could have
more aptly be called lib2d .. since most of the true AWT functionality
is in the xawt library.


-phil.
Post by Erik Joelsson
diff -r 50cd89fe209f make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk
+++ b/make/lib/Awt2dLibraries.gmk
@@ -683,15 +683,15 @@
hidevf w_novirtualdescr arrowrtn2, \
DISABLED_WARNINGS_microsoft := 4267 4244 4018 4090 4996 4146 4334
4819 4101, \
MAPFILE := $(BUILD_LIBFONTMANAGER_MAPFILE), \
- LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))
$(LDFLAGS_CXX_JDK) \
+ LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \
LDFLAGS_macosx := -undefined dynamic_lookup, \
LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \
LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX), \
- LIBS_linux := -lc, \
+ LIBS_linux := -lawt_headless -lc, \
LIBS_solaris := -lawt_headless -lc, \
LIBS_aix := -lawt_headless,\
I could not remove -lawt however.
/Erik
Post by Erik Joelsson
Post by Severin Gehwolf
Post by Erik Joelsson
Post by Phil Race
When this was fixed for Solaris
https://bugs.openjdk.java.net/browse/JDK-8071710
the observed problem was not building (although it could have been)
but at runtime.
I think you can verify what you've done with "ldd" ..
This patch adds awt_headless.so, but does not remove awt.so.
Perhaps the line
LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX)
After your fix I expect "ldd" should not need to show awt .. just awt_headless
ie linux should not have this -lawt dependency any more and the -lawt
dependency should be specific to windows + mac ..
Thanks for the review, Phil. I'll post an updated webrev shortly.
Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on
platforms that need it? solaris, linux, aix should already be fine
without filtering.
I would say try removing the filtering. The affected flags are
currently only set on linux and solaris. I will do a test build on
the latter and see if the filtering is actually needed.
/Erik
Post by Severin Gehwolf
Thanks,
Severin
Post by Erik Joelsson
So we already use -lawt_headless on solaris and aix, then I really can't
see a reason not to do the same for linux.
Post by Phil Race
Post by Severin Gehwolf
Hi,
Could I please get a review for this rather small patch which
originally occurred for us on JDK 8 (Fedora) which recently switched to
building with "-Wl,-z,defs" linker flags. The result was a build
failure, due to unresolved symbols. Indeed libfontmanager.so should
have -lawt_headless in the list of dependent libs as symbols such as
AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. Some
more details are on the bug.
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8196218
Testing: Build fails with configure option
--with-extra-ldflags="-Xlinker -z -Xlinker defs"
prior the fix. Succeeds after.
I don't know about this, build folks probably know.
This is from way ahead of my time. The filtering is simply the
build-infra way of achieving the same thing as in the old build system.
$ hg annotate make/sun/font/Makefile
...
0: #
0: # Created without -z defs on linux
0: #
0: ifeq ($(PLATFORM), linux)
0: LDFLAGS_DEFS_OPTION =
0: endif
...
/Erik
Post by Phil Race
-phil.
Post by Severin Gehwolf
There is this snippet in the libfontmanager block in
LDFLAGS := $(subst
-Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))
$(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
It's my understanding that this is supposed to filter "-Wl,-z,defs"
from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a legit
reason when unresolved symbols at link time are OK? Besides, why does
it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 it's the
other way round. Xlinker flags are filtered, but -Wl,-z,defs is not.
Thoughts?
Thanks,
Severin
Severin Gehwolf
2018-01-29 09:39:38 UTC
Permalink
Hi,

Updated webrev which removes the linker flags filtering. Linking with
the awt lib is being kept. ldd confirmed what Erik found out elsewhere:

$ find build/linux-x86_64-normal-server-release/images/jdk -name libfontmanager.so
build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so
$ ldd build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so
ldd: warning: you do not have execution permission for `build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so'
linux-vdso.so.1 (0x00007ffe13cc5000)
libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007fb58e204000)
libawt.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt.so (0x00007fb58df34000)
libjava.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libjava.so (0x00007fb58dd07000)
libjvm.so => not found
libawt_headless.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt_headless.so (0x00007fb58dafe000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fb58d778000)
libm.so.6 => /lib64/libm.so.6 (0x00007fb58d423000)
libc.so.6 => /lib64/libc.so.6 (0x00007fb58d040000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb58ce29000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fb58cc18000)
libpng16.so.16 => /lib64/libpng16.so.16 (0x00007fb58c9e5000)
libz.so.1 => /lib64/libz.so.1 (0x00007fb58c7ce000)
libjvm.so => not found
libdl.so.2 => /lib64/libdl.so.2 (0x00007fb58c5ca000)
libjvm.so => not found
libverify.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libverify.so (0x00007fb58c3bb000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb58e74f000)
libjvm.so => not found
libjvm.so => not found

http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/

How does this look?

Do I need an Oracle sponsor for this or can I push this to jdk/jdk
myself.

Thanks,
Severin
Post by Phil Race
Post by Erik Joelsson
I could not remove -lawt however.
Ah yes, Erik sent me the errors and yes there are some 2D functions that are
defined in libawt that fontmanager needs for text rendering support, so
we can't remove that.
libawt on these platforms with separate headless and xawt libraries
could have
more aptly be called lib2d .. since most of the true AWT functionality
is in the xawt library.
-phil.
Post by Erik Joelsson
diff -r 50cd89fe209f make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk
+++ b/make/lib/Awt2dLibraries.gmk
@@ -683,15 +683,15 @@
hidevf w_novirtualdescr arrowrtn2, \
DISABLED_WARNINGS_microsoft := 4267 4244 4018 4090 4996 4146 4334
4819 4101, \
MAPFILE := $(BUILD_LIBFONTMANAGER_MAPFILE), \
- LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))
$(LDFLAGS_CXX_JDK) \
+ LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \
LDFLAGS_macosx := -undefined dynamic_lookup, \
LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \
LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX), \
- LIBS_linux := -lc, \
+ LIBS_linux := -lawt_headless -lc, \
LIBS_solaris := -lawt_headless -lc, \
LIBS_aix := -lawt_headless,\
I could not remove -lawt however.
/Erik
Post by Erik Joelsson
Post by Severin Gehwolf
Post by Erik Joelsson
Post by Phil Race
When this was fixed for Solaris
https://bugs.openjdk.java.net/browse/JDK-8071710
the observed problem was not building (although it could have been)
but at runtime.
I think you can verify what you've done with "ldd" ..
This patch adds awt_headless.so, but does not remove awt.so.
Perhaps the line
LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX)
After your fix I expect "ldd" should not need to show awt .. just
awt_headless
ie linux should not have this -lawt dependency any more and the -lawt
dependency should be specific to windows + mac ..
Thanks for the review, Phil. I'll post an updated webrev shortly.
Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on
platforms that need it? solaris, linux, aix should already be fine
without filtering.
I would say try removing the filtering. The affected flags are
currently only set on linux and solaris. I will do a test build on
the latter and see if the filtering is actually needed.
/Erik
Post by Severin Gehwolf
Thanks,
Severin
Post by Erik Joelsson
So we already use -lawt_headless on solaris and aix, then I really can't
see a reason not to do the same for linux.
Post by Phil Race
Post by Severin Gehwolf
Hi,
Could I please get a review for this rather small patch which
originally occurred for us on JDK 8 (Fedora) which recently
switched to
building with "-Wl,-z,defs" linker flags. The result was a build
failure, due to unresolved symbols. Indeed libfontmanager.so should
have -lawt_headless in the list of dependent libs as symbols such as
AWTLoadFont come from libawt_headless.so, not libawt.so on Linux.
Some
more details are on the bug.
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8196218
Testing: Build fails with configure option
--with-extra-ldflags="-Xlinker -z -Xlinker defs"
prior the fix. Succeeds after.
I don't know about this, build folks probably know.
This is from way ahead of my time. The filtering is simply the
build-infra way of achieving the same thing as in the old build system.
$ hg annotate make/sun/font/Makefile
...
0: #
0: # Created without -z defs on linux
0: #
0: ifeq ($(PLATFORM), linux)
0: LDFLAGS_DEFS_OPTION =
0: endif
...
/Erik
Post by Phil Race
-phil.
Post by Severin Gehwolf
There is this snippet in the libfontmanager block in
LDFLAGS := $(subst
-Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))
$(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
It's my understanding that this is supposed to filter "-Wl,-z,defs"
from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a
legit
reason when unresolved symbols at link time are OK? Besides, why
does
it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8
it's the
other way round. Xlinker flags are filtered, but -Wl,-z,defs is not.
Thoughts?
Thanks,
Severin
Erik Joelsson
2018-01-29 16:29:59 UTC
Permalink
This looks good to me. Good catch on the dependency declaration further
down. I don't see any reason this would need a sponsor, jdk/jdk should
be open.

/Erik
Post by Severin Gehwolf
Hi,
Updated webrev which removes the linker flags filtering. Linking with
$ find build/linux-x86_64-normal-server-release/images/jdk -name libfontmanager.so
build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so
$ ldd build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so
ldd: warning: you do not have execution permission for `build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so'
linux-vdso.so.1 (0x00007ffe13cc5000)
libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007fb58e204000)
libawt.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt.so (0x00007fb58df34000)
libjava.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libjava.so (0x00007fb58dd07000)
libjvm.so => not found
libawt_headless.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt_headless.so (0x00007fb58dafe000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fb58d778000)
libm.so.6 => /lib64/libm.so.6 (0x00007fb58d423000)
libc.so.6 => /lib64/libc.so.6 (0x00007fb58d040000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb58ce29000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fb58cc18000)
libpng16.so.16 => /lib64/libpng16.so.16 (0x00007fb58c9e5000)
libz.so.1 => /lib64/libz.so.1 (0x00007fb58c7ce000)
libjvm.so => not found
libdl.so.2 => /lib64/libdl.so.2 (0x00007fb58c5ca000)
libjvm.so => not found
libverify.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libverify.so (0x00007fb58c3bb000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb58e74f000)
libjvm.so => not found
libjvm.so => not found
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/
How does this look?
Do I need an Oracle sponsor for this or can I push this to jdk/jdk
myself.
Thanks,
Severin
Post by Phil Race
Post by Erik Joelsson
I could not remove -lawt however.
Ah yes, Erik sent me the errors and yes there are some 2D functions that are
defined in libawt that fontmanager needs for text rendering support, so
we can't remove that.
libawt on these platforms with separate headless and xawt libraries
could have
more aptly be called lib2d .. since most of the true AWT functionality
is in the xawt library.
-phil.
Post by Erik Joelsson
diff -r 50cd89fe209f make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk
+++ b/make/lib/Awt2dLibraries.gmk
@@ -683,15 +683,15 @@
hidevf w_novirtualdescr arrowrtn2, \
DISABLED_WARNINGS_microsoft := 4267 4244 4018 4090 4996 4146 4334
4819 4101, \
MAPFILE := $(BUILD_LIBFONTMANAGER_MAPFILE), \
- LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))
$(LDFLAGS_CXX_JDK) \
+ LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \
LDFLAGS_macosx := -undefined dynamic_lookup, \
LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \
LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX), \
- LIBS_linux := -lc, \
+ LIBS_linux := -lawt_headless -lc, \
LIBS_solaris := -lawt_headless -lc, \
LIBS_aix := -lawt_headless,\
I could not remove -lawt however.
/Erik
Post by Erik Joelsson
Post by Severin Gehwolf
Post by Erik Joelsson
Post by Phil Race
When this was fixed for Solaris
https://bugs.openjdk.java.net/browse/JDK-8071710
the observed problem was not building (although it could have been)
but at runtime.
I think you can verify what you've done with "ldd" ..
This patch adds awt_headless.so, but does not remove awt.so.
Perhaps the line
LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX)
After your fix I expect "ldd" should not need to show awt .. just awt_headless
ie linux should not have this -lawt dependency any more and the -lawt
dependency should be specific to windows + mac ..
Thanks for the review, Phil. I'll post an updated webrev shortly.
Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on
platforms that need it? solaris, linux, aix should already be fine
without filtering.
I would say try removing the filtering. The affected flags are
currently only set on linux and solaris. I will do a test build on
the latter and see if the filtering is actually needed.
/Erik
Post by Severin Gehwolf
Thanks,
Severin
Post by Erik Joelsson
So we already use -lawt_headless on solaris and aix, then I really can't
see a reason not to do the same for linux.
Post by Phil Race
Post by Severin Gehwolf
Hi,
Could I please get a review for this rather small patch which
originally occurred for us on JDK 8 (Fedora) which recently switched to
building with "-Wl,-z,defs" linker flags. The result was a build
failure, due to unresolved symbols. Indeed libfontmanager.so should
have -lawt_headless in the list of dependent libs as symbols such as
AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. Some
more details are on the bug.
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8196218
Testing: Build fails with configure option
--with-extra-ldflags="-Xlinker -z -Xlinker defs"
prior the fix. Succeeds after.
I don't know about this, build folks probably know.
This is from way ahead of my time. The filtering is simply the
build-infra way of achieving the same thing as in the old build system.
$ hg annotate make/sun/font/Makefile
...
0: #
0: # Created without -z defs on linux
0: #
0: ifeq ($(PLATFORM), linux)
0: LDFLAGS_DEFS_OPTION =
0: endif
...
/Erik
Post by Phil Race
-phil.
Post by Severin Gehwolf
There is this snippet in the libfontmanager block in
LDFLAGS := $(subst
-Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))
$(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
It's my understanding that this is supposed to filter "-Wl,-z,defs"
from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a legit
reason when unresolved symbols at link time are OK? Besides, why does
it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 it's the
other way round. Xlinker flags are filtered, but -Wl,-z,defs is not.
Thoughts?
Thanks,
Severin
Severin Gehwolf
2018-01-29 16:50:50 UTC
Permalink
Post by Erik Joelsson
This looks good to me. Good catch on the dependency declaration further
down.
Yes, the build failed for me without that :)
Post by Erik Joelsson
I don't see any reason this would need a sponsor, jdk/jdk should
be open.
Thanks for the review! I'll run this through the new submit repo and -
barring unforeseen circumstances - will push it once approved.

Cheers,
Severin
Post by Erik Joelsson
Post by Severin Gehwolf
Hi,
Updated webrev which removes the linker flags filtering. Linking with
$ find build/linux-x86_64-normal-server-release/images/jdk -name libfontmanager.so
build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so
$ ldd build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so
ldd: warning: you do not have execution permission for `build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so'
linux-vdso.so.1 (0x00007ffe13cc5000)
libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007fb58e204000)
libawt.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt.so (0x00007fb58df34000)
libjava.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libjava.so (0x00007fb58dd07000)
libjvm.so => not found
libawt_headless.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt_headless.so (0x00007fb58dafe000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fb58d778000)
libm.so.6 => /lib64/libm.so.6 (0x00007fb58d423000)
libc.so.6 => /lib64/libc.so.6 (0x00007fb58d040000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb58ce29000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fb58cc18000)
libpng16.so.16 => /lib64/libpng16.so.16 (0x00007fb58c9e5000)
libz.so.1 => /lib64/libz.so.1 (0x00007fb58c7ce000)
libjvm.so => not found
libdl.so.2 => /lib64/libdl.so.2 (0x00007fb58c5ca000)
libjvm.so => not found
libverify.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libverify.so (0x00007fb58c3bb000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb58e74f000)
libjvm.so => not found
libjvm.so => not found
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/
How does this look?
Do I need an Oracle sponsor for this or can I push this to jdk/jdk
myself.
Thanks,
Severin
Post by Phil Race
Post by Erik Joelsson
I could not remove -lawt however.
Ah yes, Erik sent me the errors and yes there are some 2D functions that are
defined in libawt that fontmanager needs for text rendering support, so
we can't remove that.
libawt on these platforms with separate headless and xawt libraries
could have
more aptly be called lib2d .. since most of the true AWT functionality
is in the xawt library.
-phil.
Post by Erik Joelsson
diff -r 50cd89fe209f make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk
+++ b/make/lib/Awt2dLibraries.gmk
@@ -683,15 +683,15 @@
hidevf w_novirtualdescr arrowrtn2, \
DISABLED_WARNINGS_microsoft := 4267 4244 4018 4090 4996 4146 4334
4819 4101, \
MAPFILE := $(BUILD_LIBFONTMANAGER_MAPFILE), \
- LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))
$(LDFLAGS_CXX_JDK) \
+ LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \
LDFLAGS_macosx := -undefined dynamic_lookup, \
LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \
LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX), \
- LIBS_linux := -lc, \
+ LIBS_linux := -lawt_headless -lc, \
LIBS_solaris := -lawt_headless -lc, \
LIBS_aix := -lawt_headless,\
I could not remove -lawt however.
/Erik
Post by Erik Joelsson
Post by Severin Gehwolf
Post by Erik Joelsson
Post by Phil Race
When this was fixed for Solaris
https://bugs.openjdk.java.net/browse/JDK-8071710
the observed problem was not building (although it could have been)
but at runtime.
I think you can verify what you've done with "ldd" ..
This patch adds awt_headless.so, but does not remove awt.so.
Perhaps the line
LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX)
After your fix I expect "ldd" should not need to show awt .. just
awt_headless
ie linux should not have this -lawt dependency any more and the -lawt
dependency should be specific to windows + mac ..
Thanks for the review, Phil. I'll post an updated webrev shortly.
Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on
platforms that need it? solaris, linux, aix should already be fine
without filtering.
I would say try removing the filtering. The affected flags are
currently only set on linux and solaris. I will do a test build on
the latter and see if the filtering is actually needed.
/Erik
Post by Severin Gehwolf
Thanks,
Severin
Post by Erik Joelsson
So we already use -lawt_headless on solaris and aix, then I really
can't
see a reason not to do the same for linux.
Post by Phil Race
Post by Severin Gehwolf
Hi,
Could I please get a review for this rather small patch which
originally occurred for us on JDK 8 (Fedora) which recently
switched to
building with "-Wl,-z,defs" linker flags. The result was a build
failure, due to unresolved symbols. Indeed libfontmanager.so should
have -lawt_headless in the list of dependent libs as symbols such as
AWTLoadFont come from libawt_headless.so, not libawt.so on Linux.
Some
more details are on the bug.
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8196218
Testing: Build fails with configure option
--with-extra-ldflags="-Xlinker -z -Xlinker defs"
prior the fix. Succeeds after.
I don't know about this, build folks probably know.
This is from way ahead of my time. The filtering is simply the
build-infra way of achieving the same thing as in the old build
system.
$ hg annotate make/sun/font/Makefile
...
0: #
0: # Created without -z defs on linux
0: #
0: ifeq ($(PLATFORM), linux)
0: LDFLAGS_DEFS_OPTION =
0: endif
...
/Erik
Post by Phil Race
-phil.
Post by Severin Gehwolf
There is this snippet in the libfontmanager block in
LDFLAGS := $(subst
-Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))
$(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
It's my understanding that this is supposed to filter "-Wl,-z,defs"
from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a
legit
reason when unresolved symbols at link time are OK? Besides, why
does
it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8
it's the
other way round. Xlinker flags are filtered, but -Wl,-z,defs is not.
Thoughts?
Thanks,
Severin
Severin Gehwolf
2018-01-29 18:53:51 UTC
Permalink
Hi Phil,

Are you OK with the latest webrev as well?
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/

Thanks,
Severin
Post by Erik Joelsson
This looks good to me. Good catch on the dependency declaration further
down. I don't see any reason this would need a sponsor, jdk/jdk should
be open.
/Erik
Post by Severin Gehwolf
Hi,
Updated webrev which removes the linker flags filtering. Linking with
$ find build/linux-x86_64-normal-server-release/images/jdk -name libfontmanager.so
build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so
$ ldd build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so
ldd: warning: you do not have execution permission for `build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so'
linux-vdso.so.1 (0x00007ffe13cc5000)
libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007fb58e204000)
libawt.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt.so (0x00007fb58df34000)
libjava.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libjava.so (0x00007fb58dd07000)
libjvm.so => not found
libawt_headless.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt_headless.so (0x00007fb58dafe000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fb58d778000)
libm.so.6 => /lib64/libm.so.6 (0x00007fb58d423000)
libc.so.6 => /lib64/libc.so.6 (0x00007fb58d040000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb58ce29000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fb58cc18000)
libpng16.so.16 => /lib64/libpng16.so.16 (0x00007fb58c9e5000)
libz.so.1 => /lib64/libz.so.1 (0x00007fb58c7ce000)
libjvm.so => not found
libdl.so.2 => /lib64/libdl.so.2 (0x00007fb58c5ca000)
libjvm.so => not found
libverify.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libverify.so (0x00007fb58c3bb000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb58e74f000)
libjvm.so => not found
libjvm.so => not found
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/
How does this look?
Do I need an Oracle sponsor for this or can I push this to jdk/jdk
myself.
Thanks,
Severin
Post by Phil Race
Post by Erik Joelsson
I could not remove -lawt however.
Ah yes, Erik sent me the errors and yes there are some 2D functions that are
defined in libawt that fontmanager needs for text rendering support, so
we can't remove that.
libawt on these platforms with separate headless and xawt libraries
could have
more aptly be called lib2d .. since most of the true AWT functionality
is in the xawt library.
-phil.
Post by Erik Joelsson
diff -r 50cd89fe209f make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk
+++ b/make/lib/Awt2dLibraries.gmk
@@ -683,15 +683,15 @@
hidevf w_novirtualdescr arrowrtn2, \
DISABLED_WARNINGS_microsoft := 4267 4244 4018 4090 4996 4146 4334
4819 4101, \
MAPFILE := $(BUILD_LIBFONTMANAGER_MAPFILE), \
- LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))
$(LDFLAGS_CXX_JDK) \
+ LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \
LDFLAGS_macosx := -undefined dynamic_lookup, \
LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \
LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX), \
- LIBS_linux := -lc, \
+ LIBS_linux := -lawt_headless -lc, \
LIBS_solaris := -lawt_headless -lc, \
LIBS_aix := -lawt_headless,\
I could not remove -lawt however.
/Erik
Post by Erik Joelsson
Post by Severin Gehwolf
Post by Erik Joelsson
Post by Phil Race
When this was fixed for Solaris
https://bugs.openjdk.java.net/browse/JDK-8071710
the observed problem was not building (although it could have been)
but at runtime.
I think you can verify what you've done with "ldd" ..
This patch adds awt_headless.so, but does not remove awt.so.
Perhaps the line
LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX)
After your fix I expect "ldd" should not need to show awt .. just
awt_headless
ie linux should not have this -lawt dependency any more and the -lawt
dependency should be specific to windows + mac ..
Thanks for the review, Phil. I'll post an updated webrev shortly.
Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on
platforms that need it? solaris, linux, aix should already be fine
without filtering.
I would say try removing the filtering. The affected flags are
currently only set on linux and solaris. I will do a test build on
the latter and see if the filtering is actually needed.
/Erik
Post by Severin Gehwolf
Thanks,
Severin
Post by Erik Joelsson
So we already use -lawt_headless on solaris and aix, then I really
can't
see a reason not to do the same for linux.
Post by Phil Race
Post by Severin Gehwolf
Hi,
Could I please get a review for this rather small patch which
originally occurred for us on JDK 8 (Fedora) which recently
switched to
building with "-Wl,-z,defs" linker flags. The result was a build
failure, due to unresolved symbols. Indeed libfontmanager.so should
have -lawt_headless in the list of dependent libs as symbols such as
AWTLoadFont come from libawt_headless.so, not libawt.so on Linux.
Some
more details are on the bug.
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8196218
Testing: Build fails with configure option
--with-extra-ldflags="-Xlinker -z -Xlinker defs"
prior the fix. Succeeds after.
I don't know about this, build folks probably know.
This is from way ahead of my time. The filtering is simply the
build-infra way of achieving the same thing as in the old build
system.
$ hg annotate make/sun/font/Makefile
...
0: #
0: # Created without -z defs on linux
0: #
0: ifeq ($(PLATFORM), linux)
0: LDFLAGS_DEFS_OPTION =
0: endif
...
/Erik
Post by Phil Race
-phil.
Post by Severin Gehwolf
There is this snippet in the libfontmanager block in
LDFLAGS := $(subst
-Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))
$(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
It's my understanding that this is supposed to filter "-Wl,-z,defs"
from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a
legit
reason when unresolved symbols at link time are OK? Besides, why
does
it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8
it's the
other way round. Xlinker flags are filtered, but -Wl,-z,defs is not.
Thoughts?
Thanks,
Severin
Phil Race
2018-01-29 20:09:35 UTC
Permalink
It looks OK but have you tried running it through the new build system
discussed here ?
http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000566.html

-phil.
Post by Severin Gehwolf
Hi Phil,
Are you OK with the latest webrev as well?
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/
Thanks,
Severin
Post by Erik Joelsson
This looks good to me. Good catch on the dependency declaration further
down. I don't see any reason this would need a sponsor, jdk/jdk should
be open.
/Erik
Post by Severin Gehwolf
Hi,
Updated webrev which removes the linker flags filtering. Linking with
$ find build/linux-x86_64-normal-server-release/images/jdk -name libfontmanager.so
build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so
$ ldd build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so
ldd: warning: you do not have execution permission for `build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so'
linux-vdso.so.1 (0x00007ffe13cc5000)
libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007fb58e204000)
libawt.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt.so (0x00007fb58df34000)
libjava.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libjava.so (0x00007fb58dd07000)
libjvm.so => not found
libawt_headless.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt_headless.so (0x00007fb58dafe000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fb58d778000)
libm.so.6 => /lib64/libm.so.6 (0x00007fb58d423000)
libc.so.6 => /lib64/libc.so.6 (0x00007fb58d040000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb58ce29000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fb58cc18000)
libpng16.so.16 => /lib64/libpng16.so.16 (0x00007fb58c9e5000)
libz.so.1 => /lib64/libz.so.1 (0x00007fb58c7ce000)
libjvm.so => not found
libdl.so.2 => /lib64/libdl.so.2 (0x00007fb58c5ca000)
libjvm.so => not found
libverify.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libverify.so (0x00007fb58c3bb000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb58e74f000)
libjvm.so => not found
libjvm.so => not found
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/
How does this look?
Do I need an Oracle sponsor for this or can I push this to jdk/jdk
myself.
Thanks,
Severin
Post by Phil Race
Post by Erik Joelsson
I could not remove -lawt however.
Ah yes, Erik sent me the errors and yes there are some 2D functions that are
defined in libawt that fontmanager needs for text rendering support, so
we can't remove that.
libawt on these platforms with separate headless and xawt libraries
could have
more aptly be called lib2d .. since most of the true AWT functionality
is in the xawt library.
-phil.
Post by Erik Joelsson
diff -r 50cd89fe209f make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk
+++ b/make/lib/Awt2dLibraries.gmk
@@ -683,15 +683,15 @@
hidevf w_novirtualdescr arrowrtn2, \
DISABLED_WARNINGS_microsoft := 4267 4244 4018 4090 4996 4146 4334
4819 4101, \
MAPFILE := $(BUILD_LIBFONTMANAGER_MAPFILE), \
- LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))
$(LDFLAGS_CXX_JDK) \
+ LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \
LDFLAGS_macosx := -undefined dynamic_lookup, \
LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \
LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX), \
- LIBS_linux := -lc, \
+ LIBS_linux := -lawt_headless -lc, \
LIBS_solaris := -lawt_headless -lc, \
LIBS_aix := -lawt_headless,\
I could not remove -lawt however.
/Erik
Post by Erik Joelsson
Post by Severin Gehwolf
Post by Erik Joelsson
Post by Phil Race
When this was fixed for Solaris
https://bugs.openjdk.java.net/browse/JDK-8071710
the observed problem was not building (although it could have been)
but at runtime.
I think you can verify what you've done with "ldd" ..
This patch adds awt_headless.so, but does not remove awt.so.
Perhaps the line
LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX)
After your fix I expect "ldd" should not need to show awt .. just
awt_headless
ie linux should not have this -lawt dependency any more and the -lawt
dependency should be specific to windows + mac ..
Thanks for the review, Phil. I'll post an updated webrev shortly.
Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on
platforms that need it? solaris, linux, aix should already be fine
without filtering.
I would say try removing the filtering. The affected flags are
currently only set on linux and solaris. I will do a test build on
the latter and see if the filtering is actually needed.
/Erik
Post by Severin Gehwolf
Thanks,
Severin
Post by Erik Joelsson
So we already use -lawt_headless on solaris and aix, then I really can't
see a reason not to do the same for linux.
Post by Phil Race
Post by Severin Gehwolf
Hi,
Could I please get a review for this rather small patch which
originally occurred for us on JDK 8 (Fedora) which recently switched to
building with "-Wl,-z,defs" linker flags. The result was a build
failure, due to unresolved symbols. Indeed libfontmanager.so should
have -lawt_headless in the list of dependent libs as symbols such as
AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. Some
more details are on the bug.
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8196218
Testing: Build fails with configure option
--with-extra-ldflags="-Xlinker -z -Xlinker defs"
prior the fix. Succeeds after.
I don't know about this, build folks probably know.
This is from way ahead of my time. The filtering is simply the
build-infra way of achieving the same thing as in the old build system.
$ hg annotate make/sun/font/Makefile
...
0: #
0: # Created without -z defs on linux
0: #
0: ifeq ($(PLATFORM), linux)
0: LDFLAGS_DEFS_OPTION =
0: endif
...
/Erik
Post by Phil Race
-phil.
Post by Severin Gehwolf
There is this snippet in the libfontmanager block in
LDFLAGS := $(subst
-Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))
$(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
It's my understanding that this is supposed to filter "-Wl,-z,defs"
from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a legit
reason when unresolved symbols at link time are OK? Besides, why does
it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 it's the
other way round. Xlinker flags are filtered, but -Wl,-z,defs is not.
Thoughts?
Thanks,
Severin
Severin Gehwolf
2018-01-30 08:42:28 UTC
Permalink
Post by Phil Race
It looks OK but have you tried running it through the new build system
discussed here ?
http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000566.html
Thanks. I've submitted it yesterday, yes. No response - via email - so
far, though.

Cheers,
Severin
Post by Phil Race
-phil.
Post by Severin Gehwolf
Hi Phil,
Are you OK with the latest webrev as well?
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/
Thanks,
Severin
Post by Erik Joelsson
This looks good to me. Good catch on the dependency declaration further
down. I don't see any reason this would need a sponsor, jdk/jdk should
be open.
/Erik
Post by Severin Gehwolf
Hi,
Updated webrev which removes the linker flags filtering. Linking with
$ find build/linux-x86_64-normal-server-release/images/jdk -name libfontmanager.so
build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so
$ ldd build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so
ldd: warning: you do not have execution permission for `build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so'
linux-vdso.so.1 (0x00007ffe13cc5000)
libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007fb58e204000)
libawt.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt.so (0x00007fb58df34000)
libjava.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libjava.so (0x00007fb58dd07000)
libjvm.so => not found
libawt_headless.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt_headless.so (0x00007fb58dafe000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fb58d778000)
libm.so.6 => /lib64/libm.so.6 (0x00007fb58d423000)
libc.so.6 => /lib64/libc.so.6 (0x00007fb58d040000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb58ce29000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fb58cc18000)
libpng16.so.16 => /lib64/libpng16.so.16 (0x00007fb58c9e5000)
libz.so.1 => /lib64/libz.so.1 (0x00007fb58c7ce000)
libjvm.so => not found
libdl.so.2 => /lib64/libdl.so.2 (0x00007fb58c5ca000)
libjvm.so => not found
libverify.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libverify.so (0x00007fb58c3bb000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb58e74f000)
libjvm.so => not found
libjvm.so => not found
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/
How does this look?
Do I need an Oracle sponsor for this or can I push this to jdk/jdk
myself.
Thanks,
Severin
Post by Phil Race
Post by Erik Joelsson
I could not remove -lawt however.
Ah yes, Erik sent me the errors and yes there are some 2D functions that are
defined in libawt that fontmanager needs for text rendering support, so
we can't remove that.
libawt on these platforms with separate headless and xawt libraries
could have
more aptly be called lib2d .. since most of the true AWT functionality
is in the xawt library.
-phil.
Post by Erik Joelsson
diff -r 50cd89fe209f make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk
+++ b/make/lib/Awt2dLibraries.gmk
@@ -683,15 +683,15 @@
hidevf w_novirtualdescr arrowrtn2, \
DISABLED_WARNINGS_microsoft := 4267 4244 4018 4090 4996 4146 4334
4819 4101, \
MAPFILE := $(BUILD_LIBFONTMANAGER_MAPFILE), \
- LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))
$(LDFLAGS_CXX_JDK) \
+ LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \
LDFLAGS_macosx := -undefined dynamic_lookup, \
LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \
LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX), \
- LIBS_linux := -lc, \
+ LIBS_linux := -lawt_headless -lc, \
LIBS_solaris := -lawt_headless -lc, \
LIBS_aix := -lawt_headless,\
I could not remove -lawt however.
/Erik
Post by Erik Joelsson
Post by Severin Gehwolf
Post by Erik Joelsson
Post by Phil Race
When this was fixed for Solaris
https://bugs.openjdk.java.net/browse/JDK-8071710
the observed problem was not building (although it could have been)
but at runtime.
I think you can verify what you've done with "ldd" ..
This patch adds awt_headless.so, but does not remove awt.so.
Perhaps the line
LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX)
After your fix I expect "ldd" should not need to show awt .. just
awt_headless
ie linux should not have this -lawt dependency any more and the -lawt
dependency should be specific to windows + mac ..
Thanks for the review, Phil. I'll post an updated webrev shortly.
Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on
platforms that need it? solaris, linux, aix should already be fine
without filtering.
I would say try removing the filtering. The affected flags are
currently only set on linux and solaris. I will do a test build on
the latter and see if the filtering is actually needed.
/Erik
Post by Severin Gehwolf
Thanks,
Severin
Post by Erik Joelsson
So we already use -lawt_headless on solaris and aix, then I really
can't
see a reason not to do the same for linux.
Post by Phil Race
Post by Severin Gehwolf
Hi,
Could I please get a review for this rather small patch which
originally occurred for us on JDK 8 (Fedora) which recently
switched to
building with "-Wl,-z,defs" linker flags. The result was a build
failure, due to unresolved symbols. Indeed libfontmanager.so should
have -lawt_headless in the list of dependent libs as symbols such as
AWTLoadFont come from libawt_headless.so, not libawt.so on Linux.
Some
more details are on the bug.
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8196218
Testing: Build fails with configure option
--with-extra-ldflags="-Xlinker -z -Xlinker defs"
prior the fix. Succeeds after.
I don't know about this, build folks probably know.
This is from way ahead of my time. The filtering is simply the
build-infra way of achieving the same thing as in the old build
system.
$ hg annotate make/sun/font/Makefile
...
0: #
0: # Created without -z defs on linux
0: #
0: ifeq ($(PLATFORM), linux)
0: LDFLAGS_DEFS_OPTION =
0: endif
...
/Erik
Post by Phil Race
-phil.
Post by Severin Gehwolf
There is this snippet in the libfontmanager block in
LDFLAGS := $(subst
-Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))
$(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
It's my understanding that this is supposed to filter "-Wl,-z,defs"
from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a
legit
reason when unresolved symbols at link time are OK? Besides, why
does
it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8
it's the
other way round. Xlinker flags are filtered, but -Wl,-z,defs is not.
Thoughts?
Thanks,
Severin
Erik Joelsson
2018-01-30 16:36:38 UTC
Permalink
I found your job and it's all successful. Something is up with the
service though. I'm pinging the relevant people here.

/Erik
Post by Severin Gehwolf
Post by Phil Race
It looks OK but have you tried running it through the new build system
discussed here ?
http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000566.html
Thanks. I've submitted it yesterday, yes. No response - via email - so
far, though.
Cheers,
Severin
Post by Phil Race
-phil.
Post by Severin Gehwolf
Hi Phil,
Are you OK with the latest webrev as well?
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/
Thanks,
Severin
Post by Erik Joelsson
This looks good to me. Good catch on the dependency declaration further
down. I don't see any reason this would need a sponsor, jdk/jdk should
be open.
/Erik
Post by Severin Gehwolf
Hi,
Updated webrev which removes the linker flags filtering. Linking with
$ find build/linux-x86_64-normal-server-release/images/jdk -name libfontmanager.so
build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so
$ ldd build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so
ldd: warning: you do not have execution permission for `build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so'
linux-vdso.so.1 (0x00007ffe13cc5000)
libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007fb58e204000)
libawt.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt.so (0x00007fb58df34000)
libjava.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libjava.so (0x00007fb58dd07000)
libjvm.so => not found
libawt_headless.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt_headless.so (0x00007fb58dafe000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fb58d778000)
libm.so.6 => /lib64/libm.so.6 (0x00007fb58d423000)
libc.so.6 => /lib64/libc.so.6 (0x00007fb58d040000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb58ce29000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fb58cc18000)
libpng16.so.16 => /lib64/libpng16.so.16 (0x00007fb58c9e5000)
libz.so.1 => /lib64/libz.so.1 (0x00007fb58c7ce000)
libjvm.so => not found
libdl.so.2 => /lib64/libdl.so.2 (0x00007fb58c5ca000)
libjvm.so => not found
libverify.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libverify.so (0x00007fb58c3bb000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb58e74f000)
libjvm.so => not found
libjvm.so => not found
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/
How does this look?
Do I need an Oracle sponsor for this or can I push this to jdk/jdk
myself.
Thanks,
Severin
Post by Phil Race
Post by Erik Joelsson
I could not remove -lawt however.
Ah yes, Erik sent me the errors and yes there are some 2D functions that are
defined in libawt that fontmanager needs for text rendering support, so
we can't remove that.
libawt on these platforms with separate headless and xawt libraries
could have
more aptly be called lib2d .. since most of the true AWT functionality
is in the xawt library.
-phil.
Post by Erik Joelsson
diff -r 50cd89fe209f make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk
+++ b/make/lib/Awt2dLibraries.gmk
@@ -683,15 +683,15 @@
hidevf w_novirtualdescr arrowrtn2, \
DISABLED_WARNINGS_microsoft := 4267 4244 4018 4090 4996 4146 4334
4819 4101, \
MAPFILE := $(BUILD_LIBFONTMANAGER_MAPFILE), \
- LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))
$(LDFLAGS_CXX_JDK) \
+ LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \
LDFLAGS_macosx := -undefined dynamic_lookup, \
LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \
LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX), \
- LIBS_linux := -lc, \
+ LIBS_linux := -lawt_headless -lc, \
LIBS_solaris := -lawt_headless -lc, \
LIBS_aix := -lawt_headless,\
I could not remove -lawt however.
/Erik
Post by Erik Joelsson
Post by Severin Gehwolf
Post by Erik Joelsson
Post by Phil Race
When this was fixed for Solaris
https://bugs.openjdk.java.net/browse/JDK-8071710
the observed problem was not building (although it could have been)
but at runtime.
I think you can verify what you've done with "ldd" ..
This patch adds awt_headless.so, but does not remove awt.so.
Perhaps the line
LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX)
After your fix I expect "ldd" should not need to show awt .. just
awt_headless
ie linux should not have this -lawt dependency any more and the -lawt
dependency should be specific to windows + mac ..
Thanks for the review, Phil. I'll post an updated webrev shortly.
Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on
platforms that need it? solaris, linux, aix should already be fine
without filtering.
I would say try removing the filtering. The affected flags are
currently only set on linux and solaris. I will do a test build on
the latter and see if the filtering is actually needed.
/Erik
Post by Severin Gehwolf
Thanks,
Severin
Post by Erik Joelsson
So we already use -lawt_headless on solaris and aix, then I really can't
see a reason not to do the same for linux.
Post by Phil Race
Post by Severin Gehwolf
Hi,
Could I please get a review for this rather small patch which
originally occurred for us on JDK 8 (Fedora) which recently
switched to
building with "-Wl,-z,defs" linker flags. The result was a build
failure, due to unresolved symbols. Indeed libfontmanager.so should
have -lawt_headless in the list of dependent libs as symbols such as
AWTLoadFont come from libawt_headless.so, not libawt.so on Linux.
Some
more details are on the bug.
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8196218
Testing: Build fails with configure option
--with-extra-ldflags="-Xlinker -z -Xlinker defs"
prior the fix. Succeeds after.
I don't know about this, build folks probably know.
This is from way ahead of my time. The filtering is simply the
build-infra way of achieving the same thing as in the old build system.
$ hg annotate make/sun/font/Makefile
...
0: #
0: # Created without -z defs on linux
0: #
0: ifeq ($(PLATFORM), linux)
0: LDFLAGS_DEFS_OPTION =
0: endif
...
/Erik
Post by Phil Race
-phil.
Post by Severin Gehwolf
There is this snippet in the libfontmanager block in
LDFLAGS := $(subst
-Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))
$(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
It's my understanding that this is supposed to filter "-Wl,-z,defs"
from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a
legit
reason when unresolved symbols at link time are OK? Besides, why does
it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8
it's the
other way round. Xlinker flags are filtered, but -Wl,-z,defs is not.
Thoughts?
Thanks,
Severin
Severin Gehwolf
2018-01-30 16:49:27 UTC
Permalink
Post by Erik Joelsson
I found your job and it's all successful. Something is up with the
service though. I'm pinging the relevant people here.
Yes, indeed:
http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000622.html

Thanks, Erik!

Cheers,
Severin
Severin Gehwolf
2018-01-30 17:05:19 UTC
Permalink
Post by Erik Joelsson
I found your job and it's all successful. Something is up with the
service though. I'm pinging the relevant people here.
Phil, Erik: Where should I push this to? jdk or client?

http://hg.openjdk.java.net/jdk/client/

or

http://hg.openjdk.java.net/jdk/jdk/

Thanks,
Severin
Post by Erik Joelsson
/Erik
Post by Severin Gehwolf
Post by Phil Race
It looks OK but have you tried running it through the new build system
discussed here ?
http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/00056
6.html
Thanks. I've submitted it yesterday, yes. No response - via email - so
far, though.
Cheers,
Severin
Post by Phil Race
-phil.
Post by Severin Gehwolf
Hi Phil,
Are you OK with the latest webrev as well?
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev
.02/
Thanks,
Severin
Post by Erik Joelsson
This looks good to me. Good catch on the dependency
declaration further
down. I don't see any reason this would need a sponsor, jdk/jdk should
be open.
/Erik
Post by Severin Gehwolf
Hi,
Updated webrev which removes the linker flags filtering. Linking with
$ find build/linux-x86_64-normal-server-release/images/jdk
-name libfontmanager.so
build/linux-x86_64-normal-server-
release/images/jdk/lib/libfontmanager.so
$ ldd build/linux-x86_64-normal-server-
release/images/jdk/lib/libfontmanager.so
ldd: warning: you do not have execution permission for
`build/linux-x86_64-normal-server-
release/images/jdk/lib/libfontmanager.so'
linux-vdso.so.1 (0x00007ffe13cc5000)
libfreetype.so.6 => /lib64/libfreetype.so.6
(0x00007fb58e204000)
libawt.so => /disk/openjdk/upstream-sources/openjdk-
hs/build/linux-x86_64-normal-server-
release/images/jdk/lib/libawt.so (0x00007fb58df34000)
libjava.so => /disk/openjdk/upstream-sources/openjdk-
hs/build/linux-x86_64-normal-server-
release/images/jdk/lib/libjava.so (0x00007fb58dd07000)
libjvm.so => not found
libawt_headless.so => /disk/openjdk/upstream-
sources/openjdk-hs/build/linux-x86_64-normal-server-
release/images/jdk/lib/libawt_headless.so
(0x00007fb58dafe000)
libstdc++.so.6 => /lib64/libstdc++.so.6
(0x00007fb58d778000)
libm.so.6 => /lib64/libm.so.6 (0x00007fb58d423000)
libc.so.6 => /lib64/libc.so.6 (0x00007fb58d040000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1
(0x00007fb58ce29000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fb58cc18000)
libpng16.so.16 => /lib64/libpng16.so.16
(0x00007fb58c9e5000)
libz.so.1 => /lib64/libz.so.1 (0x00007fb58c7ce000)
libjvm.so => not found
libdl.so.2 => /lib64/libdl.so.2 (0x00007fb58c5ca000)
libjvm.so => not found
libverify.so => /disk/openjdk/upstream-sources/openjdk-
hs/build/linux-x86_64-normal-server-
release/images/jdk/lib/libverify.so (0x00007fb58c3bb000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb58e74f000)
libjvm.so => not found
libjvm.so => not found
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/we
brev.02/
How does this look?
Do I need an Oracle sponsor for this or can I push this to jdk/jdk
myself.
Thanks,
Severin
Post by Phil Race
Post by Erik Joelsson
I could not remove -lawt however.
Ah yes, Erik sent me the errors and yes there are some 2D
functions that are
defined in libawt that fontmanager needs for text
rendering support, so
we can't remove that.
libawt on these platforms with separate headless and xawt libraries
could have
more aptly be called lib2d .. since most of the true AWT
functionality
is in the xawt library.
-phil.
Post by Erik Joelsson
diff -r 50cd89fe209f make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk
+++ b/make/lib/Awt2dLibraries.gmk
@@ -683,15 +683,15 @@
hidevf w_novirtualdescr arrowrtn2, \
DISABLED_WARNINGS_microsoft := 4267 4244 4018
4090 4996 4146 4334
4819 4101, \
MAPFILE := $(BUILD_LIBFONTMANAGER_MAPFILE), \
- LDFLAGS := $(subst -Wl$(COMMA)-
z$(COMMA)defs,,$(LDFLAGS_JDKLIB))
$(LDFLAGS_CXX_JDK) \
+ LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \
LDFLAGS_macosx := -undefined dynamic_lookup, \
LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \
LIBS_unix := -lawt -ljava -ljvm $(LIBM)
$(LIBCXX), \
- LIBS_linux := -lc, \
+ LIBS_linux := -lawt_headless -lc, \
LIBS_solaris := -lawt_headless -lc, \
LIBS_aix := -lawt_headless,\
I could not remove -lawt however.
/Erik
Post by Erik Joelsson
Post by Severin Gehwolf
Post by Erik Joelsson
Post by Phil Race
When this was fixed for Solaris
https://bugs.openjdk.java.net/browse/JDK-807171
0
the observed problem was not building (although
it could have been)
but at runtime.
I think you can verify what you've done with
"ldd" ..
This patch adds awt_headless.so, but does not
remove awt.so.
Perhaps the line
LIBS_unix := -lawt -ljava -ljvm $(LIBM)
$(LIBCXX)
After your fix I expect "ldd" should not need
to show awt .. just
awt_headless
ie linux should not have this -lawt dependency
any more and the -lawt
dependency should be specific to windows + mac
..
Thanks for the review, Phil. I'll post an updated
webrev shortly.
Any thoughts on the LDFLAGS filtering? Shouldn't
this only be done on
platforms that need it? solaris, linux, aix should
already be fine
without filtering.
I would say try removing the filtering. The affected
flags are
currently only set on linux and solaris. I will do a
test build on
the latter and see if the filtering is actually needed.
/Erik
Post by Severin Gehwolf
Thanks,
Severin
Post by Erik Joelsson
So we already use -lawt_headless on solaris and
aix, then I really
can't
see a reason not to do the same for linux.
Post by Phil Race
Post by Severin Gehwolf
Hi,
Could I please get a review for this rather
small patch which
originally occurred for us on JDK 8 (Fedora)
which recently
switched to
building with "-Wl,-z,defs" linker flags. The
result was a build
failure, due to unresolved symbols. Indeed
libfontmanager.so should
have -lawt_headless in the list of dependent
libs as symbols such as
AWTLoadFont come from libawt_headless.so, not
libawt.so on Linux.
Some
more details are on the bug.
http://cr.openjdk.java.net/~sgehwolf/webrevs/
JDK-8196218/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK
-8196218
Testing: Build fails with configure option
--with-extra-ldflags="-Xlinker
-z -Xlinker defs"
prior the fix. Succeeds after.
I don't know about this, build folks probably
know.
This is from way ahead of my time. The filtering
is simply the
build-infra way of achieving the same thing as in
the old build
system.
$ hg annotate make/sun/font/Makefile
...
0: #
0: # Created without -z defs on linux
0: #
0: ifeq ($(PLATFORM), linux)
0: LDFLAGS_DEFS_OPTION =
0: endif
...
/Erik
Post by Phil Race
-phil.
Post by Severin Gehwolf
There is this snippet in the libfontmanager
block in
LDFLAGS := $(subst
-Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))
$(LDFLAGS_CXX_JDK) \
$(call
SET_SHARED_LIBRARY_ORIGIN), \
It's my understanding that this is supposed
to filter "-Wl,-z,defs"
from LDFLAGS_JDKLIB. Does anybody know why it
does so? Is there a
legit
reason when unresolved symbols at link time
are OK? Besides, why
does
it not also filter "-Xlinker -z -Xlinker
defs"? FWIW, in JDK 8
it's the
other way round. Xlinker flags are filtered,
but -Wl,-z,defs is not.
Thoughts?
Thanks,
Severin
Phil Race
2018-01-30 17:16:33 UTC
Permalink
Post by Severin Gehwolf
Post by Erik Joelsson
I found your job and it's all successful. Something is up with the
service though. I'm pinging the relevant people here.
Phil, Erik: Where should I push this to? jdk or client?
A good question. Since it has passed builds on all platforms, then we
know that is fine,
but if you push to jdk/jdk there may not be any actual testing of the
effects of the change before
inclusion in a promotion.

So you can push to jdk/jdk but it is a calculated risk .. if it were me
I'd push to jdk/client.

-phil.
Post by Severin Gehwolf
http://hg.openjdk.java.net/jdk/client/
or
http://hg.openjdk.java.net/jdk/jdk/
Thanks,
Severin
Phil Race
2018-01-31 16:49:43 UTC
Permalink
Severin,

Did you run any UI apps on a full (make all) build with the final
version of the patch applied ?
It appears to have completely broken all UI apps on Linux and about 800
UI tests failed last night.
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException:
native ops missing
at java.desktop/sun.java2d.xr.XRSurfaceData.freeXSDOPicture(Native
Method)

An exploded build is fine but the images build (what we ship) is broken.

I think I'll need to back this out.

A good thing it was pushed to client ..

-phil.
Post by Phil Race
Post by Severin Gehwolf
Post by Erik Joelsson
I found your job and it's all successful. Something is up with the
service though. I'm pinging the relevant people here.
Phil, Erik: Where should I push this to? jdk or client?
A good question. Since it has passed builds on all platforms, then we
know that is fine,
but if you push to jdk/jdk there may not be any actual testing of the
effects of the change before
inclusion in a promotion.
So you can push to jdk/jdk but it is a calculated risk .. if it were
me I'd push to jdk/client.
-phil.
Post by Severin Gehwolf
http://hg.openjdk.java.net/jdk/client/
or
http://hg.openjdk.java.net/jdk/jdk/
Thanks,
Severin
Phil Race
2018-01-31 16:53:49 UTC
Permalink
Reverting the change it out seems to cure the problem.
I've filed https://bugs.openjdk.java.net/browse/JDK-8196509

-phil.
Post by Erik Joelsson
Severin,
Did you run any UI apps on a full (make all) build with the final
version of the patch applied ?
It appears to have completely broken all UI apps on Linux and about
800 UI tests failed last night.
native ops missing
at java.desktop/sun.java2d.xr.XRSurfaceData.freeXSDOPicture(Native
Method)
An exploded build is fine but the images build (what we ship) is broken.
I think I'll need to back this out.
A good thing it was pushed to client ..
-phil.
Post by Phil Race
Post by Severin Gehwolf
Post by Erik Joelsson
I found your job and it's all successful. Something is up with the
service though. I'm pinging the relevant people here.
Phil, Erik: Where should I push this to? jdk or client?
A good question. Since it has passed builds on all platforms, then we
know that is fine,
but if you push to jdk/jdk there may not be any actual testing of the
effects of the change before
inclusion in a promotion.
So you can push to jdk/jdk but it is a calculated risk .. if it were
me I'd push to jdk/client.
-phil.
Post by Severin Gehwolf
http://hg.openjdk.java.net/jdk/client/
or
http://hg.openjdk.java.net/jdk/jdk/
Thanks,
Severin
Severin Gehwolf
2018-01-31 19:59:26 UTC
Permalink
Hi Phil,
Post by Erik Joelsson
Severin,
Did you run any UI apps on a full (make all) build with the final
version of the patch applied ?
It appears to have completely broken all UI apps on Linux and about 800
UI tests failed last night.
Exception in thread "AWT-EventQueue-0"
native ops missing
at
java.desktop/sun.java2d.xr.XRSurfaceData.freeXSDOPicture(Native
Method)
I cannot reproduce this. SwingSet2 works fine on my Fedora 27 desktop.
Post by Erik Joelsson
An exploded build is fine but the images build (what we ship) is broken.
Exploded build works fine for me too. Which linux systems are those?
Post by Erik Joelsson
I think I'll need to back this out.
OK.
Post by Erik Joelsson
A good thing it was pushed to client ..
Yes.

Thanks,
Severin
Post by Erik Joelsson
-phil.
Post by Phil Race
Post by Severin Gehwolf
Post by Erik Joelsson
I found your job and it's all successful. Something is up with the
service though. I'm pinging the relevant people here.
Phil, Erik: Where should I push this to? jdk or client?
A good question. Since it has passed builds on all platforms, then we
know that is fine,
but if you push to jdk/jdk there may not be any actual testing of the
effects of the change before
inclusion in a promotion.
So you can push to jdk/jdk but it is a calculated risk .. if it were
me I'd push to jdk/client.
-phil.
Post by Severin Gehwolf
http://hg.openjdk.java.net/jdk/client/
or
http://hg.openjdk.java.net/jdk/jdk/
Thanks,
Severin
Phil Race
2018-01-26 17:18:37 UTC
Permalink
Post by Severin Gehwolf
Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on
platforms that need it? solaris, linux, aix should already be fine
without filtering.
Only to say I really don't understand it :-)
But I think it is historical baggage.


Erik said :-
Post by Severin Gehwolf
I would assume that at some point there was a reason for not adding
-lawt_headless to libfontmanager

There was a time (1.4) when ONLY Solaris had a separate headless library.
I alluded to this in https://bugs.openjdk.java.net/browse/JDK-8071710
Headless for Linux was added in 1.5.

So we may be dealing with some really old technical debt.

-phil.
Severin Gehwolf
2018-01-26 17:28:30 UTC
Permalink
Post by Phil Race
Post by Severin Gehwolf
Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on
platforms that need it? solaris, linux, aix should already be fine
without filtering.
Only to say I really don't understand it :-)
But I think it is historical baggage.
Erik said :-
Post by Severin Gehwolf
I would assume that at some point there was a reason for not adding
-lawt_headless to libfontmanager
There was a time (1.4) when ONLY Solaris had a separate headless library.
I alluded to this in https://bugs.openjdk.java.net/browse/JDK-8071710
Headless for Linux was added in 1.5.
So we may be dealing with some really old technical debt.
OK. Thanks, Erik, Phil!

Cheers,
Severin
Phil Race
2018-01-26 17:09:03 UTC
Permalink
And the SCCS history which pre-dates mercurial says it was added by
Kelly O'Hair
who was the JDK build lead at the time .. so not added by 2D.

D 1.86.1.1 07/03/21 18:00:55 ohair 187 185 00007/00000/00163
6537329: Move JdbcOdbc (JDBC-ODBC Bridge) to closed

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

There's no (or insufficient for me) clue as to why that change touched
2D/AWTmakefiles.
the Makefile will be fixed to use the same Linux fake libraries trick
on all Unix platforms,

-phil.
Post by Phil Race
Post by Severin Gehwolf
Testing: Build fails with configure option
--with-extra-ldflags="-Xlinker -z -Xlinker defs"
prior the fix. Succeeds after.
I don't know about this, build folks probably know.
This is from way ahead of my time. The filtering is simply the
build-infra way of achieving the same thing as in the old build
$ hg annotate make/sun/font/Makefile
...
0: #
0: # Created without -z defs on linux
0: #
0: ifeq ($(PLATFORM), linux)
0: LDFLAGS_DEFS_OPTION =
0: endif
Erik Joelsson
2018-01-26 17:16:05 UTC
Permalink
Interesting, so this was probably just Kelly trying to get things to build.

/Erik
Post by Phil Race
And the SCCS history which pre-dates mercurial says it was added by
Kelly O'Hair
who was the JDK build lead at the time .. so not added by 2D.
D 1.86.1.1 07/03/21 18:00:55 ohair 187 185      00007/00000/00163
6537329: Move JdbcOdbc (JDBC-ODBC Bridge) to closed
https://bugs.openjdk.java.net/browse/JDK-6537329
There's no (or insufficient for me) clue as to why that change touched
2D/AWTmakefiles.
the Makefile will be fixed to use the same Linux fake libraries
trick on all Unix platforms,
-phil.
Post by Phil Race
Post by Severin Gehwolf
Testing: Build fails with configure option
          --with-extra-ldflags="-Xlinker -z -Xlinker defs"
          prior the fix. Succeeds after.
I don't know about this, build folks probably know.
This is from way ahead of my time. The filtering is simply the
build-infra way of achieving the same thing as in the old build
$ hg annotate make/sun/font/Makefile
...
   0: #
   0: # Created without -z defs on linux
   0: #
   0: ifeq ($(PLATFORM), linux)
   0:   LDFLAGS_DEFS_OPTION =
   0: endif
Loading...