User forums > Help

Stripping debug info from output tree

<< < (2/4) > >>

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:

--- Quote from: stahta01 on March 03, 2025, 05:45:55 pm ---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.

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

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:

--- Quote from: stahta01 on March 04, 2025, 09:06:21 pm ---Open a command window. And type below what does it return?


--- Code: ---where strip
--- End code ---

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.

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page