RFR(XXS): 8062312: OpenJDK build fails when bundling freetype libraries

[Erik Joelsson]

Looks good, thanks!

I usually just post the patch inline if the change is this small.

/Erik

On 2014-10-29 10:58, Volker Simonis wrote:
> Hi Erik,
>
> thanks for the review.
>
> On Wed, Oct 29, 2014 at 10:01 AM, Erik Joelsson
> <erik.joelsson at oracle.com> wrote:
>> Hello Volker,
>>
>> The change looks good, but I would like a comment explaining why
>> install-file isn't used. Otherwise it's quite possible we will break this
>> again in future cleanups.
>>
> I forget that and I'm to lazy to create a new webrev:)
> Would you be fine with the following:
>
> +  # We can't use $(install-file) in this rule because it preserves
> symbolic links and
> +  # libfreetype.so is usually a symbolic link to something like
> libfreetype.so.6 on Unix.
>     $(FREETYPE_TARGET_LIB): $(FREETYPE_BUNDLE_LIB_PATH)/$(call
> SHARED_LIBRARY,freetype)
> -       $(install-file)
> +       $(MKDIR) -p $(@D)
> +       $(CP) $< $@
>
>
>> /Erik
>>
>>
>> On 2014-10-28 20:18, Volker Simonis wrote:
>>> Hi,
>>>
>>> could you please review the following tiny change which fixes the copy
>>> step of the freetype libraries after 8058756:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/8062312/
>>> https://bugs.openjdk.java.net/browse/JDK-8062312
>>>
>>> After the fix for "JDK-8058756: OpenJDK builds fail on Windows -
>>> cannot copy freetype.dll" the build fails on Unix if the freetype
>>> library which should be bundled is a symbolic link. This is because
>>> 8058756 replaced the copy operation by a call to $(install-file) which
>>> preserves symlinks.
>>>
>>> The fix is easy: just roll back to the initial copy operation and
>>> insert an 'mkdir -p' for the target directory (as initially proposed
>>> as fix for 8058756).
>>>
>>> Built and smoke tested on Linux, Solaris, Windows and MacOS X.
>>>
>>> Thank you and best regards,
>>> Volker
>>