User forums > Help
Newbie needing help with flags
BlueHazzard:
If you start your program from within codeblocks, codeblocks adds all library paths to the "PATH" environment variable, so your executable can find them. This does not mean they are linked statically. Codeblocks only makes sure your application can find the dll files.
If you run the application outside of codeblocks the PATH variable is not modified and so your application can not find the library and will report an error.
To compile wxWidgets from source as a static library:
1) download the MSW source from wxWidgets and extract it
2) Make sure your mingw compiler is in the PATH variable: open a cmd window and type
--- Code: ---gcc -v
--- End code ---
this should not report an error
3) With the command prompt cd to the wxWidgetsSourceCode/build/msw folder
4) run
--- Code: ---mignw32-make.exe -f makefile.gcc BUILD=debug SHARED=0 MONOLITHIC=1
--- End code ---
and
--- Code: ---mignw32-make.exe -f makefile.gcc BUILD=release SHARED=0 MONOLITHIC=1
--- End code ---
But why do you need static executables? Copy the dll in the same folder as your exe and ship them together...
--- Quote ---When i started C::B it always automaticly serched for a compiler and took the first one it found. This was my old MingW-setup with devC++. To avoid this, i've ziped the old MingW. So it can't be found anymore. But this is no real solution. Is there a possibility to stop this auto-search?
--- End quote ---
you probably have to set one default compiler with the default button... And make sure codeblocks can write the configuration fle: Are other settings saved?
stahta01:
FYI: Building a static monolithic wxWidgets library is not normal so it is more likely to have build issues.
And, monolithic builds often has issues because of too long of a command line length or out of memory on linking errors.
Tim S.
art-ganseforth:
At first: Thank you for offering time !!
--- Quote ---If you start your program from within codeblocks, codeblocks adds all library paths to the "PATH" environment variable, so your executable can find them.
--- End quote ---
Shouldn't this work with both programs and not only for the test-program?
--- Quote ---To compile wxWidgets from source as a static library:
--- End quote ---
I suck at the second step: "Make sure your mingw compiler is in the PATH variable". Where i can find the PATH variable and how the compiler should be "in" it (conderning this last point i have an idea which will maybe be anwered if i see the PATH variable).
--- Quote ---But why do you need static executables? Copy the dll in the same folder as your exe and ship them together...
--- End quote ---
I tried this. There were 4 wxWidgets-dll-requestes, then the program ended. So i collected the dlls and started the program again. Now there appered around 7-8 further requests for various openGL and system-dlls. At this point i realized, that my program probably needs lots more of dlls - next to lots of configuration-files, ogenGL-shaders, texture-images etc. So, it's already a bit messy and dlls won't make it better :/
...but it's also maybe just a preference - and that i would like to understand it.
--- Quote ---you probably have to set one default compiler with the default button... And make sure codeblocks can write the configuration fle: Are other settings saved?
--- End quote ---
Yes i have set a default compiler. It is in the C::B-folder on volume F:/.
Concerning the C::B-settings i'm also a bit confused. I use a portable version and i had several problems with different 'appearences' of C::B, depending on how i start ist. Only using CbLauncher.exe works. In other cases no compiler is found or i have problems with the UI-size on my UHD-display.
I looked a whilw for different config-files but i did not find.
--- Quote ---FYI: Building a static monolithic wxWidgets library is not normal so it is more likely to have build issues.
And, monolithic builds often has issues because of too long of a command line length or out of memory on linking errors.
--- End quote ---
I'll think about this, but in the end my program is not sooo huge. The last monolithic exe compiled with devC++ needs (containing symbols) ~11.000k; the other one (without symbols) ~1.900k. The program needs 14 source-files (7x .c and 7x .h).
I would be happy to know more about this: "Make sure your mingw compiler is in the PATH variable"...
Best,
Frank
BlueHazzard:
--- Quote ---I would be happy to know more about this: "Make sure your mingw compiler is in the PATH variable"...
--- End quote ---
https://en.wikipedia.org/wiki/PATH_(variable)
https://www.computerhope.com/issues/ch000549.htm (google 1 sek)
--- Quote ---Shouldn't this work with both programs and not only for the test-program?
--- End quote ---
I am confused... Didn't you say that both programs behave the same now, after you cleaned up everything? If you run them trough codeblocks both work and if you run them from explorer they do not work? If this is not so, please describe again step by step what does not work... The post is already to long to re read everything...
For example:
1) Compiler Prog1 with project file with Build->Build
--- Code: ---projectfilejadajada
--- End code ---
2) Run Prog1 with build->run
3) Get error message
--- Code: ---Error message jadajada
--- End code ---
4) Expected: Run without error message
1) Compiler Prog2 with project file with Build->Build
--- Code: ---projectfile2jadajada
--- End code ---
2) Run Prog2 with build->run
3) All works fine
4) Expected: Run without error message like for Prog1
ecc... Short sentences, broken up in a numbered list is the best format for me
--- Quote ---Yes i have set a default compiler. It is in the C::B-folder on volume F:/.
Concerning the C::B-settings i'm also a bit confused. I use a portable version and i had several problems with different 'appearences' of C::B, depending on how i start ist. Only using CbLauncher.exe works. In other cases no compiler is found or i have problems with the UI-size on my UHD-display.
I looked a whilw for different config-files but i did not find.
--- End quote ---
I do not know where you got the portable codeblocks version, but codeblocks does not really support portable installation as far as i can tell.. The configuration file is normally stored in %UserDir%/AppData/Roaming/Codeblocks i do not know how your portable handles this...
--- Quote ---So i collected the dlls and started the program again. Now there appered around 7-8 further requests for various openGL and system-dlls.
--- End quote ---
Normally you use dependencywalker to solve this problems: http://dependencywalker.com/
--- Quote ---I'll think about this, but in the end my program is not sooo huge. The last monolithic exe compiled with devC++ needs (containing symbols) ~11.000k; the other one (without symbols) ~1.900k. The program needs 14 source-files (7x .c and 7x .h)
--- End quote ---
stahta01 was talking about compiling wxWidgets. And i support his statement. I had many problems in the past with this. I tried it today with gcc_8.XX and it worked ok, but if the shit hits the fan and you get errors, you will not want to be the one who cleans it up...
art-ganseforth:
--- Quote ---I would be happy to know more about this: "Make sure your mingw compiler is in the PATH variable"...
--- End quote ---
Just foud out what you ment. Found your post when i wanted to give an update. My head had been at the compiler-settings. So i did not think of system parameter.
Think i understood the principal (long time ago that i used console).
--- Quote ---I am confused... Didn't you say that both programs behave the same now, after you cleaned up everything?
--- End quote ---
I thought i've said that i deleted the folders and recompiled again. Since i did this, both programs behave different again, when i start with C::B-start-button.
I'm also confused (just tried it once more), but ist true...
--- Quote ---For example:
1) Compiler Prog1 with project file with Build->Build
...
--- End quote ---
Yes. Just tried it once more. Ist true...
C::B-Protocol test-program (last line of compilation and program-start)
--- Code: ---Output file is bin\Release_x86\test.exe with size 1,05 MB
Process terminated with status 0 (0 minute(s), 6 second(s))
0 error(s), 0 warning(s) (0 minute(s), 6 second(s))
-------------- Run: Release in test (compiler: GNU GCC Compiler)---------------
Checking for existence: F:\codeblocks-17.12-nosetup\Projects\19-01-26 - test-ogl\test\bin\Release_x86\test.exe
Executing: "F:\codeblocks-17.12-nosetup\Projects\19-01-26 - test-ogl\test\bin\Release_x86\test.exe" (in F:\codeblocks-17.12-nosetup\Projects\19-01-26 - test-ogl\test\.)
Process terminated with status 0 (0 minute(s), 1 second(s))
--- End code ---
And the other one (error in the last line):
--- Code: ---Output file is glLive3d\glLive3d.exe with size 1,85 MB
Process terminated with status 0 (0 minute(s), 18 second(s))
0 error(s), 0 warning(s) (0 minute(s), 18 second(s))
-------------- Run: Release in glLive3d (compiler: GNU GCC Compiler)---------------
Checking for existence: F:\codeblocks-17.12-nosetup\Projects\19-01-24 - ThreadTest\glLive3d\glLive3d.exe
Executing: "F:\codeblocks-17.12-nosetup\Projects\19-01-24 - ThreadTest\glLive3d\glLive3d.exe" (in F:\codeblocks-17.12-nosetup\Projects\19-01-24 - ThreadTest\.)
Process terminated with status -1073741515 (0 minute(s), 3 second(s))
--- End code ---
Both were compiled in the same C::B-workspace without closing C::B in between.
--- Quote ---I do not know where you got the portable codeblocks version
--- End quote ---
Here: https://sourceforge.net/projects/codeblocks/files/Binaries/17.12/Windows/
Inside the unpacked archieve is a local UserData-folder. Maybe the C::B-nosetup version is configured to use this one instaed of the common one. For me it seem like this, because after duplicating the whole folder, i was abel to save and restore different settings for both.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version