Stripping debug info from output tree

[wtfisgoingoff]

Windows 11 

I got those msg  after running update32_64.bat (@call update.bat 32_64)
strip: 'output32_64\*.exe': No such file 
strip: 'output32_64\*.dll': No such file 
strip: 'output32_64\share\CodeBlocks\plugins\*.dll': No such file   

I added those cmd into that bat file  dir "%CB_OUTPUT_DIR%\*.exe"   echo CB_OUTPUT_DIR=%CB_OUTPUT_DIR%   
CB_OUTPUT_DIR outputed correctly    and  all *.exe were listed   

chatgpt suggested this cmd and it worked 

for %%f in ("%CB_OUTPUT_DIR%\*.exe") do strip "%%f"
for %%f in ("%CB_OUTPUT_DIR%\*.dll") do strip "%%f"
for %%f in ("%CB_OUTPUT_RESDIR%\plugins\*.dll") do strip "%%f" 
 
So what might be wrong here? Original strip cmds in update.bat are
strip "%CB_OUTPUT_DIR%\*.exe" 
strip "%CB_OUTPUT_DIR%\*.dll"
strip "%CB_OUTPUT_RESDIR%\plugins\*.dll"

[Miguel Gimenez]

Are you using powershell or cmd?

EDIT: Are you using MSYS?. If so, probably strip.exe expects '/' as path separator.

[wtfisgoingoff]

powershell . I tried CMD and msys2 shell didn't work neither.

I installed strip by MSYS2 indeed.

'/' as path separator didn't work .

The above part of  stripping is

copy "%CB_DEVEL_DIR%\cb_console_runner.exe" "%CB_OUTPUT_DIR%\cb_console_runner.exe" > nul

echo Transferring executable files from devel to output folder
xcopy /D /y "%CB_DEVEL_DIR%\*.exe" "%CB_OUTPUT_DIR%" > nul
echo Transferring DLL files from devel to output folder
xcopy /D /y "%CB_DEVEL_DIR%\*.dll" "%CB_OUTPUT_DIR%" > nul
echo Transferring LIB files from devel to output folder
xcopy /D /y "%CB_DEVEL_DIR%\*.a" "%CB_OUTPUT_DIR%" > nul
echo Transferring DLL plugin files from devel to output folder
xcopy /D /y "%CB_DEVEL_RESDIR%\plugins\*.dll" "%CB_OUTPUT_RESDIR%\plugins" > nul

Transferring worked. So   '\' path separator should work in powershell ,cmd msys2 shell

[Miguel Gimenez]

Copy and xcopy are system commands, strip is not and the MSYS version may expect '/'.

[wtfisgoingoff]

Didn't work

[stahta01]

strip is likely part of the GCC compiler tool chain.
You likely need to add the path to that to the path of the command window you are using.

Edit: The above assumes not using MSys2

Tim S.

[wtfisgoingoff]

strip is likely part of the GCC compiler tool chain.
You likely need to add the path to that to the path of the command window you are using.

Edit: The above assumes not using MSys2

Tim S.

Can you be more specific about this "add the path to that to the path of the command window you are using" .Thx

[stahta01]

Open a command window. And type below what does it return?

Code

where strip

If it fails to find strip then the problem is what I said it was; then, you can learn how to use windows on a windows support site or use google.

SET PATH command is not that hard it should be easy to find info on it.
If you do not know where you installed your compiler; I do not know the answer; you can check the CB toolchain setting and you need to add "bin" to that value.

Tim S.

[wtfisgoingoff]

Open a command window. And type below what does it return?

Code

where strip

If it fails to find strip then the problem is what I said it was; then, you can learn how to use windows on a windows support site or use google.

SET PATH command is not that hard it should be easy to find info on it.
If you do not know where you installed your compiler; I do not know the answer; you can check the CB toolchain setting and you need to add "bin" to that value.

Tim S.

