* 'sh.'exe' issue with redirection
[not found] <8d97486a-f68e-afb7-721b-883c60212559.ref@yahoo.no>
@ 2024-02-26 9:51 ` Gisle Vanem
0 siblings, 0 replies; only message in thread
From: Gisle Vanem @ 2024-02-26 9:51 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2024-02-26 9:51 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <8d97486a-f68e-afb7-721b-883c60212559.ref@yahoo.no>
2024-02-26 9:51 ` 'sh.'exe' issue with redirection Gisle Vanem
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).