Try changing line 275 of the root build.gradle from:

ext.IS_64 = OS_ARCH.toLowerCase().contains("64")

to:

ext.IS_64 = true


On Sun, Oct 8, 2017 at 6:24 PM, <jav...@use.startmail.com> wrote:

> 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 <
> ketch...@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 <jav...@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_i
>>> mpl_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 <
>>> ketch...@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 <cnewl...@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 <jav...@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.rushfo...@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, jav...@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@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!
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>
>>>>> >>>
>>>>> >>
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>


-- 
Michael Ennen

Reply via email to