#3587 Cygwin build fails

[Philipp Klaus Krause]

I tried to build sdcc from current trunk in Cygwin on Windows 10 (in a qemu VM on Debian GNU/Linux).

This fails when trying to build the libraries due to some preprocessor issue:

/home/test/sdcc-code/sdcc/bin/sdcc -I../../device/include -I../../device/include/mcs51 -mds390 --nostdinc --std-c2x -c _atof.c -o ds390/_atof.rel
C:/cygwin64/home/test/sdcc-code/sdcc/support/cpp/gcc/cpp.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory
                                                             at 1: warning 190: ISO C forbids an empty translation unit
subprocess error 32512
make[4]: *** [Makefile:728: ds390/_atof.rel] Error 1

[Philipp Klaus Krause]

Looking at the DLLs used:

$ ldd C:/cygwin64/home/test/sdcc-code/sdcc/support/cpp/gcc/cc1
        ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x7ffe36050000)
        KERNEL32.DLL => /cygdrive/c/Windows/System32/KERNEL32.DLL (0x7ffe34bd0000)
        KERNELBASE.dll => /cygdrive/c/Windows/System32/KERNELBASE.dll (0x7ffe337a0000)
        cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffe05610000)

$ ldd C:/cygwin64/home/test/sdcc-code/sdcc/support/cpp/gcc/cpp.exe
        ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x7ffe36050000)
        KERNEL32.DLL => /cygdrive/c/Windows/System32/KERNEL32.DLL (0x7ffe34bd0000)
        KERNELBASE.dll => /cygdrive/c/Windows/System32/KERNELBASE.dll (0x7ffe337a0000)
        cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffe05610000)

All are found. Maybe when cpp is called from sdcc, the PATH is lost, and they are no longer found.

[Felix]

In fact, bin/sdcpp replaces PATH. If on cygwin PATH is (wild guess) abused to locate shared libraries, I can imagine that (at least) cygwin1.dll can't be found because of that.

To test this, replace
export PATH=${abs_top_builddir}/support/cpp/gcc
by
export PATH=${abs_top_builddir}/support/cpp/gcc:$PATH
in bin/sdcpp (and bin/sdcpp.in).

Otherwise, it might help to know what the broken error message "[..] libraries: ?: cannot open [..]" is supposed to convey. strace?

[Philipp Klaus Krause]

Indeed that works. I now can compile. The Cygwin build still fails when linking though (I'll put that problem into a separate reply).

According to https://learn.microsoft.com/de-de/windows/win32/dlls/dynamic-link-library-search-order the following are searched in order when looking for DLLs:

• DLL Redirection.
• API sets.
• SxS manifest redirection.
• Loaded-module list.
• Known DLLs.
• Windows 11, version 21H2 (10.0; Build 22000), and later. The package dependency graph of the process. This is the application's package plus any dependencies specified as <packagedependency> in the <dependencies> section of the application's package manifest. Dependencies are searched in the order they appear in the manifest.</dependencies></packagedependency>
• The folder from which the application loaded.
• The system folder. Use the GetSystemDirectory function to retrieve the path of this folder.
• The 16-bit system folder. There's no function that obtains the path of this folder, but it is searched.
• The Windows folder. Use the GetWindowsDirectory function to get the path of this folder.
• The current folder.
• The directories that are listed in the PATH environment variable. This doesn't include the per-application path specified by the App Paths registry key. The App Paths key isn't used when computing the DLL search path.

[Philipp Klaus Krause]

Compilation works when changing PATH in sdcpp, as suggested by @felixs above.

Now the build fails when linking:

make[5]: Entering directory '/home/test/sdcc-code/sdcc/device/lib/ds390'
/home/test/sdcc-code/sdcc/bin/sdar -rcD ../build/ds390/libds390.lib tinibios.rel memcpyx.rel i2c390.rel rtc390.rel putchar.rel gptr_cmp.rel atomic_flag_test_and_set.rel atomic_flag_clear.rel
/home/test/sdcc-code/sdcc/bin/sdar: line 12: /home/test/sdcc-code/sdcc/support/sdbinutils/binutils/libs/sdar: No such file or directory
make[5]: *** [Makefile:44: ../build/ds390/libds390.lib] Error 127

I see the wrapper bin/sdar but there is no support/sdbinutils/binutils/libs/sdar. However, there are support/sdbinutils/binutils/sdar.exe and support/sdbinutils/binutils/.libs/sdar.exe.

[Felix]

There are two ways. Either we patch binutils removing the .exe nonsense, or we patch bin/*.in. I can see some cygwin related stub there, but it doesn't seem to do anything.

In the meantime, you could try and hardcode .exe there, check what else breaks on cygwin.

thanks
felix

[Felix]

The change needed in bin/sdar.in is as follows.

-bin=sdar
+EXEEXT=@EXEEXT@
+bin=sdar${EXEEXT}

This should work as long as configure and support/sdbinutils/configure agree on EXEEXT, which I think they do.

[Philipp Klaus Krause]

That still leaves a binutils/libs/sdar.exe vs binutils/.libs/sdar.exe problem.

P.S.: Commenting out the 3 lines following "non-cygwin" makes it work for me.

[Felix]

Fixed in [r14063]. still need to fix regression tests on cygwin...