strip is in PATH.Since no one's mentioned this problem and the relevant files in official Windows nightly build stripped.  So this update.bat must be working,right?
Thanks a lot. I will keep those for %%f in ("%CB_OUTPUT_DIR%*.exe") do strip "%%f"  for now.

[everSome]

Using an MSYS2 UCRT64 bash shell on my Windows 10 setup, I see that I have:

$ where strip
C:\msys64\ucrt64\bin\strip.exe
C:\msys64\usr\bin\strip.exe
$ pacman -Qo /ucrt64/bin/strip.exe
/ucrt64/bin/strip.exe is owned by mingw-w64-ucrt-x86_64-binutils 2.44-1
$ pacman -Qo /usr/bin/strip.exe
/usr/bin/strip.exe is owned by binutils 2.44-1

If you feed tentative shell commands through something like

$(TARGET_COMPILER_DIR)..\usr\bin\env MSYSTEM=UCRT64 CHERE_INVOKING=1 /usr/bin/bash -lc

you can let MSYS2 find the best version to use. In the above instance, it will use an /ucrt64/bin version if exists; otherwise it will look for what essentially is a Cygwin based version in /usr/bin. If that also fails, it will then look for a system version.

$ where xcopy
C:\Windows\System32\xcopy.exe

Unfortunately, syntax for Windows xcopy is:

xcopy <Source> [<Destination>] [/w] [/p] [/c] [/v] [/q] [/f] [/l] [/g] [/d [:MM-DD-YYYY]] [/u] [/i] [/s [/e]] [/t] [/k] [/r] [/h] [{/a | /m}] [/n] [/o] [/x] [/exclude:FileName1[+[FileName2]][+[FileName3]]] [{/y | /-y}] [/z] [/b] [/j] [/compress]

Note, all options come after file specifiers, not before! It's easy enough to make a version of things with the xcopy options flipped to after all file specifiers. These command files like never change.

[wtfisgoingoff]

Using an MSYS2 UCRT64 bash shell on my Windows 10 setup, I see that I have:

$ where strip
C:\msys64\ucrt64\bin\strip.exe
C:\msys64\usr\bin\strip.exe
$ pacman -Qo /ucrt64/bin/strip.exe
/ucrt64/bin/strip.exe is owned by mingw-w64-ucrt-x86_64-binutils 2.44-1
$ pacman -Qo /usr/bin/strip.exe
/usr/bin/strip.exe is owned by binutils 2.44-1

If you feed tentative shell commands through something like

$(TARGET_COMPILER_DIR)..\usr\bin\env MSYSTEM=UCRT64 CHERE_INVOKING=1 /usr/bin/bash -lc

you can let MSYS2 find the best version to use. In the above instance, it will use an /ucrt64/bin version if exists; otherwise it will look for what essentially is a Cygwin based version in /usr/bin. If that also fails, it will then look for a system version.

$ where xcopy
C:\Windows\System32\xcopy.exe

Unfortunately, syntax for Windows xcopy is:

xcopy <Source> [<Destination>] [/w] [/p] [/c] [/v] [/q] [/f] [/l] [/g] [/d [:MM-DD-YYYY]]   [/s [/e]] [/t] [/k] [/r] [/h] [{/a | /m}] [/n] [/o] [/x] [/exclude:FileName1[+[FileName2]][+[FileName3]]] [{/y | /-y}] [/z]  [/j] [/compress]

Note, all options come after file specifiers, not before! It's easy enough to make a version of things with the xcopy options flipped to after all file specifiers. These command files like never change.

I got 4 strip.exe
D:\MSYS2\usr\bin\strip.exe
D:\MSYS2\ucrt64\bin\strip.exe
D:\MSYS2\ucrt64\x86_64-w64-mingw32\bin\strip.exe
D:\MSYS2\usr\x86_64-pc-msys\bin\strip.exe
This one [D:\MSYS2\usr\x86_64-pc-msys\bin\strip.exe] didn't show those
'output32_64\*.exe': No such file   'output32_64\*.dll': No such file   'output32_64\share\CodeBlocks\plugins\*.dll': No such file   

