Error on build
javafx at use.startmail.com
javafx at use.startmail.com
Mon Oct 9 01:24:18 UTC 2017
Hi,
I possess an AMD 64 bit machine.
My JDK_HOME points to a 64 bit JDK.
MS C++ redistributables reported as installed on my machine (determined
by control panel -> uninstall a program -> reviewing resulting list of
installed sw) report both 32 and 64 installations.
MS VS was installed as I reported below.
AFAIK Cygwin is not versioned x86 or 64-bit or if it is (can't actually
recall) it cannot effect the result of the build.
Are they any other factors at play I am unaware of?
Cheers.
On Sunday, October 8, 2017 6:45 AM, David Bimamisa
<ketchxup at googlemail.com> wrote:
> Which version of JDK are you using? 64-bit or 32-bit?
> I remember getting these types of errors only if there was a mismatch
> between the JDK and c++ compiler machine type
> As noted in wiki: "the version of the JDK you have set as JDK_HOME
> will determine whether you build 32 or 64 bit binaries"
>
> Regards
> David
>
> 2017-10-07 1:09 GMT+02:00 <javafx at use.startmail.com>:
>> This is the result of using *VS 2017 CE- every option selected,
>> downloaded and installed*
>>
>> I would say there is an external symbol _fltused (float used?) and
>> a few other such errors and also the assumption that the builder is
>> on a 32 bit machine ?? (see final error).
>>
>>
>> _fltused
>> __GSHandlerCheck
>> __security_check_cookie
>> powf
>> __imp_IsProcessorFeaturePresent
>> _DllMainCRTStartup
>>
>> and
>>
>> C:/Program Files (x86)/Microsoft Visual Studio
>> 14.0/VC/LIB\MSVCRT.lib : warning LNK4272: library machine type 'X86'
>> conflicts with target machine type 'x64'
>> C:\cygwin64\home\mdbg\rt\modules\javafx.graphics\build\libs\jsl-decora\win\decora_sse.dll
>> : fatal error LNK1120: 7 unresolved externals
>> :graphics:linkDecoraNativeShadersWin FAILED
>>
>>
>> MS Studio 2017 CE doesn't ask you if you want a 32 bit or 64 bit
>> installation, only WHERE you want it installed.
>>
>> The user choice of Program Files vs Program FIles x(86 ) might
>> constitute a choice of sorts so after failing with the default x86
>> place, I uninstalled everything and tried the other only to have it
>> fail much sooner. The first fail (x86) actually got through building
>> part or most of .graphics, which gave me false hope.
>>
>> That non-question usually means the install itself knows what to do
>> or has a preference and in this context especially - VS
>> 2017,install- should not lead to x86 vs 64 bit type problems .
>>
>> Also, the instructions on the wiki , outdated I am told, also say
>> the default project is sdk. I do not think this is the case. It
>> seems mandatory to type "sdk" after gradle to hit the sdk build
>> task.
>>
>> Any help or experiences from anyone is much appreciated.
>>
>>
>>
>> Full output:
>>
>> SSEPhongLighting_POINTPeer.obj : error LNK2001: unresolved external
>> symbol _fltused
>> SSEPhongLighting_SPOTPeer.obj : error LNK2001: unresolved external
>> symbol _fltused
>> SSESepiaTonePeer.obj : error LNK2001: unresolved external symbol
>> _fltused
>> SSEUtils.obj : error LNK2001: unresolved external symbol _fltused
>> SSELinearConvolvePeer.obj : error LNK2001: unresolved external
>> symbol _fltused
>> SSELinearConvolveShadowPeer.obj : error LNK2001: unresolved external
>> symbol _fltused
>> SSEPerspectiveTransformPeer.obj : error LNK2001: unresolved external
>> symbol _fltused
>> SSEPhongLighting_DISTANTPeer.obj : error LNK2001: unresolved
>> external symbol _fltused
>> SSEBrightpassPeer.obj : error LNK2001: unresolved external symbol
>> _fltused
>> SSEColorAdjustPeer.obj : error LNK2001: unresolved external symbol
>> _fltused
>> SSEDisplacementMapPeer.obj : error LNK2001: unresolved external
>> symbol _fltused
>> SSEInvertMaskPeer.obj : error LNK2001: unresolved external symbol
>> _fltused
>> SSEBlend_SRC_INPeer.obj : error LNK2001: unresolved external symbol
>> _fltused
>> SSEBlend_SRC_OUTPeer.obj : error LNK2001: unresolved external symbol
>> _fltused
>> SSEBlend_SRC_OVERPeer.obj : error LNK2001: unresolved external
>> symbol _fltused
>> SSEBoxShadowPeer.obj : error LNK2001: unresolved external symbol
>> _fltused
>> SSEBlend_REDPeer.obj : error LNK2001: unresolved external symbol
>> _fltused
>> SSEBlend_SCREENPeer.obj : error LNK2001: unresolved external symbol
>> _fltused
>> SSEBlend_SOFT_LIGHTPeer.obj : error LNK2001: unresolved external
>> symbol _fltused
>> SSEBlend_SRC_ATOPPeer.obj : error LNK2001: unresolved external
>> symbol _fltused
>> SSEBlend_HARD_LIGHTPeer.obj : error LNK2001: unresolved external
>> symbol _fltused
>> SSEBlend_LIGHTENPeer.obj : error LNK2001: unresolved external symbol
>> _fltused
>> SSEBlend_MULTIPLYPeer.obj : error LNK2001: unresolved external
>> symbol _fltused
>> SSEBlend_OVERLAYPeer.obj : error LNK2001: unresolved external symbol
>> _fltused
>> SSEBlend_DARKENPeer.obj : error LNK2001: unresolved external symbol
>> _fltused
>> SSEBlend_DIFFERENCEPeer.obj : error LNK2001: unresolved external
>> symbol _fltused
>> SSEBlend_EXCLUSIONPeer.obj : error LNK2001: unresolved external
>> symbol _fltused
>> SSEBlend_GREENPeer.obj : error LNK2001: unresolved external symbol
>> _fltused
>> SSEBlend_ADDPeer.obj : error LNK2001: unresolved external symbol
>> _fltused
>> SSEBlend_BLUEPeer.obj : error LNK2001: unresolved external symbol
>> _fltused
>> SSEBlend_COLOR_BURNPeer.obj : error LNK2001: unresolved external
>> symbol _fltused
>> SSEBlend_COLOR_DODGEPeer.obj : error LNK2001: unresolved external
>> symbol _fltused
>>
>> SSEPerspectiveTransformPeer.obj : error LNK2001: unresolved external
>> symbol __GSHandlerCheck
>> SSEBoxShadowPeer.obj : error LNK2001: unresolved external symbol
>> __GSHandlerCheck
>> SSEDisplacementMapPeer.obj : error LNK2001: unresolved external
>> symbol __GSHandlerCheck
>> SSELinearConvolvePeer.obj : error LNK2001: unresolved external
>> symbol __GSHandlerCheck
>> SSELinearConvolveShadowPeer.obj : error LNK2001: unresolved external
>> symbol __GSHandlerCheck
>>
>> SSEPerspectiveTransformPeer.obj : error LNK2001: unresolved external
>> symbol __security_check_cookie
>> SSEBoxShadowPeer.obj : error LNK2001: unresolved external symbol
>> __security_check_cookie
>> SSEDisplacementMapPeer.obj : error LNK2001: unresolved external
>> symbol __security_check_cookie
>> SSELinearConvolvePeer.obj : error LNK2001: unresolved external
>> symbol __security_check_cookie
>> SSELinearConvolveShadowPeer.obj : error LNK2001: unresolved external
>> symbol __security_check_cookie
>> SSEPerspectiveTransformPeer.obj : error LNK2001: unresolved external
>> symbol __security_cookie
>> SSEBoxShadowPeer.obj : error LNK2001: unresolved external symbol
>> __security_cookie
>> SSEDisplacementMapPeer.obj : error LNK2001: unresolved external
>> symbol __security_cookie
>> SSELinearConvolvePeer.obj : error LNK2001: unresolved external
>> symbol __security_cookie
>> SSELinearConvolveShadowPeer.obj : error LNK2001: unresolved external
>> symbol __security_cookie
>>
>> SSEPhongLighting_DISTANTPeer.obj : error LNK2019: unresolved
>> external symbol powf referenced in function
>> Java_com_sun_scenario_effect_impl_sw_sse_SSEPhongLighting_1DISTANTPeer_filter
>> SSEPhongLighting_POINTPeer.obj : error LNK2001: unresolved external
>> symbol powf
>> SSEPhongLighting_SPOTPeer.obj : error LNK2001: unresolved external
>> symbol powf
>>
>> SSEUtils.obj : error LNK2019: unresolved external symbol
>> __imp_IsProcessorFeaturePresent referenced in function
>> Java_com_sun_scenario_effect_impl_sw_sse_SSERendererDelegate_isSupported
>>
>> LINK : error LNK2001: unresolved external symbol _DllMainCRTStartup
>>
>> C:/Program Files (x86)/Microsoft Visual Studio
>> 14.0/VC/LIB\MSVCRT.lib : warning LNK4272: library machine type 'X86'
>> conflicts with target machine type 'x64'
>> C:\cygwin64\home\mdbg\rt\modules\javafx.graphics\build\libs\jsl-decora\win\decora_sse.dll
>> : fatal error LNK1120: 7 unresolved externals
>> :graphics:linkDecoraNativeShadersWin FAILED
>>
>>
>> On Thursday, October 5, 2017 10:09 AM, David Bimamisa <ketchxup at googlemail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I'm not sure whether DirectX is needed or not. So I stick with
>>> DirectX SDK
>>> (June 2010).
>>> But I think WINSDK is still needed since I got my build running
>>> only after
>>> installing Windows 10 SDK (shipped with visual studio 2017).
>>> However, I had to run the *vs_installer.ex*e again and go to
>>> "change" in
>>> order to customize my VS2017 installation.
>>> To get Windows 10 SDK installed, I added the workload "Desktop
>>> development with C++" (see Figure in https://docs.microsoft.com/
>>> en-us/visualstudio/install/install-visual-studio) and selected the
>>> option
>>> "Toolset for visual C++" below in the right sided list (don't know
>>> if this
>>> is needed though)
>>>
>>> This is how my *build*/*windows_tools.properties *looks now:
>>> WINDOWS_VS_DEVENVDIR=C:/Program Files (x86)/Microsoft Visual
>>> Studio/2017/Community/Common7/IDE
>>> WINDOWS_VS_DEVENVCMD=C:/Program Files (x86)/Microsoft Visual
>>> Studio/2017/Community/Common7/IDE/devenv.com <http://devenv.com>
>>> WINDOWS_VS_VCINSTALLDIR=C:/Program Files (x86)/Microsoft Visual
>>> Studio/2017/Community/VC
>>> WINDOWS_VS_VSINSTALLDIR=C:/Program Files (x86)/Microsoft Visual
>>> Studio/2017/Community
>>> WINDOWS_VS_MSVCDIR=C:/Program Files (x86)/Microsoft Visual
>>> Studio/2017/Community/VC
>>> WINDOWS_VS_INCLUDE=...
>>> WINDOWS_VS_LIB=...
>>> WINDOWS_VS_LIBPATH=...
>>> WINDOWS_VS_PATH=...
>>> WINDOWS_VS_VER=150
>>> WINDOWS_SDK_DIR=C:/Program Files (x86)/Windows Kits/10
>>> WINDOWS_SDK_VERSION=10.0.14393.0
>>>
>>> Regards,
>>> David
>>>
>>> 2017-10-04 23:51 GMT+02:00 Chris Newland <cnewland at chrisnewland.com>:
>>>
>>>> Thanks David.
>>>>
>>>> Do you know if the WINSDK and DirectX requirements are still as
>>>> per the
>>>> wiki/docs or can later versions be used?
>>>>
>>>> Cheers,
>>>>
>>>> Chris
>>>> @chriswhocodes | JITWatch | DemoFX
>>>>
>>>> On Wed, October 4, 2017 13:15, David Bimamisa wrote:
>>>> > It should also work with the community version of VS2017
>>>> >
>>>> >
>>>> > Regards
>>>> > David
>>>> >
>>>> >
>>>> >
>>>> > Am 03.10.2017 5:56 nachm. schrieb <javafx at use.startmail.com>:
>>>> >
>>>> >
>>>> > VS 2017 Professional is now required to build OpenJFX.
>>>> >
>>>> >>
>>>> > Ahh I see. I am sure it needs every bit of power offered by the
>>>> > professional version of Microsoft's excellent dev environment
>>>> but
>>>> > unfortunately it cuts me out of building or testing since I
>>>> don't have
>>>> > that subscription and it's really rather pricey.
>>>> >
>>>> > Cheers!
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >>
>>>> >>
>>>> > On Tuesday, October 3, 2017 9:43 AM, Kevin Rushforth <
>>>> > kevin.rushforth at oracle.com> wrote:
>>>> >
>>>> >
>>>> >> The Wiki is out of date. VS 2017 Professional is now required
>>>> to build
>>>> >> OpenJFX. A fix was just pushed [1] to allow a different build
>>>> of VS 2017
>>>> >> than the hard-coded one.
>>>> >>
>>>> >> Also, I am still able to build with VS 2010 and VS 2013, which
>>>> should
>>>> >> work as long as you don't build media or webkit (they aren't
>>>> built by
>>>> >> default).
>>>> >>
>>>> >> -- Kevin
>>>> >>
>>>> >>
>>>> >> [1] https://bugs.openjdk.java.net/browse/JDK-8187366
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> Chris Newland wrote:
>>>> >>
>>>> >>
>>>> >>>
>>>> >>> Hi,
>>>> >>>
>>>> >>>
>>>> >>> I'm also trying to build OpenJFX on Windows 10 so I can add a
>>>> >>> Windows
>>>> >>> build to my community OpenJFX build server at
>>>> >>> https://chriswhocodes.com
>>>> >>> and am hitting the same problems as you.
>>>> >>>
>>>> >>> Setting WINSDK_DIR on the command line using 'set' or 'export'
>>>> >>> doesn't work and neither does setting via the Windows
>>>> environment
>>>> >>> manager UI.
>>>> >>>
>>>> >>>
>>>> >>> Hardcoding got me past this one:
>>>> >>>
>>>> >>>
>>>> >>> def WINDOWS_SDK_DIR="..." above the check.
>>>> >>>
>>>> >>> Next error I'm hitting is NativeCompileTask.compile()
>>>> >>>
>>>> >>>
>>>> >>> This is with Windows 10, VS10 Express, WinSDK 7.1, and DirectX
>>>> June
>>>> >>> 2010.
>>>> >>>
>>>> >>>
>>>> >>> buildSrc/win.gradle has hardcoded paths to VS2017 Professional
>>>> so I'm
>>>> >>> guessing the devs who wrote this build script have got it
>>>> working on a
>>>> >>> more modern build environment than the one described in the
>>>> docs.
>>>> >>>
>>>> >>> Will post here if I can get it to build.
>>>> >>>
>>>> >>>
>>>> >>> Cheers,
>>>> >>>
>>>> >>>
>>>> >>> Chris
>>>> >>>
>>>> >>>
>>>> >>> On Tue, October 3, 2017 02:14, javafx at use.startmail.com wrote:
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>>
>>>> >>>> Hi again !
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> Well I was able to track down the source of the error I am
>>>> >>>> receiving from the gradle build. Unfortunately, the error
>>>> persists,
>>>> >>>> which is a bit of a mystery. Maybe a gradle maven can
>>>> enlighten me
>>>> >>>> here.
>>>> >>>>
>>>> >>>> For some reason, this line on line 90-91 of win.gradle is
>>>> throwing
>>>> >>>> the exception, although I can prove it ought not to: if
>>>> >>>> (WINDOWS_SDK_DIR ==
>>>> >>>> null || WINDOWS_SDK_DIR == "") { throw new
>>>> GradleException("FAIL:
>>>> >>>> WINSDK_DIR not defined");
>>>> >>>> I cannot get past this, the exception is triggered, and yet
>>>> the
>>>> >>>> assignment of a value to property WINDOWS_SDK_DIR is quite
>>>> clear here
>>>> >>>> (line
>>>> >>>> of 69 win.gradle): defineProperty("WINDOWS_SDK_DIR",
>>>> properties,
>>>> >>>> System.getenv().get("WINSDK_DIR"))
>>>> >>>> and that system variable is, in fact, set as proved by (my)
>>>> running
>>>> >>>> this simple program I wrote (which exists in the same
>>>> directory as
>>>> >>>> win.gradle to exclude any conceivable path issues) and
>>>> getting the
>>>> >>>> proper outputpublic class WinSDK { public WinSDK() { } public
>>>> static
>>>> >>>> void main(String[] args) { String sdk =
>>>> >>>> (String)System.getenv().get("WINSDK_DIR");
>>>> >>>> System.out.println("sdk = " + sdk);
>>>> >>>> }
>>>> >>>> }
>>>> >>>> Output as expected- the proper path to Microsoft SDK and
>>>> anyways
>>>> >>>> certainly not the empty string or null.
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> Sorry to ask such a basic question but is anyone on this list
>>>> >>>> actually able to clone then compile OpenFX from source using
>>>> the
>>>> >>>> procedure outlined on the below mentioned page using any of
>>>> the
>>>> >>>> gradle scripts, (in my instance gradle.win) ?
>>>> >>>>
>>>> >>>> Seems like first -step level stuff that is done regularly by
>>>> >>>> everyone on the list interested in improving or exploring
>>>> OpenFX but
>>>> >>>> maybe I am wrong about this? Many thanks in advance.
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> On Thursday, September 28, 2017 6:59 PM,
>>>> >>>> javafx at use.startmail.comwrote:
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>> Hi All,
>>>> >>>>> New member to this group. I am encountering a little trouble
>>>> when
>>>> >>>>> I
>>>> >>>>> try to build OpenJFX. I am following the instructions here:
>>>> (using
>>>> >>>>> Cygwin
>>>> >>>>> on Win 7):
>>>> >>>>>
>>>> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> When I run gradle after cloning the OpenJFX repository, I
>>>> get a
>>>> >>>>> "build
>>>> >>>>> failed with exception" . I include the output from the
>>>> entire run
>>>> >>>>> just in case it's significant:
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> $ gradle
>>>> >>>>> WARNING: An illegal reflective access operation has occurred
>>>> >>>>> WARNING: Illegal reflective access by
>>>> >>>>> org.gradle.internal.reflect.JavaMethod
>>>> >>>>> (file:/C:/gradle/lib/gradle-base-services-3.1.jar) to method
>>>> >>>>> java.lang.ClassLoader.getPackages() WARNING: Please consider
>>>> >>>>> reporting this to the maintainers of
>>>> >>>>> org.gradle.internal.reflect.JavaMethod WARNING: Use
>>>> >>>>> --illegal-access=warn to enable warnings of further
>>>> >>>>> illegal reflective access operations WARNING: All illegal
>>>> access
>>>> >>>>> operations will be denied in a future release
>>>> >>>>> :buildSrc:generateGrammarSource UP-TO-DATE
>>>> >>>>> :buildSrc:compileJava UP-TO-DATE
>>>> >>>>> :buildSrc:compileGroovy UP-TO-DATE
>>>> >>>>> :buildSrc:processResources UP-TO-DATE
>>>> >>>>> :buildSrc:classes UP-TO-DATE
>>>> >>>>> :buildSrc:jar UP-TO-DATE
>>>> >>>>> :buildSrc:assemble UP-TO-DATE
>>>> >>>>> :buildSrc:compileTestJava UP-TO-DATE
>>>> >>>>> :buildSrc:compileTestGroovy UP-TO-DATE
>>>> >>>>> :buildSrc:processTestResources UP-TO-DATE
>>>> >>>>> :buildSrc:testClasses UP-TO-DATE
>>>> >>>>> :buildSrc:test UP-TO-DATE
>>>> >>>>> :buildSrc:check UP-TO-DATE
>>>> >>>>> :buildSrc:build UP-TO-DATE
>>>> >>>>> FAILURE: Build failed with an exception.
>>>> >>>>> * Where:
>>>> >>>>> Script 'C:\cygwin64\home\mdbg\rt\buildSrc\win.gradle' line:
>>>> 91
>>>> >>>>> * What went wrong:
>>>> >>>>> A problem occurred evaluating script.
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>> FAIL: WINSDK_DIR not defined
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>> * Try:
>>>> >>>>> Run with --stacktrace option to get the stack trace. Run
>>>> with
>>>> >>>>> --info
>>>> >>>>> or --debug option to get more log output. BUILD FAILED
>>>> >>>>> Total time: 1.376 secs
>>>> >>>>> I should add that even though the tutorial doesn't mention
>>>> to do
>>>> >>>>> it, I
>>>> >>>>> cd-ed into the folder named rt, which was created by
>>>> Mercurial when
>>>> >>>>> I
>>>> >>>>> cloned OpenJFX, I called gradle from there. Calling it from
>>>> the
>>>> >>>>> directory containing rt resulted in nothing happening ,
>>>> which
>>>> >>>>> makes sense afaik. the variable WINSDK is not one I am
>>>> familiar
>>>> >>>>> with- it's not any environment or system variable on my
>>>> machine
>>>> >>>>> and the tutorial doesn't say anything about it. I hesitate
>>>> to start
>>>> >>>>> arbitrarily hacking build files based on error messages. It
>>>> seems
>>>> >>>>> as though it ought to just work and perhaps this is a bug I
>>>> should
>>>> >>>>> report or is it something else ?
>>>> >>>>> Thank you!
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>
>>>> >>>
>>>> >>
>>>> >
>>>>
>>>>
More information about the openjfx-dev
mailing list