Windows build failure in JDK8 with --disable-zip-debug-info

[Dmitry Samersoff]

Volker,

What version of *make* do you use in both cases?

-Dmitry

On 2015-03-12 17:34, Volker Simonis wrote:
> Hi,
> 
> I understand that I'm a little late to the game but I just run into
> this problem myself:)
> 
> The funny thing is that this problem doesn't occur with MinGW/MSYS but
> just with Cygwin and I can't understand why?
> 
> We have a little special setup here at SAP: we do the Windows builds
> with MinGW/MSYS and by default we always build with
> --disable-zip-debug-info. So until now we had no problems.
> 
> Now I started to migrate our build to Cygwin (but still with
> --disable-zip-debug-info) and run into the problem.
> 
> I think the origin of the dependency on the .map (and .pdb) files is
> clear - it is set right in SetupNativeCompilation if we don't want to
> zip the debug information (i.e. --disable-zip-debug-info):
> 
>         ifeq ($(ZIP_DEBUGINFO_FILES), true)
>           ...
>         else
>           ifeq ($(OPENJDK_TARGET_OS), windows)
>             $1 += $$($1_OUTPUT_DIR)/$$($1_LIBRARY).map \
>                 $$($1_OUTPUT_DIR)/$$($1_LIBRARY).pdb
> 
> But we also have the following pattern rule in SetupNativeCompilation
> which should copy the .map and .pdb from OBJECT_DIR to OUTPUT_DIR:
> 
>         ifneq ($$($1_OUTPUT_DIR),$$($1_OBJECT_DIR))
>           $$($1_OUTPUT_DIR)/% : $$($1_OBJECT_DIR)/%
>           $(CP) $$< $$@
>         endif
> 
> This rule works perfectly with MinGW/MSYS but it doesn't get triggered
> with Cygwin. And that's the reason why we get the error "*** No rule
> to make target `/cygdrive/c/jprt/T/P1/031627.daholme/s/build/windows-x86-normal-clientANDserver-release/jdk/bin/verify.map'"
> which says that it can not make the .map file in the OUTPUT_DIR. But
> notice that the .map file is there in the OBJECT_DIR directory (i.e.
> ../objs/libverify/verify.map), but make under Cygwin somehow doesn't
> recognize that there's a rule to copy it over to the OUTPUT_DIR
> directory.
> 
> I tried the workaround proposed by Magnus' but unfortunately it
> doesn't work. I think that's because the problem is not that the .map
> files are not created - the problem is that they are not copied over
> to the OUTPUT_DIR.
> 
> So here's what really helped:
> 
>           ifeq ($(OPENJDK_TARGET_OS), windows)
>             $1 += $$($1_OUTPUT_DIR)/$$($1_LIBRARY).map \
>                 $$($1_OUTPUT_DIR)/$$($1_LIBRARY).pdb
> 
>             $$($1_OUTPUT_DIR)/$$($1_LIBRARY).map :
> $$($1_OBJECT_DIR)/$$($1_LIBRARY).map
>               echo "Copying .map from OBJECT_DIR to OUTPUT_DIR"
>               $(CP) $$< $$@
>             $$($1_OUTPUT_DIR)/$$($1_LIBRARY).pdb :
> $$($1_OBJECT_DIR)/$$($1_LIBRARY).pdb
>                echo "Copying .pdb from OBJECT_DIR to OUTPUT_DIR"
>                $(CP) $$< $$@
> 
> And you need the same fix for the PROGRAM build part:
> 
>           ifeq ($(OPENJDK_TARGET_OS), windows)
>             $1 += $$($1_OUTPUT_DIR)/$$($1_PROGRAM).map \
>                 $$($1_OUTPUT_DIR)/$$($1_PROGRAM).pdb
> 
>             $$($1_OUTPUT_DIR)/$$($1_PROGRAM).map :
> $$($1_OBJECT_DIR)/$$($1_PROGRAM).map
>                echo "Copying .map from OBJECT_DIR to OUTPUT_DIR"
>                $(CP) $$< $$@
>             $$($1_OUTPUT_DIR)/$$($1_PROGRAM).pdb :
> $$($1_OBJECT_DIR)/$$($1_PROGRAM).pdb
>                echo "Copying .pdb from OBJECT_DIR to OUTPUT_DIR"
>                $(CP) $$< $$@
> 
> So for me this works now and I will change our internal build accordingly.
> 
> I don't know if there's any interest of bringing this to jdk8u. I just
> though I'll let you know:)
> 
> It would also be interesting if somebody has some explanation for why
> the pattern rule for copying the .map files works under MinGW/MSYS but
> not under Cygwin.
> 
> Regards,
> Volker
> 
> On Wed, Nov 5, 2014 at 2:00 PM, David Holmes <david.holmes at oracle.com> wrote:
>> On 5/11/2014 10:27 PM, Magnus Ihse Bursie wrote:
>>>
>>> On 2014-11-05 13:25, Magnus Ihse Bursie wrote:
>>>>
>>>> I even have a vague memory of a fix along these lines in jdk9. If
>>>> that's correct, it's probably due for backporting. I'll see if I can
>>>> locate it.
>>>
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8025936
>>>
>>> It might be some work backporting it though, the comments in the bug
>>> says it needed to be substantially rewritten due to changes in JDK9.
>>
>>
>> Thanks Magnus. Seems this is unlikely to be fixed then - which means I can't
>> test what I'm working on for the case where we don't zip the debuginfo files
>> :(
>>
>> David
>>
>>> /Magnus


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.