## Bug #3273

Status:
Closed
Priority:
Normal
Target version:
-
Start date:
Due date:
% Done:

100%

billable:
No
vendor_id:
GCD
case_num:

### History

#### #1 Updated by Hynek Cihlarabout 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 Cihlarabout 4 years ago

From Ovidiu:
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 Maxiniucabout 4 years ago

ant tool uses JAVA_HOME to built the path for include headers for gcc.

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~1 and 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:

JAVA_HOME=C:\PROGRA~1\Java\jdk1.8.0_121


#### #4 Updated by Eugenie Lyzenkoabout 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 MKLINK to properly resolve the original directory. After link has been created it must be used in JAVA_HOME and JRE_HOME environment variables instead of original path with spaces. And this gets FWD to be properly compiled.

#### #5 Updated by Greg Shahabout 3 years ago

Please update our documentation (Install the JDK) to explain the full details. You will see that this document already has one workaround and refers to #3273. It is OK to leave that workaround in place as well as add this additional discussion.

#### #6 Updated by Eugenie Lyzenkoabout 3 years ago

Greg Shah wrote:

Please update our documentation (Install the JDK) to explain the full details. You will see that this document already has one workaround and refers to #3273. It is OK to leave that workaround in place as well as add this additional discussion.

OK. Done.

#### #7 Updated by Greg Shahabout 3 years ago

The documentation update is good.

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?

#### #8 Updated by Eugenie Lyzenkoabout 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:
https://github.com/chef/omnibus/issues/685
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.

#### #9 Updated by Greg Shahabout 3 years ago

• % Done changed from 0 to 100
• Status changed from New to Closed
• Assignee set to Eugenie Lyzenko

OK, thanks for the clarification.