But none stripping was done. Every file should be stripping  is  still very large.

[stahta01]

You cannot expect a batch file to work using an bash/sh shell! Change the shell or edit the batch file to work.

 Tim S.

[everSome]

FYI, under MSYS2's Porting documentation: You may need to use platform checks to switch between behaviour suited for MSYS2 and the default one. Some useful identifiers:

Identifier          Platform(s)                Usage
_WIN32              mingw, msvc                C code (#ifdef ...)
_WIN64              64-bit mingw, 64-bit msvc  C code (#ifdef ...)
__CYGWIN__          msys2, cygwin              C code (#ifdef ...)
__MSYS__            msys2                      C code (#ifdef ...)
x86_64-pc-msys2     64-bit msys2               Build scripts (if [ $host = '...' ])
i686-pc-msys2       32-bit msys2               Build scripts (if [ $host = '...' ])
x86_64-w64-mingw32  64-bit mingw               Build scripts (if [ $host = '...' ])
i686-w64-mingw32    32-bit mingw               Build scripts (if [ $host = '...' ])
cygwin              msys2                      Python (sys.platform)
win32               mingw                      Python (sys.platform)

from which I'd guess that the x86_64-w64-mingw32 versions are there to help cross compiling build scripts. Now my understanding of MSYS2 bash is that while it will handle .sh and .bash scripts, .bat scripts are just passed to Windows cmd.exe which can find xcopy, but does not have a native version of strip or zip. You could parameterize update.bat's usage of them and use it via a .sh script that through 2 additional arguments tells cmd.exe where to find them (which is what I've done), or you might copy C:\msys64\ucrt64\bin\strip.exe and C:\msys64\usr\bin\zip.exe into the C:\Windows\System32\ folder so that cmd.exe can naturally find them.

[stahta01]

FYI, under MSYS2's Porting documentation: You may need to use platform checks to switch between behaviour suited for MSYS2 and the default one. Some useful identifiers:

Identifier          Platform(s)                Usage
_WIN32              mingw, msvc                C code (#ifdef ...)
_WIN64              64-bit mingw, 64-bit msvc  C code (#ifdef ...)
__CYGWIN__          msys2, cygwin              C code (#ifdef ...)
__MSYS__            msys2                      C code (#ifdef ...)
x86_64-pc-msys2     64-bit msys2               Build scripts (if [ $host = '...' ])
i686-pc-msys2       32-bit msys2               Build scripts (if [ $host = '...' ])
x86_64-w64-mingw32  64-bit mingw               Build scripts (if [ $host = '...' ])
i686-w64-mingw32    32-bit mingw               Build scripts (if [ $host = '...' ])
cygwin              msys2                      Python (sys.platform)
win32               mingw                      Python (sys.platform)

from which I'd guess that the x86_64-w64-mingw32 versions are there to help cross compiling build scripts. Now my understanding of MSYS2 bash is that while it will handle .sh and .bash scripts, .bat scripts are just passed to Windows cmd.exe which can find xcopy, but does not have a native version of strip or zip. You could parameterize update.bat's usage of them and use it via a .sh script that through 2 additional arguments tells cmd.exe where to find them (which is what I've done), or you might copy C:\msys64\ucrt64\bin\strip.exe and C:\msys64\usr\bin\zip.exe into the C:\Windows\System32\ folder so that cmd.exe can naturally find them.

MSys2 does not pass .bat files to an cmd.exe command.

Tim S.

[everSome]

You are welcome to try what I use to see if that helps you. Note that I only have a standard MSYS2 environment on my Windows 10 machine. Place these scripts in the src directory where update.bat resides. From a UCRT64 shell execute

./update32_64_MSYS2.sh
or
./update31_64_MSYS2.sh

in stead of

update32_64.bat
or
update31_64.bat

as desired.
Note that attached version of update.bat is meant to replace the existing version thereof. Oops, I'm only allowed 2 attachments, and I had to tack on .txt name suffixes which you'll have to remove.