RFR: JDK-8199608 Clean up LDFLAGS for libfontmanager

Erik Joelsson erik.joelsson at oracle.com
Wed Mar 14 20:44:18 UTC 2018


On 2018-03-14 13:22, Magnus Ihse Bursie wrote:
> On 2018-03-14 15:59, Erik Joelsson wrote:
>> This change is unfortunately not correct for Linux and Solaris. We 
>> cannot link libfontmanager explicitly against either libawt_xawt or 
>> libawt_headless. See https://bugs.openjdk.java.net/browse/JDK-8196516 
>> for my suggestion on a better fix than we currently have. I was 
>> hoping for Severin to check it out and pick it up, but he is away for 
>> a bit so that hasn't happened.
>>
>> The reason we cannot link explicitly is that we need to decide at 
>> runtime whether to pull in the headful or headless libraries. If one 
>> or the other is already pulled in, and we explicitly load the other, 
>> the runtime linker will lookup the common symbols in one or the other 
>> in an unpredictable way. Some users get the correct behavior, some 
>> get the wrong behavior. We recently had discussions around this on 
>> this list if you want to dive deeper into it.
>>
>> Also see https://bugs.openjdk.java.net/browse/JDK-8194870 for one of 
>> the consequences of explicit linking here.
>>
>> I think the mac part is ok though, but Phil has to have a look. For 
>> Linux and Solaris, if you could remove the -lawt_headless and add 
>> "-Xlinker --unresolved-symbols=ignore-all" to LDFLAGS for linux I 
>> think we should be good.
> Oh, this seems like a fine mess. :-(
>
> I see we used to link with libawt_headless for solaris, but removed it 
> in JDK-8194870. Phil remarked in that bug: "We linked against headless 
> before then but allowed undefined symbols JDK 9 switched this to 
> libawt_headless when headless apps failed." but I'm not sure I 
> understand what this really means.
I think he means that we linked with xawt before, but switch to headless 
at some point. If you run on a machine without X11 present, then if you 
load xawt, you get a runtime linker error. That was the reason for 
switching to linking with headless instead.
>
> I agree it seems likely that the macosx changes is correct. I could 
> probably add -Wl,--unresolved-symbols=ignore-all for gcc on linux, but 
> that is unlikely to work on solstudio. :-( So I'm afraid we're still 
> stuck with the need to remove -z defs for some builds. :-(
>
On solaris we should be able to override -Wl,-z,defs with -Wl,-z,nodefs 
later on the link line I think. Perhaps that works on Linux as well. I 
didn't find nodefs on the Linux man page, but coming to think about it, 
the "no" prefix should be universal.
> Question to Phil: Would it be possible to rewrite the code to load and 
> reference the symbols dynamically, using libdl? The problem here is 
> that the functions are declared extern, instead of loaded into a 
> function pointer at runtime. That's how you typically use this kind of 
> runtime-determined dynamic loading.
>
That sounds like a better long term solution.

/Erik
> /Magnus
>>
>> /Erik
>>
>> On 2018-03-14 04:45, Magnus Ihse Bursie wrote:
>>> This is the final LDFLAGS cleanup, which required some more work to 
>>> resolve.
>>>
>>> Libfontmanager had previously explicitely disabled -z defs, with the 
>>> result that linking did not complain about missing libraries. To fix 
>>> this, I had to provide the proper libraries to link with. For linux 
>>> and solaris, this was libawt_headless. For macosx, this was 
>>> libawt_lwawt, but also three system frameworks.
>>>
>>> Note that this patch has a merge conflict with JDK-8199606. The end 
>>> result of both patches are shown in the patch (that is, with -lc 
>>> removed). I will make sure to resolve the conflicts properly when 
>>> committing this patch.
>>>
>>> I have run COMPARE_BUILDS, with expected results. That is, no 
>>> changes for Windows, and a deps change for macosx, linux and 
>>> solaris. I also got a symbol change for linux, since the symbols 
>>> from libawt_headless changed from e.g. "AWTCharAdvance" to 
>>> "AWTCharAdvance@@SUNWprivate_1.1". And of course, when you do 
>>> linking changes, you also end up getting binary/disasm changes.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199608
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8199608-clean-up-LDFLAGS-for-libfontmanager/webrev.01
>>>
>>
>




More information about the build-dev mailing list