Author Topic: [solved] What are the possible reasons those plugins are much larger?  (Read 2873 times)

Offline wtfisgoingoff

  • Multiple posting newcomer
  • *
  • Posts: 14
I built C::B by this guide https://wiki.codeblocks.org/index.php/Installing_Code::Blocks_from_source_on_Windows
Everything seems fine, C::B runs fine. But when I tried to send it to others, the compressed package is much larger than official nightly build. Then I found those plugins built by myself are much larger.(attached)So, what I might have wrongly done ?
« Last Edit: December 25, 2023, 05:39:25 pm by wtfisgoingoff »

Online stahta01

  • Lives here!
  • ****
  • Posts: 7591
    • My Best Post
The most likely is you are not striping the binaries right.

From an command prompt (cmd.exe) window run.
Code
where strip

If strip is not in the PATH you will get this.
Code
INFO: Could not find files for the given pattern(s).

Tim S.
« Last Edit: December 25, 2023, 04:58:32 pm by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline wtfisgoingoff

  • Multiple posting newcomer
  • *
  • Posts: 14
Thx a lot, problem solved. :)
I read a guide that says MSYS2/xxxx/bin should  not be in PATH. And I followed it.  So when I ran that update32_64.bat, strip was not in PATH.(BTW if I run update.bat in CLI  rather than double clicking it, I should have found this problem.)

Online stahta01

  • Lives here!
  • ****
  • Posts: 7591
    • My Best Post
Having sh.exe in the path while building wxWidgets will cause the build to fail.

Tim S.

Thx a lot, problem solved. :)
I read a guide that says MSYS2/xxxx/bin should  not be in PATH. And I followed it.  So when I ran that update32_64.bat, strip was not in PATH.(BTW if I run update.bat in CLI  rather than double clicking it, I should have found this problem.)
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline PB

  • Multiple posting newcomer
  • *
  • Posts: 57
Having sh.exe in the path while building wxWidgets will cause the build to fail.
This should be avoidable with a SHELL build parameter, e.g.
Quote
mingw32-make -f makefile.gcc SHARED=1 BUILD=release SHELL=cmd.exe

Online stahta01

  • Lives here!
  • ****
  • Posts: 7591
    • My Best Post
Having sh.exe in the path while building wxWidgets will cause the build to fail.
This should be avoidable with a SHELL build parameter, e.g.
Quote
mingw32-make -f makefile.gcc SHARED=1 BUILD=release SHELL=cmd.exe

CB requires monolithic build normally; and that fails most of the time when that option is used; I am guessing the command line is too long.
It has been over 3 years since I last tried it.

Tim S.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline PB

  • Multiple posting newcomer
  • *
  • Posts: 57
[CB requires monolithic build normally; and that fails most of the time when that option is used; I am guessing the command line is too long.

Just for the record, Windows allows a command line length of about 8 kB.

This should be more than enough to build wxWidgets in any reasonable configuration, monolithic or not; I mean when calling the mingw make.

AFAIK, wxWidgets internally uses response files to work around the command line length limit when compiling its files.