RFR(M): 8043492 - ad_x86_64_misc.obj : error LNK2011: precompiled object not linked in; image may not run

Thu Jun 5 20:43:17 UTC 2014

>My concern is if user specify FORCE_MSC_VER=1400 to use VS2005 and his
build will break in some strange place, for example, in sa.make due to your
change. So should we stop the build gracefully if used VS is not supported
or let it fail late (or produce broken code which is worse) with just
warning message?

I think the warning should be enough?

>The warning message should be "1600 or later (Visual Studio 2010 or later)"
to avoid updating it again in a future.

We only know that 2010/2012/2013 works (and we're explicitly checking for
it), if someone tries to compile with say Visual Studio 2020 we should say
that it's not supported since we don't know if it actually works. We need to
update the makefiles for new versions of Visual Studio anyway so I don't see
this as a major thing.

Thanks,
Christian

-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Thursday, June 5, 2014 4:34 PM
To: Christian Tornqvist; hotspot-dev at openjdk.java.net
Subject: Re: RFR(M): 8043492 - ad_x86_64_misc.obj : error LNK2011:
precompiled object not linked in; image may not run

It is fine if specified version > 1800.

My concern is if user specify FORCE_MSC_VER=1400 to use VS2005 and his build
will break in some strange place, for example, in sa.make due to your
change. So should we stop the build gracefully if used VS is not supported
or let it fail late (or produce broken code which is worse) with just
warning message?

The warning message should be "1600 or later (Visual Studio 2010 or later)"
to avoid updating it again in a future.

Vladimir

On 6/5/14 12:53 PM, Christian Tornqvist wrote:
> Hi Vladimir,
>
> I think the option of overriding should be left in to make it easier 
> to test new/beta versions of Visual Studio. I could change the 
> messages to something
> like:
>
> "*** WARNING *** Incorrect cl.exe version detected: $(MSC_VER), only
> 1600/1700/1800 (Visual Studio 2010/2012/2013) are supported"
> "*** WARNING *** Incorrect link.exe version detected: $(LD_VER), only
> 1000/1100/1200 (Visual Studio 2010/2012/2013) are supported"
>
> Would that make sense?
>
> Thanks,
> Christian
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Thursday, June 5, 2014 2:37 PM
> To: hotspot-dev at openjdk.java.net
> Cc: Christian Törnqvist
> Subject: Re: RFR(M): 8043492 - ad_x86_64_misc.obj : error LNK2011:
> precompiled object not linked in; image may not run
>
> On 6/5/14 9:23 AM, Christian Tornqvist wrote:
>> Hi everyone,
>>
>> This is a fix for building JDK9 with Visual Studio 2013, the fix is 
>> to add _build_pch_file.obj to LD_FLAGS in vm.make when building with
> VS2012/2013.
>> Also added VS2013 to vm_version.cpp so that -Xinternalversion looks
> correct.
>>
>
> Your clean up is correct. We care only about jdk8u and jdk9 now. And 
> we use
> VS2010 (1600) for 9 and 8u.
>
> We should not allow to build with old compilers since you removed all 
> code for them. But based on sanity.make we still allow it with
FORCE_MSC_VER.
>
> Thanks,
> Vladimir
>
>>
>>
>> Cleaned up support for older versions of Visual Studio (2008 and older).
>> Mainstream support for these versions have ended:
>>
>> http://support.microsoft.com/lifecycle/search/?sort=PN
>> <http://support.microsoft.com/lifecycle/search/?sort=PN&alpha=Visual+
>> S
>> tudio> &alpha=Visual+Studio and comments in the Hotspot code suggest
>> we need VS2010 and later anyway.
>>
>> Also cleaned up one of the warnings when building the SA with a CL 
>> option that was removed in VS2005 (described by 
>> https://bugs.openjdk.java.net/browse/JDK-6989106).
>>
>>
>>
>> Changes have been tested in JPRT and locally on my Windows 8.1 x64 
>> machine using VS2010 and VS2013, built using gnu make:
>>
>>
>>
>> Java HotSpot(TM) Server VM (1.9.0-internal) for windows-x86 JRE 
>> (1.9.0), built on Jun  5 2014 08:19:39 by "Christian" with MS VC++
>> 10.0 (VS2010)
>>
>> Java HotSpot(TM) Server VM (1.9.0-internal) for windows-x86 JRE 
>> (1.9.0), built on Jun  5 2014 08:36:15 by "Christian" with MS VC++
>> 12.0 (VS2013)
>>
>> Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal) for windows-amd64 
>> JRE (1.9.0), built on Jun  5 2014 08:31:36 by "Christian" with MS 
>> VC++
>> 10.0
>> (VS2010)
>>
>> Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal) for windows-amd64 
>> JRE (1.9.0), built on Jun  5 2014 08:26:51 by "Christian" with MS 
>> VC++
>> 12.0
>> (VS2013)
>>
>>
>>
>> and Visual Studio project (using create.bat):
>>
>>
>>
>> Java HotSpot(TM) Server VM (1.9.0) for windows-x86 JRE (1.9.0), built 
>> on Jun
>> 5 2014 09:24:42 by "Christian" with MS VC++ 10.0 (VS2010)
>>
>> Java HotSpot(TM) Server VM (1.9.0) for windows-x86 JRE (1.9.0), built 
>> on Jun
>> 5 2014 09:19:32 by "Christian" with MS VC++ 12.0 (VS2013)
>>
>> Java HotSpot(TM) 64-Bit Server VM (1.9.0) for windows-amd64 JRE 
>> (1.9.0), built on Jun  5 2014 09:11:10 by "Christian" with MS VC++
>> 10.0 (VS2010)
>>
>> Java HotSpot(TM) 64-Bit Server VM (1.9.0) for windows-amd64 JRE 
>> (1.9.0), built on Jun  5 2014 09:15:57 by "Christian" with MS VC++
>> 12.0 (VS2013)
>>
>>
>>
>> Webrev can be found at:
>>
>> http://cr.openjdk.java.net/~ctornqvi/webrev/8043492/webrev.00/
>>
>>
>>
>> Bug:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8043492
>>
>>
>>
>> Thanks,
>>
>> Christian
>>
>