-
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"
-
Are you using powershell or cmd?
EDIT: Are you using MSYS?. If so, probably strip.exe expects '/' as path separator.
-
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
-
Copy and xcopy are system commands, strip is not and the MSYS version may expect '/'.
-
Didn't work
-
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.
-
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
-
Open a command window. And type below what does it return?
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.
-
Open a command window. And type below what does it return?
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
I forgot to mention that you'll have to uncomment three commands beginning at line 241:
REM %3 "%CB_OUTPUT_DIR%/*.exe"
REM %3 "%CB_OUTPUT_DIR%/*.dll"
REM %3 "%CB_OUTPUT_RESDIR_STRIP%/plugins/*.dll"
just remove the leading "REM " characters thereof as I do not want them stripped for my personal use.
-
I forgot to mention that as I've commented out stripping since don't want to do that, you'll have to uncomment the three strip commands around lines 241 to 243.
REM echo Stripping debug info from output tree
REM %3 "%CB_OUTPUT_DIR%/*.exe"
REM %3 "%CB_OUTPUT_DIR%/*.dll"
REM %3 "%CB_OUTPUT_RESDIR_STRIP%/plugins/*.dll"
Just remove the "REM "prefix threof.
-
I'm being rather forgetful about this stuff as I did it a year or two ago. You'll notice that at the bottom of the update32_64_MSYS2.sh file there is a reference to
update32_64_MSYS2.sh
You can just delete it, or I could post it if you'd find it useful. I've only used this in the UCRT64 and MINGW64 environments. What that python script does is examine the import tables of all .exe and .dll files in output32_64 in a repetative manner for references to MSYS2 .dll files and copies them into output32_64.