User forums > Help

Stripping debug info from output tree

<< < (3/4) > >>

wtfisgoingoff:

--- Quote from: everSome on March 07, 2025, 12:17:14 pm ---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.

--- End quote ---
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:

--- Quote from: everSome on March 10, 2025, 04:09:46 am ---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.

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page