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

Thu Jun 5 20:48:43 UTC 2014

On 6/5/14 1:43 PM, Christian Tornqvist wrote:
>> 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?

In some sense yes. He was warned, so he can't file a bug.

>
>> 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.

Okay, I agree.

Reviewed.

Thanks,
Vladimir

>
> 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
>>>
>>
>