[OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library

Phil Race philip.race at oracle.com
Mon Jan 29 20:09:35 UTC 2018 

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.

On 01/29/2018 10:53 AM, Severin Gehwolf wrote:
> Hi Phil,
>
> Are you OK with the latest webrev as well?
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/
>
> Thanks,
> Severin
>
> On Mon, 2018-01-29 at 08:29 -0800, Erik Joelsson wrote:
>> 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
>>
>>
>> On 2018-01-29 01:39, Severin Gehwolf wrote:
>>> 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
>>>
>>> On Fri, 2018-01-26 at 09:44 -0800, Phil Race wrote:
>>>>    > 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.
>>>>
>>>> On 01/26/2018 09:23 AM, Erik Joelsson wrote:
>>>>> 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
>>>>>
>>>>> On 2018-01-26 09:15, Erik Joelsson wrote:
>>>>>> On 2018-01-26 09:02, Severin Gehwolf wrote:
>>>>>>> On Fri, 2018-01-26 at 08:54 -0800, Erik Joelsson wrote:
>>>>>>>> On 2018-01-26 08:44, Phil Race wrote:
>>>>>>>>> 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
>>>>>>> Thanks,
>>>>>>> Severin
>>>>>>>
>>>>>>>> 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.
>>>>>>>>> On 01/26/2018 08:10 AM, Severin Gehwolf wrote:
>>>>>>>>>> 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:
>>>>>>>>> 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
>>>>>>>>
>>>>>>>>> -phil.
>>>>>>>>>> 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
>>

More information about the build-dev mailing list