Native part of FWD build fails when the used JDK is installed to a path location with white spaces
#1 Updated by Hynek Cihlar over 4 years ago
- Subject changed from Native part of FWD build fails when the used JRE is installed to a path location with white spaces to Native part of FWD build fails when the used JDK is installed to a path location with white spaces
This issue was found on Windows. The JDK's default install location there is
C:\Program Files\.... The build logic interprets the path with empty spaces as multiple locations when referencing the JVM include files.
Current workaround is to use a JDK installed to a location without spaces.
#2 Updated by Hynek Cihlar over 4 years ago
The no-space constraint if caused by parameters received by mingw compiler. The (spaced-)path will be seen as two paths and files won't be found. Please see my mail from last night for two workaround solutions. I guess the native target in gradle/ant can be fixed to support this, by passing the paths to JAVA_HOME/JRE_HOME in double quotes.
#3 Updated by Ovidiu Maxiniuc over 4 years ago
ant tool uses
JAVA_HOME to built the path for include headers for
If JDK is already installed or to avoid installing it to a different location, we just need to set
JAVA_HOME environment variable so it does not contain spaces (which will be sent to
gcc and will split paths to multiple parameters).
The solution is to replace file-tokens that contains spaces with their legacy 8.3 filename that are space-less. Usually the problem tokens are
Program Files and
Program Files (x86) if a 32 bit Java is installed on a 64-bit OS. The default legacy file name for these are
PROGRA~2, but these can be different in some conditions, for example if Windows was not clean installed. In this case we need to use
dir C:\ /X
command to find out the legacy names. They are found in second to the last column, like this:
16-Nov-15 02:45 PM <DIR> PROGRA~1 Program Files 16-Nov-15 02:48 PM <DIR> PROGRA~2 Program Files (x86) 16-Nov-15 02:51 PM <DIR> Users 16-Nov-15 02:40 PM <DIR> Windows
If needed (the complete path to JDK contains multiple tokens with spaces) repeat the above process for the parent of each affected token.
In the correct value for this environment variable when JDK is installed in the default location, should look like this:
#4 Updated by Eugenie Lyzenko over 3 years ago
After search for solution I've the following conclusion: This is the really
GCC package limitation that does not like the spaces in include file path. So I would offer to use the following scenarios depending on target system configuration:
1. System with no
JDK yet installed. The approach is to install into directory with no spaces inside. Then make respective environment variables.
2. System with
JDK already installed into something like
"Program Files\path to JDK" containing spaces. In this case the developer will need to create symbolic link to
JDK that will not have the spaces:
mklink /D SomePathWithNoSpaces "The target path\to JDK with\spaces inside"
The quotation in link creation command is mandatory for
MKLINKto properly resolve the original directory. After link has been created it must be used in
JRE_HOMEenvironment variables instead of original path with spaces. And this gets
FWDto be properly compiled.
#6 Updated by Eugenie Lyzenko over 3 years ago
#8 Updated by Eugenie Lyzenko over 3 years ago
Greg Shah wrote:
This is the really GCC package limitation that does not like the spaces in include file path.
To confirm: there is nothing we can do in our makefile to avoid this issue?
Whatever we do in makefile - we can not change the current path to
JDK that can have spaces. Otherwise this will be path to other installation and this means technically we just make additional copy of the same
JDK. This can complicate support of the existed
JDK. As I can see this is not a
GCC bug but intention. Some discussion:
This is in our case
-Ipath option issue. I have tried to enclose in
'' or even use
%20 instead of space or escape it with
\ or even
^ (caret). Nothing helps.
So I think it will be the better and safer to just avoid spaces in path.