Project

General

Profile

Bug #10609

FWD compilation issues on Windows

Added by Șerban Bursuc 10 months ago. Updated 5 months ago.

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

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:

build.xml.patch Magnifier (2.41 KB) Roger Borrello, 02/26/2026 12:53 AM

makefile.launcher.patch Magnifier (681 Bytes) Roger Borrello, 02/26/2026 12:53 AM

makefile.win_utils.patch Magnifier (654 Bytes) Roger Borrello, 02/26/2026 12:53 AM

makefile.spawn.patch Magnifier (682 Bytes) Roger Borrello, 02/26/2026 12:53 AM

History

#1 Updated by Șerban Bursuc 10 months ago

Continuing the discussion from #7143-1712.

Tomasz, I used the wrapper as well and I still have the same issue. The path is magically broken.

#2 Updated by Tomasz Domin 10 months ago

c:\Projects>cd 9687b

c:\Projects\9687b>gradlew.bat ant-native
To honour the JVM settings for this build a single-use Daemon process will be forked. See https://docs.gradle.org/7.6.4/userguide/gradle_daemon.html#sec:disabling_the_daemon.
Daemon will be stopped at the end of the build

Configure project :

[ant:echo] propArg:

Task :buildVersion

Fetching repository name and branch from bzr info...
WARN: Could not find repository name and branch in 'bzr info' output!
WARN: Unable to resolve repository name. Make sure you build from a supported bzr repository location or the property repo is defined in version.properties.
WARN: Unable to resolve branch name. Make sure you build from a supported bzr repository location or the property branch is defined in version.properties.
Fetching revision number from bzr revno...
Product version: 4.0.0_undefined_undefined_16008

Task :ant-native

[ant:echo]

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

See https://docs.gradle.org/7.6.4/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 17s
27 actionable tasks: 25 executed, 2 up-to-date

#3 Updated by Șerban Bursuc 10 months ago

I took Lorian's functioning compilation and compared the logs.

I noticed that the gcc is skipped but that is because it already succeeded once, if there is an ant clean then the compilation finishes correctly:

#4 Updated by Tomasz Domin 10 months ago

Șerban Bursuc wrote:

I took Lorian's functioning compilation and compared the logs.

{{Collapse(Working)
[...]
}}

{{Collapse(Not working)
[...]
}}

I noticed that the gcc is skipped but that is because it already succeeded once, if there is an ant clean then the compilation finishes correctly: {{Collapse(Compile success)
[...]
}}

Maybe there were some leftovers ?
Is it working now ?

#5 Updated by Șerban Bursuc 10 months ago

Tomasz Domin wrote:

Șerban Bursuc wrote:

I took Lorian's functioning compilation and compared the logs.

{{Collapse(Working)
[...]
}}

{{Collapse(Not working)
[...]
}}

I noticed that the gcc is skipped but that is because it already succeeded once, if there is an ant clean then the compilation finishes correctly: {{Collapse(Compile success)
[...]
}}

Maybe there were some leftovers ?
Is it working now ?

No, I meant that when comparing the logs of working vs not working, in the working version the gcc steps are skipped because there is already a binary file, that's why it skips to the makespawn steps, but if there is an ant clean done before, then the working logs are similar to the non working logs, but the gcc steps all work without issues. So I don't see the problem.

#6 Updated by Tomasz Domin 10 months ago

Șerban Bursuc wrote:

Tomasz Domin wrote:

Șerban Bursuc wrote:

I took Lorian's functioning compilation and compared the logs.

{{Collapse(Working)
[...]
}}

{{Collapse(Not working)
[...]
}}

I noticed that the gcc is skipped but that is because it already succeeded once, if there is an ant clean then the compilation finishes correctly: {{Collapse(Compile success)
[...]
}}

Maybe there were some leftovers ?
Is it working now ?

No, I meant that when comparing the logs of working vs not working, in the working version the gcc steps are skipped because there is already a binary file, that's why it skips to the makespawn steps, but if there is an ant clean done before, then the working logs are similar to the non working logs, but the gcc steps all work without issues. So I don't see the problem.

The difference is also using make vs direct gcc call. Do you have make ?

#7 Updated by Șerban Bursuc 10 months ago

The difference is also using make vs direct gcc call. Do you have make ?

Yes.

C:\hotel_gui\p2j>make --version
GNU Make 4.4.1
Built for x86_64-pc-msys
Copyright (C) 1988-2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

I actually had issues with make in the 32 bit version. It would incorrectly add 32 bit architecture to the compile cmd, here in the makefile:

# calculate the CPU bitness and save it in ARCH
ifndef ARCH
   ifeq "$(OS)" "Windows" 
      ifeq "$(PROCESSOR_ARCHITECTURE)" "AMD64" 
         ARCH=64bit
      else
         ARCH=32bit
      endif
   else
      ARCH := $(shell uname -p)
      ifeq "$(OS)" "SunOS" 
         # x86 CPU needs additional call to get exact info
         ifneq "$(ARCH)" "sparc" 
            ARCH := $(shell isainfo -n)
         endif
      endif
   endif
endif

I do have a system variable PROCESS_ARCHITECTURE that is AMD64 but make would see x86 and it would incorrectly add -DWORD_SIZE_32. I fixed this by using a make build on 64 bit.

Is this an issue, should I have used 32 bit make? If so I don't see how the makefile would be correct, it would constantly pick 32 bit incorrectly.

#8 Updated by Tomasz Domin 10 months ago

For me its:

c:\Projects\9687b>make -version
GNU Make 3.82
Built for x86_64-w64-mingw32

I've never set PROCESS_ARCHITECTURE.

#9 Updated by Tomasz Domin 10 months ago

Is there only one version of gcc installed ?

#10 Updated by Șerban Bursuc 10 months ago

I've never set PROCESS_ARCHITECTURE.

I'm certain this is a Windows default, check the system variables in the environment variables.

Is there only one version of gcc installed ?

No but in the Path variable which make uses I only have one.

I'm considering downgrading make to your version. I have no other ideas.

#11 Updated by Șerban Bursuc 10 months ago

Tomasz, your make version is very old, it doesn't compile even with the latest GCC and not even with the 4.9.0 GCC. There is a 4 year gap in the release (2010 vs 2014).

I'm confused how you have this make version installed. Did you follow some sort of Wiki on Redmine?

#12 Updated by Șerban Bursuc 10 months ago

What Gradle version do you have Tomasz?

#13 Updated by Tomasz Domin 10 months ago

Șerban Bursuc wrote:

Tomasz, your make version is very old, it doesn't compile even with the latest GCC and not even with the 4.9.0 GCC. There is a 4 year gap in the release (2010 vs 2014).

I'm confused how you have this make version installed. Did you follow some sort of Wiki on Redmine?

AFAIR I took everything from the page: Development_Environment_Setup_and_Building_FWD_on_Windows - check Installing MinGW Compiler and Utils

Șerban Bursuc wrote:

What Gradle version do you have Tomasz?

There is no gradle installed on the virtual machine, the one bundled with FWD is in use in version 7.6.4

Oh, virtual machine is Windows 10.

#14 Updated by Șerban Bursuc 10 months ago

So according to the Wiki, make is bundled in the MingW toolkit from our downloads page.

I removed the separately installed make from Path and now the backslash error is gone, but now I get this:

