Building ToolMaker on various platforms

[tajmone]

@thoni56, I've tried to build the repo under Win 10 using MSYS2 + MinGW-32, but only managed to compile part of the project. IRC, you mention somewhere that it only builds using CygWin.

Pre-Compiled Win Binaries

Since I'd like to be able to access all the ToolMaker binaries for the ALAN source project, I was hoping to manage to build it with MSYS2 and also wondering whether you could either:

1. Make the precompiled binaries for Windows available for download somewhere.
2. Add a Travis CI job to cross-compile ToolMaker for Windows under Ubuntu when a release is created.

As for the latter, it could automate adding precompiled binaries for other OSs too, and include them in each tagged GitHub release. Since the project is not actually following a versioned-releases strategy, and because it includes various tools, you could use dates in the YYYY-MM-DD format for release tags, instead of SemVer, and simply create a new release whenever any of the project tools was updated.

This might be a better versioning strategy, since the goal would be just to provide up-to-date binaries which each release, and because SemVer tags are not applicable to the whole project, besides not being practical in this case.

MSYS2/MinGW-32 Failure

Any idea why the build fails under MSYS2? The only binaries that compile successfully are:

• imp.exe
• lmk.exe
• smk.exe

These tools seems to work fine — at least, I can query them via -help.

The Make log is rather long and not entirely clear, due to the many GCC warnings that clutter it. I've pasted it below, in a foldable section (so it doesn't take the whole page).

From what I gather, it fails to build the pmk tool:

collect2.exe: error: ld returned 1 exit status
make[1]: *** [Makefile:60: mingw32] Error 1
make[1]: Leaving directory '/d/GitHub/ToolMaker/ToolMaker/src/pmk'
make: *** [Makefile:8: all] Error 2

but I'm not sure what the collect2.exe binary is (part of the repo?) and why it's failing.

