Recent Posts

Pages: 1 2 3 [4] 5 6 7 8 9 10
31
great, very good answer which helped me fix klingeltonemp3 the problem
32
Using Code::Blocks / Re: Using doxygen
« Last post by stahta01 on December 01, 2020, 06:01:35 am »
33
Using Code::Blocks / Using doxygen
« Last post by newcoder007 on December 01, 2020, 02:29:52 am »
Is there a way to generate a documentation with doxygen in codeblocks?
34
Using Code::Blocks / Re: Issue creating DLL
« Last post by oBFusCATed on December 01, 2020, 01:58:02 am »
Edit: After searching real fast it it seems like just enabling static libgcc and static libstdc++ fixed the issue. Are there any other general settings that are usually good to have enabled?
You should first check what are the licensing requirements of the libraries you're using.
Generally GCC and its runtime are GPL licensed (with some exception clauses).
You should be pretty sure that you understand the license and the license allows you to do what you want to do.
35
Using Code::Blocks / Re: Issue creating DLL
« Last post by sodev on November 30, 2020, 11:17:57 pm »
Although you are on windows i wouldn't statically link the compiler runtime libraries, this might cause trouble. I would simply distribute them together with the application.
36
Development / Re: Single PCH file for building the CodeBlocks_wx31_64.cbp
« Last post by oBFusCATed on November 30, 2020, 09:25:04 pm »
BTW: Don't get me wrong. I'm not opposing the visibility related changes. They are good and important!
I just don't like PCHs and I think they are stupid and a waste of time. :)

Do you get improvement when loading C::B? It should improve load performance, because the dynamic library loader has less work to do when loading DLLs with smaller number of symbols. At least on linux this is pretty slow step.

I don't know if the windows toolchain supports the gc-sections linker option (you need to use -fdata-sections and -ffunction-sections for the compiler for this to work). This leads to smaller .exe and .dll files when using hidden visibility at least on linux. My knowledge about windows related stuff is quite limited these days. :)
37
Development / Re: Single PCH file for building the CodeBlocks_wx31_64.cbp
« Last post by oBFusCATed on November 30, 2020, 09:18:05 pm »
No this is not how you benchmark. Apply all changes in your branch, then try to measure PCH-on versus PCH-off.
Currently you're measuring noPCH+massive amount of symbols and PCH+smaller amount of symbols. The linking step in C::B is serial, so it has big effects on the overall time. Smaller number of symbols improves linking performance.
Also what happens if you just put only wx related includes in the PCH or you use the wxprec.h or whatever is called?

p.s. My build time on Linux, GCC 9.3.0, Amd Ryzen7 1700 (relatively slow CPU in 2020, it is slower than a mobile cpu produced by a fashion/fruit company) is:
1. 93 sec with PCH.
2. 123 sec without PCH.

So, you need to buy better CPU and/or switch to better compiler. GCC on windows is massively slow. So working to switch to something like clang would be a big improvement in both speed and compiler quality (GCC on windows is pretty bad compared to how it behaves on Linux). I've not use clang on windows, but I doubt it would be as bad as GCC is. On linux clang and GCC are comparable.

And I pay 60 seconds or more every time I edit a header which is in the PCH, super annoying.

p.p.s. The compilation is really slow if the compiler emits too many errors/warnings. If you're not error/warning free you'll get horrendous build times. This is something which needs to be investigated quite a bit.
p.p.p.s. The compilation is non-optimal (and it will get worse on newer non-fruit cpus), because it cannot schedule work from multiple projects. Linking is blocking progress :(. This is clearly visible when building any plugins. Someday I'll write a ninja-build generator, but there are more important projects/problems first.
p.p.p.p.s. The switch from wx28 to wx30 made compilation visibly slower. I've not debugged why, but my guess is the use of basic_string as the base for wxString.
38
Using Code::Blocks / Re: Issue creating DLL
« Last post by hopslam on November 30, 2020, 08:33:11 pm »
Ok so that worked a lot better. When using the test DLL, it gives says it cannot find libgcc_s_dw2-1.dll.

Edit: After searching real fast it it seems like just enabling static libgcc and static libstdc++ fixed the issue. Are there any other general settings that are usually good to have enabled?
39
Using Code::Blocks / Re: Issue creating DLL
« Last post by sodev on November 30, 2020, 06:30:57 pm »
Dependency Walker is kind of broken since Windows 7, it has lots of trouble with this new API related stuff. A better alternative is to use https://github.com/lucasg/Dependencies, it can resolve these dependencies properly.
40
Using Code::Blocks / Re: Issue creating DLL
« Last post by hopslam on November 30, 2020, 05:58:18 pm »
Post the full rebuild log.
Can you use depends.exe to inspect your dll?
Do you see the function?
My guess is that C++ name mangling is causing you the trouble.

Sorry I somehow missed the reply to the post.

The full build log is:

-------------- Build: Debug in test (compiler: GNU GCC Compiler)---------------

mingw32-g++.exe -Wall -DBUILD_DLL -g  -c "C:\Users\Owner\Desktop\Header Test\test\main.cpp" -o obj\Debug\main.o
mingw32-g++.exe -shared -Wl,--output-def=bin\Debug\libtest.def -Wl,--out-implib=bin\Debug\libtest.a -Wl,--dll  obj\Debug\main.o  -o bin\Debug\test.dll  -luser32
Output file is bin\Debug\test.dll with size 35.87 KB
Process terminated with status 0 (0 minute(s), 0 second(s))
0 error(s), 0 warning(s) (0 minute(s), 0 second(s))

When I try to use dependency walker I get an error: At least one required implicit or forwarded dependency was not found, and a warning: At least one delay-load dependency module was not found. The problem with that is every API-MS_WIN_CORE dll gives an error.
Pages: 1 2 3 [4] 5 6 7 8 9 10