Hello list, my 1st issue here.
I'm now having a big issue with 'sh.exe' used by
*any* GNU-make program in a link-macro (or simple rule)
where 'stdout' gets redirect like this:
LDFLAGS = -nologo -debug -incremental:no -verbose
define link_EXE
@echo -e "\e[1;32mLinking $(1)\e[0m"
link.exe $(LDFLAGS) -out:$(strip $(1)) $(2) > link.tmp
@cat link.tmp >> $(1:.exe=.map)
endef
Using Microsoft's 'link.exe' or clang-cl's 'lld-link.exe'
does not matter. And it's not specific to Qt. But the error-
level gets lost when I intentionally remove a needed .lib-file
in any type of link-command. 'Qt6Widgets.lib' in the case below.
Issuing gnu-make to link a simple Qt6 program and with
'--debug=j' shows (edited for clarity):
Linking qtdiag.exe
Reaping winning child 0000019a69da3fb0 PID
link.exe -nologo -debug -incremental:no -verbose -out:qtdiag.exe
objects/main.obj objects/qtdiag.obj
f:\gv\Qt\6.5.1\msvc2019_64/lib/Qt6Core.lib
f:\gv\Qt\6.5.1\msvc2019_64/lib/Qt6Gui.lib
f:\gv\Qt\6.5.1\msvc2019_64/lib/Qt6Network.lib
f:\gv\Qt\6.5.1\msvc2019_64/lib/Qt6OpenGL.lib > link.tmp
CreateProcess(f:\CygWin64\bin\sh.exe,f:/CygWin64/bin/sh.exe -c
"link.exe -nologo -debug -incremental:no -verbose -out:qtdiag.exe
objects/main.obj objects/qtdiag.obj
f:\gv\Qt\6.5.1\msvc2019_64/lib/Qt6Core.lib
f:\gv\Qt\6.5.1\msvc2019_64/lib/Qt6Gui.lib
f:\gv\Qt\6.5.1\msvc2019_64/lib/Qt6Network.lib
f:\gv\Qt\6.5.1\msvc2019_64/lib/Qt6OpenGL.lib > link.tmp",...)
Live child 0000024430223280 (qtdiag.exe) PID 2491888511248
Reaping winning child 0000024430223280 PID 2491888511248
CreateProcess(f:\CygWin64\bin\sh.exe,f:/CygWin64/bin/sh.exe -c "cat link.tmp >>
qtdiag.map",...)
Live child 0000024430223280 (qtdiag.exe) PID 2491888513984
Reaping winning child 0000024430223280 PID 2491888513984
CreateProcess(f:\CygWin64\bin\echo.exe,echo,...)
Live child 0000024430223280 (qtdiag.exe) PID 2491888511536
Reaping winning child 0000024430223280 PID 2491888511536
Removing child 0000024430223280 PID 2491888511536 from chain.
Now 'link.tmp' contains:
qtdiag.obj : error LNK2019: unresolved external symbol
"__declspec(dllimport) public: static class QList<class QString> __cdecl
QStyleFactory::keys(void)"
qtdiag.exe : fatal error LNK1120: 1 unresolved externals
since I intentionally removed 'Qt6Widgets.lib'. GNU-make doesn't
stop since 'sh.exe' seems to have reset the exit-code somehow.
But defining my 'link_EXE' macro w/o a '> link.tmp' works fine:
LDFLAGS = -nologo -debug -incremental:no
define link_EXE
@echo -e "\e[1;32mLinking $(1)\e[0m"
link.exe $(LDFLAGS) -out:$(strip $(1)) $(2)
@cat link.tmp >> $(1:.exe=.map)
endef
Resulting in this to 'stdout':
qtdiag.obj : error LNK2019: unresolved external symbol
"__declspec(dllimport) public: static class QList<class QString> __cdecl
QStyleFactory::keys(void)"
...
qtdiag.exe : fatal error LNK1120: 1 unresolved externals
--------------
But I'd rather prefer '-verbose' and redirection to see
the details of 'link.exe'.
So what in Cygwin's 'sh.exe' could cause the exit-code 1120 from
'link.exe' (or others) to get lost like this? The 'link' exit-codes
are listed here:
https://learn.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-errors-and-warnings?view=msvc-170 (all
>= 1000 if that matters).
I have tried several gnu-make programs to figure out this
"redirection bug". They all behave the same; exit-code from
'link.exe' gets ignored. Hence it's not a GNU-make issue AFAICS.
I also ensured there is no Cygwin/MSys 'link.exe' program
in the PATH ahead of MSVC's 'link.exe' and I've deleted
f:\Cygwin64\bin\link.exe
I suspect perhaps all this started to happen after the huge
update of "Visual-Studio 17.10 Preview 1.0". cl/link version.
14.40.33521:
https://devblogs.microsoft.com/visualstudio/introducing-visual-studio-17-10-preview-1-is-here/
I fixed this by adding this 'Git-for-Windows' directory:
f:\ProgramFiler\Git-2\usr\bin
before 'f:\Cygwin64\bin' (thus letting GNU-make to use
'f:\ProgramFiler\Git-2\usr\bin\sh.exe' instead). But I'd
rather keep it simpler and use 'f:\Cygwin64\bin\sh.exe'.
And 'f:\Cygwin64\bin\sh --version' shows:
GNU bash, version 5.2.21(1)-release (x86_64-pc-cygwin)
...
So how can I hnt down this issue. Is there perhaps some env-var
in my shell that could cause this? Please advice.
--
--gv
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