Since Make aborts at the above error, I have no idea if there are other problems with the remaining tools (I don't even know how many binaries I should expect on a successful build). Maybe if we manage to fix the above problem the rest of the Makefile works fine under MSYS2, or maybe there are more problems.

I haven't yet tried to build other sub-folders/tool using their Makefiles, but I will try to.

MSYS Log

Error log trying to build the project under Windows 10 x64, using MSYS2 and MinGW-32.

MSYS2 Error Log (click to unfold)

``` P.K.Dick@RANXEROX MINGW32 /d/ToolMaker/src $ make cd tmk; make all make[1]: Entering directory '/d/ToolMaker/src/tmk' Rebuilding for mingw32 rm: cannot remove '*.o': No such file or directory rm: cannot remove '*.a': No such file or directory gcc -Wall -g -DTARGETOS=\"mingw32\" -m32 -c -o tmkPaSema.o tmkPaSema.c gcc -Wall -g -DTARGETOS=\"mingw32\" -m32 -c -o tmkParse.o tmkParse.c gcc -Wall -g -DTARGETOS=\"mingw32\" -m32 -c -o tmkErr.o tmkErr.c gcc -Wall -g -DTARGETOS=\"mingw32\" -m32 -c -o tmkScan.o tmkScan.c gcc -Wall -g -DTARGETOS=\"mingw32\" -m32 -c -o tmkScSema.o tmkScSema.c gcc -Wall -g -DTARGETOS=\"mingw32\" -m32 -c -o tmkOpts.o tmkOpts.c gcc -Wall -g -DTARGETOS=\"mingw32\" -m32 -c -o tmkCommon.o tmkCommon.c ar r libtmk.a tmkPaSema.o tmkParse.o tmkErr.o tmkScan.o tmkScSema.o tmkOpts.o tmkCommon.o C:\tools\msys64\mingw32\bin\ar.exe: creating libtmk.a ranlib libtmk.a install -C -b Common.imp ../../lib/ansi-c make[1]: Leaving directory '/d/ToolMaker/src/tmk' cd imp; make all make[1]: Entering directory '/d/ToolMaker/src/imp' Rebuilding for mingw32 rm: cannot remove '*.o': No such file or directory rm: cannot remove '*.a': No such file or directory gcc -Wall -g -DTARGETOS=\"mingw32\" -m32 -c -o impParse.o impParse.c gcc -Wall -g -DTARGETOS=\"mingw32\" -m32 -c -o impPaSema.o impPaSema.c impPaSema.c: In function 'impPaSema': impPaSema.c:454:5: warning: 'errStr' may be used uninitialized [-Wmaybe-uninitialized] 454 | strcat(errStr, "INTEGER**IDENTIFIER"); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ : note: by argument 1 of type 'const char *' to '__builtin_strlen' declared here impPaSema.c:453:10: note: 'errStr' declared here 453 | char errStr[19]; | ^~~~~~ impPaSema.c:467:5: warning: 'errStr' may be used uninitialized [-Wmaybe-uninitialized] 467 | strcat(errStr, "INTEGER**IDENTIFIER"); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ : note: by argument 1 of type 'const char *' to '__builtin_strlen' declared here impPaSema.c:466:10: note: 'errStr' declared here 466 | char errStr[19]; | ^~~~~~ impPaSema.c:480:5: warning: 'errStr' may be used uninitialized [-Wmaybe-uninitialized] 480 | strcat(errStr, "INTEGER**IDENTIFIER"); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ : note: by argument 1 of type 'const char *' to '__builtin_strlen' declared here impPaSema.c:479:10: note: 'errStr' declared here 479 | char errStr[19]; | ^~~~~~ impPaSema.c:493:5: warning: 'errStr' may be used uninitialized [-Wmaybe-uninitialized] 493 | strcat(errStr, "INTEGER*IDENTIFIER"); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ : note: by argument 1 of type 'const char *' to '__builtin_strlen' declared here impPaSema.c:492:10: note: 'errStr' declared here 492 | char errStr[19]; | ^~~~~~ impPaSema.c:506:5: warning: 'errStr' may be used uninitialized [-Wmaybe-uninitialized] 506 | strcat(errStr, "INTEGER**IDENTIFIER"); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ : note: by argument 1 of type 'const char *' to '__builtin_strlen' declared here impPaSema.c:505:10: note: 'errStr' declared here 505 | char errStr[19]; | ^~~~~~ impPaSema.c:454:5: warning: '__builtin_memcpy' writing 20 bytes into a region of size 19 overflows the destination [-Wstringop-overflow=] 454 | strcat(errStr, "INTEGER**IDENTIFIER"); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ impPaSema.c:453:10: note: destination object 'errStr' of size 19 453 | char errStr[19]; | ^~~~~~ impPaSema.c:467:5: warning: '__builtin_memcpy' writing 20 bytes into a region of size 19 overflows the destination [-Wstringop-overflow=] 467 | strcat(errStr, "INTEGER**IDENTIFIER"); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ impPaSema.c:466:10: note: destination object 'errStr' of size 19 466 | char errStr[19]; | ^~~~~~ impPaSema.c:480:5: warning: '__builtin_memcpy' writing 20 bytes into a region of size 19 overflows the destination [-Wstringop-overflow=] 480 | strcat(errStr, "INTEGER**IDENTIFIER"); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ impPaSema.c:479:10: note: destination object 'errStr' of size 19 479 | char errStr[19]; | ^~~~~~ impPaSema.c:506:5: warning: '__builtin_memcpy' writing 20 bytes into a region of size 19 overflows the destination [-Wstringop-overflow=] 506 | strcat(errStr, "INTEGER**IDENTIFIER"); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ impPaSema.c:505:10: note: destination object 'errStr' of size 19 505 | char errStr[19]; | ^~~~~~ gcc -Wall -g -DTARGETOS=\"mingw32\" -m32 -c -o impErr.o impErr.c gcc -Wall -g -DTARGETOS=\"mingw32\" -m32 -c -o impList.o impList.c gcc -Wall -g -DTARGETOS=\"mingw32\" -m32 -c -o impScan.o impScan.c gcc -Wall -g -DTARGETOS=\"mingw32\" -m32 -c -o impScSema.o impScSema.c gcc -Wall -g -DTARGETOS=\"mingw32\" -m32 -c -o ast.o ast.c gcc -Wall -g -DTARGETOS=\"mingw32\" -m32 -c -o name.o name.c gcc -Wall -g -DTARGETOS=\"mingw32\" -m32 -c -o impMacro.o impMacro.c gcc -Wall -g -DTARGETOS=\"mingw32\" -m32 -c -o timing.o timing.c gcc -Wall -g -DTARGETOS=\"mingw32\" -m32 -c -o version.o version.c ar rv imp.a impParse.o impPaSema.o impErr.o impList.o impScan.o impScSema.o ast.o name.o impMacro.o timing.o version.o a - impParse.o a - impPaSema.o a - impErr.o a - impList.o a - impScan.o a - impScSema.o a - ast.o a - name.o a - impMacro.o a - timing.o a - version.o C:\tools\msys64\mingw32\bin\ar.exe: creating imp.a ranlib imp.a gcc -Wall -g -DTARGETOS=\"mingw32\" -m32 -c -o imp.o imp.c gcc -o imp -Wall -g -DTARGETOS=\"mingw32\" -m32 imp.o imp.a mkdir -p ../../bin install imp ../../bin/ make[1]: Leaving directory '/d/ToolMaker/src/imp' cd lmk; make all make[1]: Entering directory '/d/ToolMaker/src/lmk' Rebuilding for mingw32 rm: cannot remove '*.o': No such file or directory rm: cannot remove '*.a': No such file or directory gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o lmkPaSema.o lmkPaSema.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o lmkParse.o lmkParse.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o lmkErr.o lmkErr.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o lmkScan.o lmkScan.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o lmkScSema.o lmkScSema.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o lmkList.o lmkList.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o lmkTab.o lmkTab.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o lmk.o lmk.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o version.o version.c gcc -o lmk -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 lmkPaSema.o lmkParse.o lmkErr.o lmkScan.o lmkScSema.o lmkList.o lmkTab.o lmk.o version.o ../tmk/libtmk.a ../imp/imp.a install lmk ../../bin/ install -C -b List.imp ../../lib/ansi-c/ make[1]: Leaving directory '/d/ToolMaker/src/lmk' cd smk; make all make[1]: Entering directory '/d/ToolMaker/src/smk' Rebuilding for mingw32 rm: cannot remove '*.o': No such file or directory rm: cannot remove '*.a': No such file or directory gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o smkPaSema.o smkPaSema.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o smkScSema.o smkScSema.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o smkParse.o smkParse.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o smkErr.o smkErr.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o smkScan.o smkScan.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o smkList.o smkList.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o smk.o smk.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o token.o token.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o scanner.o scanner.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o vocabulary.o vocabulary.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o definition.o definition.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o rule.o rule.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o ast.o ast.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o lmprintf.o lmprintf.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o name.o name.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o char.o char.c char.c: In function 'charClass': char.c:180:5: warning: this 'else' clause does not guard... [-Wmisleading-indentation] 180 | else | ^~~~ char.c:182:7: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'else' 182 | if(*string==']') break; | ^~ gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o nfa.o nfa.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o lookahead.o lookahead.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o dfa.o dfa.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o map.o map.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o pack.o pack.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o write.o write.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o time.o time.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o action.o action.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o set.o set.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o screen.o screen.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o smalloc.o smalloc.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o nfas.o nfas.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o common.o common.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o version.o version.c gcc -o smk -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 smkPaSema.o smkScSema.o smkParse.o smkErr.o smkScan.o smkList.o smk.o token.o scanner.o vocabulary.o definition.o rule.o ast.o lmprintf.o name.o char.o nfa.o lookahead.o dfa.o map.o pack.o write.o time.o action.o set.o screen.o smalloc.o nfas.o common.o version.o ../tmk/libtmk.a ../imp/imp.a install smk ../../bin/ install -C -b Scan.imp ../../lib/ansi-c make[1]: Leaving directory '/d/ToolMaker/src/smk' cd pmk; make all make[1]: Entering directory '/d/ToolMaker/src/pmk' Rebuilding for mingw32 rm: cannot remove '*.o': No such file or directory rm: cannot remove '*.a': No such file or directory gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o pack.o pack.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o pmkErr.o pmkErr.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o pmkList.o pmkList.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o pmkParse.o pmkParse.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o pmkScan.o pmkScan.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o pmkPaSema.o pmkPaSema.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o pmkScSema.o pmkScSema.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o pmkSymTab.o pmkSymTab.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o pmkTab.o pmkTab.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o pwDbg.o pwDbg.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o pwGe.o pwGe.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o pwLog.o pwLog.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o pwPack.o pwPack.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o pwSymSet.o pwSymSet.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o pwsGrm.o pwsGrm.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o pwsOrd.o pwsOrd.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o pwsQueue.o pwsQueue.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o pwsWrit.o pwsWrit.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o set.o set.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o timing.o timing.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o pmk.o pmk.c gcc -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 -c -o version.o version.c gcc -o pmk -Wall -g -I../tmk -I../imp -DTARGETOS=\"mingw32\" -m32 pack.o pmkErr.o pmkList.o pmkParse.o pmkScan.o pmkPaSema.o pmkScSema.o pmkSymTab.o pmkTab.o pwDbg.o pwGe.o pwLog.o pwPack.o pwSymSet.o pwsGrm.o pwsOrd.o pwsQueue.o pwsWrit.o set.o timing.o pmk.o version.o ../tmk/libtmk.a ../imp/imp.a C:/tools/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld.exe: pmkParse.o:pmkParse.c:(.bss+0x0): multiple definition of `inFiles'; pmkErr.o:pmkErr.c:(.bss+0x0): first defined here C:/tools/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld.exe: pmkParse.o:pmkParse.c:(.bss+0xc): multiple definition of `code_spec'; pmkErr.o:pmkErr.c:(.bss+0xc): first defined here C:/tools/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld.exe: pmkScan.o:pmkScan.c:(.bss+0x0): multiple definition of `inFiles'; pmkErr.o:pmkErr.c:(.bss+0x0): first defined here C:/tools/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld.exe: pmkScan.o:pmkScan.c:(.bss+0xc): multiple definition of `code_spec'; pmkErr.o:pmkErr.c:(.bss+0xc): first defined here C:/tools/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld.exe: pmkPaSema.o:pmkPaSema.c:(.bss+0x0): multiple definition of `inFiles'; pmkErr.o:pmkErr.c:(.bss+0x0): first defined here C:/tools/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld.exe: pmkPaSema.o:pmkPaSema.c:(.bss+0xc): multiple definition of `code_spec'; pmkErr.o:pmkErr.c:(.bss+0xc): first defined here C:/tools/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld.exe: pmkScSema.o:pmkScSema.c:(.bss+0x0): multiple definition of `inFiles'; pmkErr.o:pmkErr.c:(.bss+0x0): first defined here C:/tools/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld.exe: pmkScSema.o:pmkScSema.c:(.bss+0xc): multiple definition of `code_spec'; pmkErr.o:pmkErr.c:(.bss+0xc): first defined here C:/tools/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld.exe: pmkSymTab.o:pmkSymTab.c:(.bss+0x0): multiple definition of `inFiles'; pmkErr.o:pmkErr.c:(.bss+0x0): first defined here C:/tools/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld.exe: pmkTab.o:pmkTab.c:(.bss+0x0): multiple definition of `inFiles'; pmkErr.o:pmkErr.c:(.bss+0x0): first defined here C:/tools/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld.exe: pmkTab.o:pmkTab.c:(.bss+0xc): multiple definition of `code_spec'; pmkErr.o:pmkErr.c:(.bss+0xc): first defined here C:/tools/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld.exe: pwGe.o:pwGe.c:(.bss+0x0): multiple definition of `inFiles'; pmkErr.o:pmkErr.c:(.bss+0x0): first defined here C:/tools/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld.exe: pwLog.o:pwLog.c:(.bss+0x0): multiple definition of `inFiles'; pmkErr.o:pmkErr.c:(.bss+0x0): first defined here C:/tools/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld.exe: pwLog.o:pwLog.c:(.bss+0xc): multiple definition of `code_spec'; pmkErr.o:pmkErr.c:(.bss+0xc): first defined here C:/tools/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld.exe: pwPack.o:pwPack.c:(.bss+0x0): multiple definition of `inFiles'; pmkErr.o:pmkErr.c:(.bss+0x0): first defined here C:/tools/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld.exe: pwSymSet.o:pwSymSet.c:(.bss+0x0): multiple definition of `inFiles'; pmkErr.o:pmkErr.c:(.bss+0x0): first defined here C:/tools/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld.exe: pwsGrm.o:pwsGrm.c:(.bss+0x0): multiple definition of `inFiles'; pmkErr.o:pmkErr.c:(.bss+0x0): first defined here C:/tools/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld.exe: pwsGrm.o:pwsGrm.c:(.bss+0xc): multiple definition of `code_spec'; pmkErr.o:pmkErr.c:(.bss+0xc): first defined here C:/tools/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld.exe: pwsOrd.o:pwsOrd.c:(.bss+0x0): multiple definition of `inFiles'; pmkErr.o:pmkErr.c:(.bss+0x0): first defined here C:/tools/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld.exe: pwsQueue.o:pwsQueue.c:(.bss+0x0): multiple definition of `inFiles'; pmkErr.o:pmkErr.c:(.bss+0x0): first defined here C:/tools/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld.exe: pwsWrit.o:pwsWrit.c:(.bss+0x0): multiple definition of `inFiles'; pmkErr.o:pmkErr.c:(.bss+0x0): first defined here C:/tools/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld.exe: pmk.o:pmk.c:(.bss+0x0): multiple definition of `inFiles'; pmkErr.o:pmkErr.c:(.bss+0x0): first defined here collect2.exe: error: ld returned 1 exit status make[1]: *** [Makefile:60: mingw32] Error 1 make[1]: Leaving directory '/d/ToolMaker/src/pmk' make: *** [Makefile:8: all] Error 2 ```

Building with LLVM/Clang?

Do you think that the project might build using the Clang compiler? It seems that the LLVM package contains various tools that allow code analysis to compile C project under Windows without all the cross-compatibility problems, which might allow to compile directly under Windows — but I'm not sure how this works and whether it currently handles any project or only certain features.

I've installed the LLVM package because various Rust projects need it to translate C sources to Rust (e.g. headers, or even transpiling entire sources). From what I've read, Clang has developed into an excellent compiler and it's currently comparable to GCC in terms of quality results.

If there's a chance that the project might build under Win OS using Clang (and other LLVM tools), without the need of the POSIX emulation layer of CygWin/MSYS2, then I think it's worth investing some energy in creating a build script for it.

More Info on Project Binaries

If you could provide me with some info regarding the various binary tools generated by the project it could help me out trying to provide alternative build scripts for Windows 10 (MSYS2, or Clang/LLVM).

Having a README file in each src/ folder, describing the tool, etc., would be useful.

[thoni56]

I'm moving this to discussions also, as it will probably be more of a conversation. Although ultimately, having binaries would be the wanted "fix".

I will also add info here in a piecemeal fashion.

First piece is that it some part of the suite requires 32-bit compilation, probably smk/ScannerMaker (the lexer generator). That is (has been) possible on some platforms, but as I knew how to do it on Cygwin I might have mentioned that as the "platform of choice". But I also found out how to do that on Linux (using multilib and/or mingw32).

For Msys2 I think it worked at some point using a Msys Mingw32 console, because I think it used to default to Mingw32 tool suite. (And the Mys2 Mingw64 console defaulted to gcc=x86_64 toolchain.) Also see #1, for a historic data point for this.

It's been a while since I used Msys2, things changes from under you ;-) and it seems that has changed (IIRC) so that now, what ever console, you need to explicitly select toolchain. So your best bet is probably to try

make CC=i686-w64-mingw32-gcc

(The Makefiles are using gcc -m32 which should also use a 32-bit toolchain, but that fails for me in linking because gcc seems to try the wrong run-time libraries to link with, mostly guessing here, haven't looked deeper at this)

But I ran in a problem with multiple declaration of a variable in pmk/ParserMaker (the parser generator tool). This is probably caused by declarations which where completely legal in gcc3/c99 and resolved to the same symbol is now interpreted as two different symbols, which clashes in the linkage step. I have not dived deeper into this either, yet.

BTW, collect is a GCC step in the linking process.

[tajmone]

So your best bet is probably to try

make CC=i686-w64-mingw32-gcc

I've tried that, but the build fails with the same error as before (I was already using MingW 32-bit, since that's the only version available in the MinGw-32 shell).

It's been a while since I used Msys2, things changes from under you ;-) and it seems that has changed (IIRC) so that now, what ever console, you need to explicitly select toolchain.

As far as I remember, now with MSYS2 the MinGW-64 shell only builds 64-bit apps, and the MinGW-32 shell only 32-bit apps, so their toolchains are set and selected accordingly. I had to explicitly install the 32-bit toolchain in the 32-bit shell, though, since only the 64-bit toolchain is natively provided. Then there's the MSYS2 shell, where all packages are updated (for both architectures) along with MSYS2 updates, as well as settings. Although a bit reductive, this should be the general scope of the three different shells.

But I ran in a problem with multiple declaration of a variable in pmk/ParserMaker (the parser generator tool). This is probably caused by declarations which where completely legal in gcc3/c99 and resolved to the same symbol is now interpreted as two different symbols, which clashes in the linkage step. I have not dived deeper into this either, yet.

Yes, I also get the impression that this is the error which makes the build fail. I'll try and look at all the warnings, one by one, maybe this can be fixed easily, even via compiler/linker options.

This is what I dislike of C, all the compiler issues. I don't mind the language itself, it's quite elegant, flexible and clear. But given all the problems with C's "undefined behaviours" (which have been the root cause of 90% of the vulnerability issues in software), and the endless compiler quirks (even on a same architecture and OS), I find that these problems ultimately undermine C's claimed portability (which sounds more of a myth than a reality). It's a language you can learn in a year, but will take you 10 years to learn all the compiler and OS quirks, which isn't really appealing.

I fail to understand the whole point of having standards (ANSI/C89, C99, etc.) if then a same source file abiding to that standard won't compile on a newer version of a compiler using the c99 option. Aren't these options supposed to enforce the standards?

And of course, under Windows things get even worst, since the MS compilers only fully supports C89, and a distorted version of C99 (freely mixing features). I guess that the WinAPI being still affected by the C89 standard doesn't help either.

[thoni56]

I fail to understand the whole point of having standards (ANSI/C89, C99, etc.) if then a same source file abiding to that standard won't compile on a newer version of a compiler using the c99 option. Aren't these options supposed to enforce the standards?

Well, it's no worse than Ruby 1.8, 1.9, 2.x, 3.x or PHP versions. If we would enforce c89 and stick with that I think we would be ok, but often as in this case we tend tp not use the standards option for the compilers in these types of projects.which means upgrading a compiler might mean the default is some newer standard.

Also glueing a whole project to an ancient version gives some advantages, but also some disadvantages. It's like posponing the upgrades of your computer, it feels good now, but comes with worse pain later on.

[thoni56]

From reading up on the fairly un-formatted log I see that the actual problem you had was actually the same multiply defined symbols in pmk. Sorry for the confusion. I don't know why compilation for me didn't work as it should, I have to investigate that when I get more time.

At some point in the "near future" I'll look at the pmk-compilation linking problem and see if I can fix it.

As of this moment I have no working binaries for "Windows" (Cygwin/Msys2).

[thoni56]

Do you think that the project might build using the Clang compiler? It seems that the LLVM package contains various tools that allow code analysis to compile C project under Windows without all the cross-compatibility problems, which might allow to compile directly under Windows — but I'm not sure how this works and whether it currently handles any project or only certain features.

As the root problem is the 32-bit dependency I think clang will not offer advantages at this time.

Unless it does not interpret the declarations in pmk referenced earlier in the same way as gcc, and there is a 32-bit output option. That might be worth exploring. But as always opening a new route of exploration for one problem often leads to a load of other things that work differently.

But I agree about clang as being a strong contender. And although the Apple Clang compiler on my Mac compiles to a universal binary (M1+x86_64) it is about 30% faster than the Homebrew gcc which only does x86_64.

[thoni56]

There was obviously something fishy with my Msys2 installation, because after a restart of my computer, it behaved as expected and I'm back with only the pmk-issue. I'll investigate.

[thoni56]

Commit 7ec2971 contains the fix in pmk that restores compilation on Msys2.

It was as I suspected gcc (11) that had decided to finally enforce the interpretation of the extern keyword, or rather the lack of it, that probably was the intention all along, but had previously allowed another interpretation.

[thoni56]

It seems to be a problem with .gitattributes, yes. I will simply remove it as indications in the wild is that it mostly creates these kinds of problems. If we, for now, stay in pure Unix-like environments that should not be a problem.

[tajmone]

A Known (and Solved) Git for Windows Bug

In Cygwin it often seems to be a difference in the protection bits, which that git reports.

Arrrg! Then it's due to a well known bug in Git for Windows, which has plagued many users for a long time, until it was recently fixed (a few months ago).
Probably CygWin and MSYS2 are still using an older version of Git for Windows (of components taken from it), so the bug is still there until it's updated.

You can find the details of the bug git-for-windows/git#694. Yes, it's related to the file permissions bits, as well as to EOLs (since these are stored in bits to, to track normalization at checkout).

Stalling Git!

If we, for now, stay in pure Unix-like environments that should not be a problem.

Not necessarily, I'm afraid. Under Win OS the bug triggers when there are files changes affecting only the permission or EOL bits, and can lead to a stall where you can't switch branch because Git sees changes in the work area, but then when you try to stage them they disappear (since contents are unchanged), but when trying to checkout another branch, rebasing or merging then Git reports it can't be done due to uncommitted changes.

Solution: Stashing

If/when this happens (usually when there are file permissions or EOL differences in a same file on different branches, but maybe even if a filename is same-named with different letter casing on different branches) I discovered you can work around it by simply stashing (see my comments on the Bug report).

So, until the bug fix is integrated into CygWin/MSYS2, we might need to keep an eye open when using git under their shell, for the bug could show up any time, and it's quite disrupting. The bug won't show on the same repository under the Git installation on Window, but this doesn't help fixing the problems in the MinGW shell, since there's no problem to fix really — so stashing in MinGW's Git instance is the only way out of the stall.

[thoni56]

Stashing did definitely not work for me, and thus prevented me to pull, switch branch, etc. like you mentioned. Only solution was to remove the whole repo, and even then the diff turned up on directly when I cloned.

I think this might be related to the bug you describe, but interaction with .gitattribute forcing some particular setting and normalizing seems to be making this more complicated.

As another data point, the particular .bat file is not actually a batch script but testdata, so the lineending is irrelevant. I think the initial git import made a lot of files have weird line-endings. I suggest that we just handle those problems if they actually becomes a problem.

Removing .gitattributes from the repo definitely solved the problem for me. So let's leave it at that until a real problem makes us revisit the eternal "line-ending enima". (Sorry, that was intended to be "enigma" ;-)

[tajmone]

As another data point, the particular .bat file is not actually a batch script but testdata, so the lineending is irrelevant. I think the initial git import made a lot of files have weird line-endings. I suggest that we just handle those problems if they actually becomes a problem.

Then probably the fix would be to explicitly declare it as a binary (-text) file in .gitattributes:

or, if all .bat files in the repo are test data:

**/*.bat binary

This should stop Git from trying to normalize EOLs, but might still check file permissions bits though. I'm not sure if this has backward propagating effects, or if it requires rebuilding the index, etc. But it might work.

In any case, it would be a good addition, since otherwise .bat files are considered DOS/CMD batch scripts.

I can't believe that today developers are still wasting so many hours all around the world to deal with line-ending problems that we're inheriting from the Jurassic era of computing — unfortunately, it seems that no matter how many evolutionary asteroids you throw at the computer world, dinosaurs never go into extinction!

[thoni56]

All tools now (again, still) compile cleanly and run all tests without any issues on Linux (gcc 9 and gcc 10 provided that you have corresponding multilib installed). I will not dabble with Msys or any other Windows based environment for a while. My priority viz-a-viz this project will be to figure out, and hopefully fix, the dependency on 32-bit compilation.

As Linux, and sometimes Darwin, is a much friendlier environment when it comes to lineendings I will focus on making it work there first. As WSL is readily available on almost any Windows machine the Alan project will not be blocked by not having ToolMaker on Msys2, I've taken this decision for now.

A little refresher, like the one you prompted ;-) made me remember that line-ending is an even bigger problem in ToolMaker since it uses a macroprocessor (IMP) and the lineended-ness of its input and skeleton files need to be catered for. This is radically easier if all files have simple, consistent, lineending.

I've normalized lineendings for all files. Having reliably and consistently running and passing tests will be key to fixing 32/64-bit issues, and as 32-bit is becoming more obsolete this is more important to fix.