DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BA5CD3858CDB
Subject: 'sh.'exe' issue with redirection
To: cygwin AT cygwin DOT com
Message-ID: <8d97486a-f68e-afb7-721b-883c60212559@yahoo.no>
Date: Mon, 26 Feb 2024 10:51:00 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
Content-Language: en-GB
References: <8d97486a-f68e-afb7-721b-883c60212559 DOT ref AT yahoo DOT no>
From: Gisle Vanem via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Gisle Vanem <gvanem AT yahoo DOT no>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

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