2025-09-24T01:02:20.989-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: terminal.o: invalid relocation type 42
2025-09-24T01:02:20.989-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: BFD (GNU Binutils) 2.24 assertion fail /home/drangon/work/mingw-w64-dgn/source/binutils-2.24/bfd/elf64-x86-64.c:343
2025-09-24T01:02:20.989-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: terminal.o: invalid relocation type 42
2025-09-24T01:02:20.989-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: BFD (GNU Binutils) 2.24 assertion fail /home/drangon/work/mingw-w64-dgn/source/binutils-2.24/bfd/elf64-x86-64.c:343
2025-09-24T01:02:20.989-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: terminal.o: invalid relocation type 42
2025-09-24T01:02:20.989-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: BFD (GNU Binutils) 2.24 assertion fail /home/drangon/work/mingw-w64-dgn/source/binutils-2.24/bfd/elf64-x86-64.c:343
2025-09-24T01:02:20.989-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: terminal.o: invalid relocation type 42
2025-09-24T01:02:20.989-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: BFD (GNU Binutils) 2.24 assertion fail /home/drangon/work/mingw-w64-dgn/source/binutils-2.24/bfd/elf64-x86-64.c:343
2025-09-24T01:02:20.989-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: terminal.o: invalid relocation type 42
2025-09-24T01:02:20.989-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: BFD (GNU Binutils) 2.24 assertion fail /home/drangon/work/mingw-w64-dgn/source/binutils-2.24/bfd/elf64-x86-64.c:343
2025-09-24T01:02:20.989-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: terminal.o: invalid relocation type 42
2025-09-24T01:02:20.990-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: BFD (GNU Binutils) 2.24 assertion fail /home/drangon/work/mingw-w64-dgn/source/binutils-2.24/bfd/elf64-x86-64.c:343
2025-09-24T01:02:20.990-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: library.o: invalid relocation type 42
2025-09-24T01:02:20.990-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: BFD (GNU Binutils) 2.24 assertion fail /home/drangon/work/mingw-w64-dgn/source/binutils-2.24/bfd/elf64-x86-64.c:343
2025-09-24T01:02:20.990-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: library.o: invalid relocation type 42
2025-09-24T01:02:20.990-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: BFD (GNU Binutils) 2.24 assertion fail /home/drangon/work/mingw-w64-dgn/source/binutils-2.24/bfd/elf64-x86-64.c:343
2025-09-24T01:02:20.990-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: library.o: invalid relocation type 42
2025-09-24T01:02:20.990-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: BFD (GNU Binutils) 2.24 assertion fail /home/drangon/work/mingw-w64-dgn/source/binutils-2.24/bfd/elf64-x86-64.c:343
2025-09-24T01:02:20.990-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: library.o: invalid relocation type 42
2025-09-24T01:02:20.990-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: BFD (GNU Binutils) 2.24 assertion fail /home/drangon/work/mingw-w64-dgn/source/binutils-2.24/bfd/elf64-x86-64.c:343
2025-09-24T01:02:20.990-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: library.o: invalid relocation type 42
2025-09-24T01:02:20.990-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: BFD (GNU Binutils) 2.24 assertion fail /home/drangon/work/mingw-w64-dgn/source/binutils-2.24/bfd/elf64-x86-64.c:343
2025-09-24T01:02:20.990-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: library.o: invalid relocation type 42
2025-09-24T01:02:20.990-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: BFD (GNU Binutils) 2.24 assertion fail /home/drangon/work/mingw-w64-dgn/source/binutils-2.24/bfd/elf64-x86-64.c:343
2025-09-24T01:02:20.990-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: library.o: invalid relocation type 42
2025-09-24T01:02:20.990-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: BFD (GNU Binutils) 2.24 assertion fail /home/drangon/work/mingw-w64-dgn/source/binutils-2.24/bfd/elf64-x86-64.c:343
2025-09-24T01:02:20.990-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: library.o: invalid relocation type 42
2025-09-24T01:02:20.990-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: BFD (GNU Binutils) 2.24 assertion fail /home/drangon/work/mingw-w64-dgn/source/binutils-2.24/bfd/elf64-x86-64.c:343
2025-09-24T01:02:20.990-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: library.o: invalid relocation type 42
2025-09-24T01:02:20.990-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: BFD (GNU Binutils) 2.24 assertion fail /home/drangon/work/mingw-w64-dgn/source/binutils-2.24/bfd/elf64-x86-64.c:343
2025-09-24T01:02:20.990-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: library.o: invalid relocation type 42
2025-09-24T01:02:20.990-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: BFD (GNU Binutils) 2.24 assertion fail /home/drangon/work/mingw-w64-dgn/source/binutils-2.24/bfd/elf64-x86-64.c:343
2025-09-24T01:02:20.991-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: library.o: invalid relocation type 42
2025-09-24T01:02:20.991-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: BFD (GNU Binutils) 2.24 assertion fail /home/drangon/work/mingw-w64-dgn/source/binutils-2.24/bfd/elf64-x86-64.c:343
2025-09-24T01:02:20.991-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] library.o: In function `convertType':
2025-09-24T01:02:20.991-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] library.c:(.text+0x500): Cannot get section contents - auto-import exception
2025-09-24T01:02:20.991-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] collect2.exe: error: ld returned 5 exit status
2025-09-24T01:02:20.997-0700 [INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] make: *** [p2j.dll] Error 1

I see a mysterious path in the errors, I assume the prebuilt binaries are not good?

#15 Updated by Șerban Bursuc 10 months ago

Finally ant-native works. It literally does not work unless you use the bundled mingw from the Wiki with the specific versions they have for make and gcc, otherwise they fail at the slash error. I think that's a problem and the build scripts and makefiles need to account for this.

I still had to do one change, I'm not sure whether it's because the script is for Java 8 or because it accounts only for the JRE, but if you install the JDK the path is wrong in build.xml, this needs to be modified:

=== modified file 'build.xml'
--- build.xml   2025-07-04 08:21:50 +0000
+++ build.xml   2025-09-24 09:08:36 +0000
@@ -1806,7 +1806,7 @@
      <condition property="native.jvm.incpath" value="${java.home}/../" else="${java.home}">
         <isset property="old.java.home"/>
      </condition>
-     <condition property="native.jvm.libpath" value="${java.home}/lib/${os.arch}/server/" else="${java.home}/lib/server/" >
+     <condition property="native.jvm.libpath" value="${java.home}/lib/${os.arch}/server/" else="${java.home}/bin/server/" >
         <isset property="old.java.home"/>
      </condition>
      <exec dir="${build.home}/native" executable="${native.build.tool}" failonerror="true">

Now FWD fully compiles for me.

#16 Updated by Eugenie Lyzenko 10 months ago

Just FYI. I did a full recent trunk(16183) build inside Windows 10 min ago. There is no problems encountered.

You will need to exactly do set up steps for Windows system

Do not use any custom setup with partial MinGW builds. We already have fully compatible zip.

The GCC is 4.9.0. We already spent a time to prepare "just unzip and run" approach. No need to spend new time for this again.

#17 Updated by Șerban Bursuc 10 months ago

Eugenie Lyzenko wrote:

Just FYI. I did a full recent trunk(16183) build inside Windows 10 min ago. There is no problems encountered.

You will need to exactly do set up steps for Windows system

Do not use any custom setup with partial MinGW builds. We already have fully compatible zip.

The GCC is 4.9.0. We already spent a time to prepare "just unzip and run" approach. No need to spend new time for this again.

The wikis are fragmented, there is the wiki you linked, the one Tomasz linked and there's also this outdated and non functional one: Windows 11 Virtual Machine Setup with FWD v4 and the Testcase Project. This one which I happened to follow tells you to first install a make then get the MingW tool suite hosted on Redmine. But if you do this and get ANY other make other than the one bundled with MingW, you get compile errors. I also think that the build files should work with newer versions too but I understand it requires more resources.

Regarding the build.xml change, even the wiki you linked is not correct, it says to add %JAVA_HOME%/jre/bin/server to Path, but newer JDKs do not have a jre folder anymore. The correct option is to do %JAVA_HOME%/bin/server, this is mentioned by Windows 11 Virtual Machine Setup with FWD v4 and the Testcase Project but I missed it. I expected the build script to work just knowing the root folder of the JDK, thought it was some kind of mistake.

In conclusion it's hard to have the perfect setup for Windows. The steps are very strict. But at least I can share this new info to others at the office who have trouble :)

#18 Updated by Șerban Bursuc 10 months ago

Small correction, the -ljvm linker error is not fixed by adding /bin/server to path, it's fixed by moving jvm.lib from jdk/lib/ to mingw64/lib.

#19 Updated by Greg Shah 10 months ago

+Roger

#20 Updated by Roger Borrello 5 months ago

Șerban Bursuc wrote:

Eugenie Lyzenko wrote:

Just FYI. I did a full recent trunk(16183) build inside Windows 10 min ago. There is no problems encountered.

You will need to exactly do set up steps for Windows system

Do not use any custom setup with partial MinGW builds. We already have fully compatible zip.

The GCC is 4.9.0. We already spent a time to prepare "just unzip and run" approach. No need to spend new time for this again.

The wikis are fragmented, there is the wiki you linked, the one Tomasz linked and there's also this outdated and non functional one: Windows 11 Virtual Machine Setup with FWD v4 and the Testcase Project. This one which I happened to follow tells you to first install a make then get the MingW tool suite hosted on Redmine. But if you do this and get ANY other make other than the one bundled with MingW, you get compile errors. I also think that the build files should work with newer versions too but I understand it requires more resources.

The Windows 11 Virtual Machine Setup with FWD v4 and the Testcase Project wiki was written by Galya and probably should be removed, unless Greg had a particular plan for it. I've never tried to follow it. The Building FWD From Source wiki is much newer than the Development Environment Setup and Building FWD on Windows wiki, although I don't see conflicting information related to the make and gcc, since they are both pointing to the 4.9.0 pre-built MinGW on proj download page.

Regarding the build.xml change, even the wiki you linked is not correct, it says to add %JAVA_HOME%/jre/bin/server to Path, but newer JDKs do not have a jre folder anymore. The correct option is to do %JAVA_HOME%/bin/server, this is mentioned by Windows 11 Virtual Machine Setup with FWD v4 and the Testcase Project but I missed it. I expected the build script to work just knowing the root folder of the JDK, thought it was some kind of mistake.

The %JAVA_HOME%/jre... information is from the very old wiki. Since I constantly have issues building native, I hesitate to touch either of them until we get all the setup steps correct.

In conclusion it's hard to have the perfect setup for Windows. The steps are very strict. But at least I can share this new info to others at the office who have trouble :)

It is helpful to get another set of eyes on it. For me, I can get the build to work if I use ant and the ant-native target. But I have to define -Dbasedir=C:/projects/fwd/trunk and -Dnative.jvm.incpath=C:/jdk-17 on the command line to get it correct. When I use native target, something changes those properties, and the path is messed up again. I suppose gradle man-handles the build.xml properties and those specific properties are replaced.

So after trying several things to get some consistency, I was able to find that the handling of paths can be normalized within the build, rather than relying upon the tools that we are using to do the build. I recall seeing someone mention that an older version of make would handle things better. I found that by "normalizing" paths to Unix variety at the correct location, I was able to build consistently, whether I was in gradle, or directly to ant. This seems to be primarily focused on the "ant-native" target, where we drop into makefiles that are using standard DOS commands, as well as the GNU tools. So some of the DOS commands don't behave properly if the paths are Unix-style.

Here are the build.xml changes and the other makefile changes that worked consistently for me:


It might be that some of those aren't really required to be normalized and there might be a more efficient method.

For the native makefiles for spawner, launcher, and win_utils, the changes are all similar:

Are these changes that should be considered?

#21 Updated by Șerban Bursuc 5 months ago

although I don't see conflicting information related to the make and gcc, since they are both pointing to the 4.9.0 pre-built MinGW on proj download page.

My point here was that the 4.9.0 version is linked there as "here is the convenient download link" but it doesn't feel mandatory. The reality is that using the prepackaged binaries from our servers is mandatory. If you attempt to use any other combination of MingW or Make you get wild errors like I did. So my problem was the fact it looked like GCD devs used those packages in the past with success, but now that they're old you might as well upgrade - completely wrong. FWD only works with those packages hosted on our servers. This might as well be bundled into trunk or in our Docker images, to prevent any attempt at any developer using something else.

#22 Updated by Roger Borrello 5 months ago

With the merge of #4645, the problem is still there:

> Task :nativeCompile FAILED
gcc -c C:\projects\fwd\trunk_test/src/native/process.c -o process.o -DWIN_TARGET -DWORD_SIZE_64 -DFWD_VERSION="\"4.0.0_p2j_trunk_16447\"" -IC:\jdk-17/include -IC:\jdk-17/include/win32 -IC:\projects\fwd\trunk_test/src/native -Wall -fpic
gcc.exe: error: C:projectsfwdtrunk_test/src/native/process.c: No such file or directory
gcc.exe: fatal error: no input files
compilation terminated.
make: *** [process.o] Error 1

[Incubating] Problems report is available at: file:///C:/projects/fwd/trunk_test/build/reports/problems/problems-report.html

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':nativeCompile'.
> Process 'command 'make'' finished with non-zero exit value 2

I had tried updates to the build.gradle previously, when it was importing the ant build file where the properties were updated after import:

ant.properties['basedir'] = project.projectDir.absolutePath.replace('\\','/')
ant.properties['src.home'] =
        new File(project.projectDir, "src")
        .absolutePath
        .replace('\\','/')

but I don't know if that fits now. I haven't look at build.gradle yet.

#23 Updated by Eugenie Lyzenko 5 months ago

Roger Borrello wrote:

With the merge of #4645, the problem is still there:
[...]

I had tried updates to the build.gradle previously, when it was importing the ant build file where the properties were updated after import:
[...]
but I don't know if that fits now. I haven't look at build.gradle yet.

Roger,

Last week I tested 4645a and trunk under Windows. In this process I got issues but never with FWD building itself. Used Windows 10 and Windows 11.

However I used gradlew all --info command. And did set up mingw from our prebuilt binaries. Including manual copy of the jvm.(lib|dll) into respective locations.

Have you tried to do full build, not just native part?

#24 Updated by Roger Borrello 5 months ago

Eugenie Lyzenko wrote:

Last week I tested 4645a and trunk under Windows. In this process I got issues but never with FWD building itself. Used Windows 10 and Windows 11.

However I used gradlew all --info command. And did set up mingw from our prebuilt binaries. Including manual copy of the jvm.(lib|dll) into respective locations.

Have you tried to do full build, not just native part?

The first thing I did was gradlew all sheet:war archive.

I think that all the underlying utilities (gcc, make) can handle Unix-style paths. But at the lowest level, in makefile, there are DOS commands executed, which cannot handle Unix-style paths. Perhaps if those tools were moved to MinGW tools (cp instead of copy, rm instead of del, etc.) perhaps we could convert all the paths at the gradle level to Unix style?

#25 Updated by Roger Borrello 5 months ago

With just some minor updates to the src/native/makefile.* and a change to build.gradle, I think the pathing issue will be gone. The paths will be Unix-style throughout, with the exception of those OUTDIR, which are used for the DOS copy and del commands.

=== modified file 'build.gradle'
--- build.gradle        2026-02-26 17:47:55 +0000
+++ build.gradle        2026-02-26 21:32:55 +0000
@@ -934,12 +934,14 @@
     def libname = isWindows ? 'p2j.dll' : 'libp2j.so'
     def buildTool = isSunOS ? 'gmake' : 'make'

+    def unixPath = { p -> file(p).absolutePath.replace('\\', '/') }
+
     // JVM paths for JNI include and library
     def jreHome = System.getProperty('java.home')
     def oldJavaHome = file("${jreHome}/../jre").exists()
-    def jvmIncPath = oldJavaHome ? "${jreHome}/.." : jreHome
-    def jvmLibPath = oldJavaHome ? "${jreHome}/lib/${System.getProperty('os.arch')}/server/" :
-                                   "${jreHome}/lib/server/" 
+    def jvmIncPathRaw = oldJavaHome ? "${jreHome}/.." : jreHome
+    def jvmLibPathRaw = oldJavaHome ? "${jreHome}/lib/${System.getProperty('os.arch')}/server/" :
+                                      "${jreHome}/lib/server/" 

     // Optional properties (can be set via -P flags)
     def postBuild = project.findProperty('post.build') ?: ''
@@ -961,14 +963,14 @@
     workingDir "${layout.buildDirectory.get()}/native" 
     executable buildTool
     args "SONAME=${libname}",
-         "SRCDIR=${projectDir}/src/native",
-         "JRE_HOME=${jreHome}",
-         "JVM_INCPATH=${jvmIncPath}",
-         "JVM_LIBPATH=${jvmLibPath}",
+         "SRCDIR=${unixPath(projectDir)}/src/native",
+         "JRE_HOME=${unixPath(jreHome)}",
+         "JVM_INCPATH=${unixPath(jvmIncPathRaw)}",
+         "JVM_LIBPATH=${unixPath(jvmLibPathRaw)}",
          "PB=${postBuild}",
-         "SPAWN_FOLDER=${spawnFolder}",
-         "SRV_CERTS_STORE=${srvCerts}",
-         "SPAWN_BUILD_SCRIPT=${spawnBuildScript}",
+         "SPAWN_FOLDER=${spawnFolder ? unixPath(spawnFolder) : ''}",
+         "SRV_CERTS_STORE=${srvCerts ? unixPath(srvCerts) : ''}",
+         "SPAWN_BUILD_SCRIPT=${spawnBuildScript ? unixPath(spawnBuildScript) : ''}",
          "PAM=${havePam}" 

     doLast {

=== modified file 'src/native/makefile.spawn'
--- src/native/makefile.spawn   2023-08-02 17:45:41 +0000
+++ src/native/makefile.spawn   2026-02-26 21:44:13 +0000
@@ -226,7 +226,7 @@
        OUTDIR=..\..\build
        PLATFORM_DIR=win32
        RMCMD=cmd.exe /k del /q
-       SOURCE=$(SRCDIR)\winspawn.c
+       SOURCE=$(SRCDIR)/winspawn.c
        EXENAME=spawn.exe
        TARGET=$(OUTDIR)\native\$(EXENAME)
        RELEASE=$(OUTDIR)\lib\$(EXENAME)

=== modified file 'src/native/makefile.win_utils'
--- src/native/makefile.win_utils       2022-05-04 01:53:32 +0000
+++ src/native/makefile.win_utils       2026-02-26 21:45:37 +0000
@@ -150,7 +150,7 @@
 OUTDIR=..\..\build
 PLATFORM_DIR=win32
 RMCMD=cmd.exe /k del /q
-SOURCE=$(SRCDIR)\get_text_metrics.c
+SOURCE=$(SRCDIR)/get_text_metrics.c
 EXENAME=get_text_metrics.exe
 TARGET=$(OUTDIR)\native\$(EXENAME)
 RELEASE=$(OUTDIR)\lib\$(EXENAME)

=== modified file 'src/native/makefile.launcher'
--- src/native/makefile.launcher        2022-10-28 10:54:33 +0000
+++ src/native/makefile.launcher        2026-02-26 21:46:13 +0000
@@ -190,7 +190,7 @@
        OUTDIR=..\..\build
        PLATFORM_DIR=win32
        RMCMD=cmd.exe /k del /q
-       SOURCE=$(SRCDIR)\fwd_local_launcher.c $(SRCDIR)\launcher_win.c $(SRCDIR)\desktop_win.c
+       SOURCE=$(SRCDIR)/fwd_local_launcher.c $(SRCDIR)/launcher_win.c $(SRCDIR)/desktop_win.c
        EXENAME=fwd_local_launcher.exe
        TARGET=$(OUTDIR)\native\$(EXENAME)
        RELEASE=$(OUTDIR)\lib\$(EXENAME)

#26 Updated by Eugenie Lyzenko 5 months ago

Roger Borrello wrote:

Eugenie Lyzenko wrote:

Last week I tested 4645a and trunk under Windows. In this process I got issues but never with FWD building itself. Used Windows 10 and Windows 11.

However I used gradlew all --info command. And did set up mingw from our prebuilt binaries. Including manual copy of the jvm.(lib|dll) into respective locations.

Have you tried to do full build, not just native part?

The first thing I did was gradlew all sheet:war archive.

I think that all the underlying utilities (gcc, make) can handle Unix-style paths.

Yes this should be true. Moreover modern Windows also accept the "/" for patch names in command like cd some/new/path.

And I just ran full build with command you provided for trunk 16447 on Windows 10. All finished fine including native part.

Don't you have another C building on your system? May be VC? Probably other tools interfere with MinGW setup?

What Windows do you use getting issue?

#27 Updated by Roger Borrello 5 months ago

Eugenie Lyzenko wrote:

Yes this should be true. Moreover modern Windows also accept the "/" for patch names in command like cd some/new/path.

And I just ran full build with command you provided for trunk 16447 on Windows 10. All finished fine including native part.

Don't you have another C building on your system? May be VC? Probably other tools interfere with MinGW setup?

What Windows do you use getting issue?

The point is that the build should work over a large span of toolsets by making the build "agnostic" to that part of the environment. So it should work for you, for me, as long as we have the basics and not a specific version. I am using the 64 bit MinGW as we are told in the setup from our ZIP file on Windows 11.

#28 Updated by Eugenie Lyzenko 5 months ago

Roger Borrello wrote:

Eugenie Lyzenko wrote:

Yes this should be true. Moreover modern Windows also accept the "/" for patch names in command like cd some/new/path.

And I just ran full build with command you provided for trunk 16447 on Windows 10. All finished fine including native part.

Don't you have another C building on your system? May be VC? Probably other tools interfere with MinGW setup?

What Windows do you use getting issue?

The point is that the build should work over a large span of toolsets by making the build "agnostic" to that part of the environment. So it should work for you, for me, as long as we have the basics and not a specific version.

I do understand your point. And agree, the process should be system/human independent.

My point is every time I take the fresh install for Windows (inside VirtualBox) and repeat set of setup instructions with tools mentioned in our wiki and using our zips I have the correct result for FWD building. I think we need to understand what is the difference between good working system and problematic one. This way we can see what should be changed in our setup instruction. For example how to set up PATH or other variable. Or to avoid using VisualC and command prompt that setting up to use VC.

Do you have VisualC from Microsoft on your system?

I am using the 64 bit MinGW as we are told in the setup from our ZIP file on Windows 11.

I've just repeated full process on Windows 11. Everything is OK.

#29 Updated by Greg Shah 5 months ago

Eugenie is right that we need to figure out the cause of the problem (the difference between the two environments).

In addition, I'd like to have less dependency on that one mingw zip file. As far as I know, no one has ever gotten the build working except with the "special" mingw zip that Eugenie has created. It would be very helpful if it was easily possible to installmingw from scratch and get the same result.

#30 Updated by Șerban Bursuc 5 months ago

I think we need to understand what is the difference between good working system and problematic one.

The difference is simple, you can install MingW online outside of your packages and the issue is reproducible. If you managed to get FWD compiling on Windows with a fresh MingW (most of us use a GUI interface to install everything, like from here: https://sourceforge.net/projects/mingw/) then we're all doing something wrong.

#31 Updated by Eugenie Lyzenko 5 months ago

Șerban Bursuc wrote:

I think we need to understand what is the difference between good working system and problematic one.

The difference is simple, you can install MingW online outside of your packages and the issue is reproducible. If you managed to get FWD compiling on Windows with a fresh MingW (most of us use a GUI interface to install everything, like from here: https://sourceforge.net/projects/mingw/)

The usage of the pre-compiled builds is much more simple. You need to only uzip archive and set PATH variable. No need to think what to install, how to install, where to get and what version. No need to reboot workstation.

Am I wrong?

then we're all doing something wrong.

The MinGW is third party tool we can not control. It is possible it become incompatible with out goals. We certainly know the binaries we have are OK. Why do we need to worry about if we can work with "recent" MinGW partially downloaded? It is just a too we have to use to make native module.

#32 Updated by Greg Shah 5 months ago

We do need to be able to use newer versions of mingw. No one except you has ever succeeded in making mingw work. That is concerning because it means that we have no documented way to install mingw from scratch. I think we need that.

Yes, it is useful to have a preinstalled zip. But that should only be a convenience, it should not be a requirement.

#33 Updated by Eugenie Lyzenko 5 months ago

Greg Shah wrote:

We do need to be able to use newer versions of mingw. No one except you has ever succeeded in making mingw work.

This is a kind of surprise for me. And I can say I tried to set up MinGW binaries from Web, the result was always negative. That's why I made our own binaries.

That is concerning because it means that we have no documented way to install mingw from scratch. I think we need that.

Agree, we need to check the current status of the MinGW project to see if something is changed.

Yes, it is useful to have a preinstalled zip. But that should only be a convenience, it should not be a requirement.

I see.

#34 Updated by Eugenie Lyzenko 5 months ago

Greg,

I have just tested recent MinGW binaries from here: https://winlibs.com/ the version is 15_2_0.

The compilation is OK. The jvm.lib and ffi libraries/header should be copied. And the C language syntax has a bit change for data types. But no other issues.

The only note: it is a zip file for unzip and run approach. I have not found the GUI installer. Is it a critical point?

#35 Updated by Greg Shah 5 months ago

The only note: it is a zip file for unzip and run approach. I have not found the GUI installer. Is it a critical point?

No, a GUI installer is not a requirement.

My worry here is that we can't prove the safety of the distribution from winlibs. Here is what we would have to do to prove it is safe:

  1. Have a documented process to install all of the tools manually and achieve a working build environment. The installation can be non-GUI, but the idea is to install "clean" and "official" versions of all needed tools.
  2. Generate builds with both the winlibs environment and with the manually built "official" environment.
  3. Compare the builds to confirm they are essentially identical.

Unfortunately, doing this may take some time.

#36 Updated by Eugenie Lyzenko 5 months ago

Greg Shah wrote:

The only note: it is a zip file for unzip and run approach. I have not found the GUI installer. Is it a critical point?

No, a GUI installer is not a requirement.

My worry here is that we can't prove the safety of the distribution from winlibs. Here is what we would have to do to prove it is safe:

  1. Have a documented process to install all of the tools manually and achieve a working build environment. The installation can be non-GUI, but the idea is to install "clean" and "official" versions of all needed tools.
  2. Generate builds with both the winlibs environment and with the manually built "official" environment.
  3. Compare the builds to confirm they are essentially identical.

Unfortunately, doing this may take some time.

In this discussion what do you mean with term "official"? Is there the resource where the MinGW can be taken as "official" one? I tried to find but either the version is outdated (as of 2021) or unavailable.

#37 Updated by Greg Shah 5 months ago

In this discussion what do you mean with term "official"? Is there the resource where the MinGW can be taken as "official" one? I tried to find but either the version is outdated (as of 2021) or unavailable.

What is the original project where MinGW was created or ported? That would be the "official" version.

#38 Updated by Eugenie Lyzenko 5 months ago

Greg Shah wrote:

In this discussion what do you mean with term "official"? Is there the resource where the MinGW can be taken as "official" one? I tried to find but either the version is outdated (as of 2021) or unavailable.

What is the original project where MinGW was created or ported? That would be the "official" version.

I have found this: https://www.msys2.org/ which looks like "official" site for MinGW, right?

Following instructions from this source (available via VPN in my region) I confirm the MinGW has a troubles with handling "\" characters in path when building FWD in Windows. So we have to apply fix from Roger's note in #10609-25. Moreover this is known issue and described in this site as feature of Linux style build for Windows (it has specific terminal application to execute building process).

Even having this installer executed it is required to copy some libs/headers into MinGW for ffi and jvm. Also it is required to rename make utility to make.exe to complete native part building.

#39 Updated by Greg Shah 5 months ago

Eugenie Lyzenko wrote:

Greg Shah wrote:

In this discussion what do you mean with term "official"? Is there the resource where the MinGW can be taken as "official" one? I tried to find but either the version is outdated (as of 2021) or unavailable.

What is the original project where MinGW was created or ported? That would be the "official" version.

I have found this: https://www.msys2.org/ which looks like "official" site for MinGW, right?

I think https://www.mingw-w64.org/ is the original site.

Following instructions from this source (available via VPN in my region) I confirm the MinGW has a troubles with handling "\" characters in path when building FWD in Windows. So we have to apply fix from Roger's note in #10609-25. Moreover this is known issue and described in this site as feature of Linux style build for Windows (it has specific terminal application to execute building process).

Even having this installer executed it is required to copy some libs/headers into MinGW for ffi and jvm. Also it is required to rename make utility to make.exe to complete native part building.

Document everything you have to do.

Also available in: Atom PDF