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