Author Topic: Building CodeBlocks source (Read 41321 times)

sorinev · « **on:** July 20, 2013, 09:59:34 pm »

In an effort to learn more interesting things, have something noteworthy on my resume instead of just an AA, and to give back to a project I enjoy, appreciate, and have used for about 4 years; I'm trying to follow the directions to build CB from the source so I can start trying to help in some way. I'm not off to a promising start however. This seems like something that should be simple for me (especially if I'm aiming to contribute...), but frustratingly, it's not.

I've followed the directions in the wiki, double and triple checked everything, but still failing to build.

First it failed to build wxwidgets with a memory exhausted error (I have 8GB). I tried the flags thing mentioned in the wiki, but it still failed. I switched to monolithic=0, and that worked (though obviously I need to solve that properly).

Second, CB itself won't build. I made sure the wx variable was set with the base portion for the unpacked wxwidgets path, but the compile instantly fails on the first file with (invalid) and tinyxml/tinystr.cpp. I googled but that didnt really return anything relevant.

What am I missing? I'm not exactly inspiring confidence in myself, given my goal here. Your assistance is greatly appreciated. Windows 7 Pro 64-bit.

oBFusCATed · « **Reply #1 on:** July 20, 2013, 10:06:39 pm »

Where did you get the source from?
What is the exact error?

sorinev · « **Reply #2 on:** July 20, 2013, 10:12:42 pm »

Sorry I'm not at home right now, I'll post the exact error when I get home.

I originally got the source from the berilos svn linked in the wiki article, but then noticed somewhere else that it was moved to a svn at sourceforge, so I got it from there.

golgepapaz · « **Reply #3 on:** July 20, 2013, 11:50:22 pm »

for the memory exhausted problem you can pass the compiler -fno-keep-inline-dllexport
on the command line when building wxWidgets. I think you need the build wxWidgets as
monolithic since project for mingw CB link to that one.
Something like this;
mingw32-make -f makefile.gcc BUILD=release UNICODE=1 SHARED=1 MONOLITHIC=1 CXXFLAGS="-fno-keep-inline-dllexport"
This builds wxwidgets fine on my 4gb rig.

(invalid) usually means that some global variable expanded to an invalid value.You know you need to set
cb global variable also, right? if you haven't, set it to (assuming you checked out the CB to c:\codeblocks_svn)

base = c:\codeblocks_svn\src\
lib = c:\codeblocks_svn\src\devel

After this you should be able to compile CB with no problems.
P.S : for cb_release_type you can use -g for debug builds or any optimization flags for release builds (usually-O2)

sorinev · « **Reply #4 on:** July 21, 2013, 01:49:34 am »

Quote from: golgepapaz on July 20, 2013, 11:50:22 pm

for the memory exhausted problem you can pass the compiler -fno-keep-inline-dllexport
on the command line when building wxWidgets. I think you need the build wxWidgets as
monolithic since project for mingw CB link to that one.
Something like this;
mingw32-make -f makefile.gcc BUILD=release UNICODE=1 SHARED=1 MONOLITHIC=1 CXXFLAGS="-fno-keep-inline-dllexport"
This builds wxwidgets fine on my 4gb rig.

(invalid) usually means that some global variable expanded to an invalid value.You know you need to set
cb global variable also, right? if you haven't, set it to (assuming you checked out the CB to c:\codeblocks_svn)

base = c:\codeblocks_svn\src\
lib = c:\codeblocks_svn\src\devel

After this you should be able to compile CB with no problems.
P.S : for cb_release_type you can use -g for debug builds or any optimization flags for release builds (usually-O2)

I followed the instructions word for word and picture for picture as outlined here. Since the repository location is out of date in that article (I found the new one referenced somewhere else; I think in a thread here), is it possible some other elements of the build process outlined there are out of date as well?

I did try adding these two lines:

Code

CFLAGS ?= -fno-keep-inline-dllexport

CXXFLAGS ?= -fno-keep-inline-dllexport

to the config.gcc file as the page outlined last night. I am retrying with the "-fno-keep-inline-dllexport" part added to the command line instead, like you posted here. I'll post back when it's done.

I'll have to wait for this to finish before getting to that error for the actual CodeBlocks build attempt.

I also already did the global variable part as outlined on the page. If wx build successfully this time around, I'll recheck everything, including the global variable.

sorinev · « **Reply #5 on:** July 21, 2013, 02:00:44 am »

wxWidgets seems to have built successfully this time.

Building codeblocks failed again. The error is the same as before. The page says just open codeblocks.cbp and hit compile, so I did that. The error is:

Code


-------------- Build: tinyXML in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------

mingw32-g++.exe -Wall (invalid) -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE   -Wall -fno-strict-aliasing -Wno-write-strings   -iquote.objs\include -I.objs\include -I. -IC:\Users\Sorinev\Desktop\wxMSW-2.8.12\include -IC:\Users\Sorinev\Desktop\wxMSW-2.8.12\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Iinclude\tinyxml  -c C:\CodeBlocksSVNSource\src\base\tinyxml\tinystr.cpp -o .objs\base\tinyxml\tinystr.o
mingw32-g++.exe: error: (invalid): No such file or directory
Process terminated with status 1 (0 minutes, 0 seconds)
1 errors, 0 warnings (0 minutes, 0 seconds)

Every build target fails instantly. This is the error when having "all" selected. Other build targets fail immediately with different specific, but generally similar errors.

Is there more to it than just hitting build, as the page says to do?

stahta01 · « **Reply #6 on:** July 21, 2013, 02:04:29 am »

A important thing to keep in mind is using the same exact version of MinGW GCC to build both wxWidgets and CB.

I suggest posting the source (MinGW Std, TDM) and version number of the MinGW GCC you are using?

Also, re-post the exact wxWidgets build command you used? And post wxWidgets version?

And, remember if doing a second make of wxWidgets, that you MUST clean the prior build every time you change the build options.

Ans, remember when you change from Monolithic to non-Monolithic you MUST clean out all the object and library files because the objects and library are NOT safe to be built in the same folder.

List Folders I delete before doing a major wxWidgets build option change (Should be done when changing Monolithic setting).

build/msw
lib/gcc_dll*
lib/gcc_lib*

Tim S.

stahta01 · « **Reply #7 on:** July 21, 2013, 02:08:05 am »

You are missing or wrong setting for the cb_release_type.

Tim S.

Jenna · « **Reply #8 on:** July 21, 2013, 02:09:40 am »

You need at least a global variable cb, where the base points to the root-folder of the sources and global variable cb_release_type, where the base is e.g. -g for debug-build or -O2 (or whatever) for release-build.
By the way C::B should have asked for the content of both variables on first run and asked you for confirmation whether you want to save an invalid content.
If you don't want to put anything in cb_release_type you need at least to put a space here.

sorinev · « **Reply #9 on:** July 21, 2013, 04:17:08 am »

Jesus, I've never seen such fast replies to my forum posts in all of the years I've been tooling around on the internet. Haha. Thanks for the very fast and very helpful replies.

My command line for the [successful] wxWidgets build this time was exactly as in golgepapaz's post:

Code

mingw32-make -f makefile.gcc BUILD=release UNICODE=1 SHARED=1 MONOLITHIC=1 CXXFLAGS="-fno-keep-inline-dllexport"

I seem to have mingw 4.6.2. It uses the same one for both the command line wxwidgets build and the codeblocks ide [attempted] build.

It seems like it's obviously more than just a

Code

Open the project file CodeBlocks.cbp. You will be prompted to define the global variable $(#wx). Enter the location where you unpacked wxWidgets. Hit the blue gear and lean back.

needing to go on here. So how about we just skip that wiki page altogether and just start me fresh here with an idiots guide, from steps 0 to n. Every detail, no matter how small and trivial. I have mingw installed, it's in C:\MinGW. Is my repository right? TortoiseSVN shows that I'm at 9214. And what's the most recent download for the wxWidgets material? Any other materials I need to download?

Again, I really appreciate the speedy and helpful replies. I'll update to the latest nightly in the meantime. Currently running 12.11.

stahta01 · « **Reply #10 on:** July 21, 2013, 05:25:44 am »

I just looked over http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Windows#Compile_Code::Blocks

And, it is out of date.

I will try to give you the basic info needed. Feel free to update the Wiki page.

I will add notes to this post as I go over what I do to build CB.

Please read Wiki Pages linked below
http://wiki.codeblocks.org/index.php?title=Global_compiler_variables

You Need to correct the Global Variable called "cb_release_type"; something MUST be entered in the base field.
I use "-g" without the quotes.

Attached image; please download image and tell me you got it.
Your copy should say default where mine says test_cb_build.

I need to delete the image as soon as possible because this sites has very little space for images.

The warning shown below can be ignore the first time you build CB; it should not happen after the pre-compiled header is created during the SDK build.

Code

cc1plus.exe: warning: .objs\include: No such file or directory [enabled by default]

Tim S.

sorinev · « **Reply #11 on:** July 21, 2013, 07:56:15 am »

I downloaded the image, thanks.

sorinev · « **Reply #12 on:** July 21, 2013, 09:27:25 am »

I've now gotten as far as actually being able to build something this time. I set the cb_release_type (first to -g, then to -O2). I made a cb variable and set it to c:\cb_svn. I'm assuming that's what's meant by root folder. Or should it be c:\cb_svn\src? (well technically it's CodeBlocksSVNSource and not cb_svn).

I did not get the above warning. My build messages are the following:

Code

||=== Build: tinyXML in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler) ===|
||=== Build: AutoRevision in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler) ===|
||=== Build: ConsoleRunner in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler) ===|
||=== Build: Squirrel in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler) ===|
||=== Build: Squirrel std lib in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler) ===|
||=== Build: SqPlus in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler) ===|
||=== Build: scintilla in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler) ===|
||=== Build: wxpropgrid in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler) ===|
||=== Build: sdk in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler) ===|
C:\CodeBlocksSVNSource\src\sdk\globals.cpp||In function 'void PlaceWindow(wxTopLevelWindow*, cbPlaceDialogMode, bool)':|
C:\CodeBlocksSVNSource\src\sdk\globals.cpp|1050|warning: 'r.tagRECT::bottom' may be used uninitialized in this function [-Wuninitialized]|
C:\CodeBlocksSVNSource\src\sdk\globals.cpp|1050|warning: 'r.tagRECT::right' may be used uninitialized in this function [-Wuninitialized]|
||Execution of 'zip -jq9 devel\share\CodeBlocks\manager_resources.zip sdk\resources\*.xrc' in 'C:\CodeBlocksSVNSource\src' failed.|

and my build log is this:

Code

...
tons and tons of stuff
...


Creating library file: devel\libcodeblocks.a
Output file is devel\codeblocks.dll with size 7.57 MB
Running target post-build steps
cmd /c if not exist devel\share\CodeBlocks mkdir devel\share\CodeBlocks
zip -jq9 devel\share\CodeBlocks\manager_resources.zip sdk\resources\*.xrc
Execution of 'zip -jq9 devel\share\CodeBlocks\manager_resources.zip sdk\resources\*.xrc' in 'C:\CodeBlocksSVNSource\src' failed.

The contents of src\output are:

share folder, with various subfolders and files
cb_console_runner.exe
codeblocks.dll
wxmsw28u_gcc_custom.dll
wxpropgrid.dll

And the contents of src\devel are:

share folder, with various subfolders and files
cb_console_runner.exe
cb_share_config.exe
codeblocks.dll
libcodeblocks.a
libwxpropgrid.a
libwxscintilla_cb.a
wxmsw28u_gcc_custom.dll
wxpropgrid.dll

Clearly, I'm missing a few things. I ran update.bat anyway, but it didn't do anything, since I think I need to set up the whole zip windows path variable thing (I need info on that).

Jenna · « **Reply #13 on:** July 21, 2013, 10:04:38 am »

The error about the call to zip that failed means you did not follow the steps exactly.
You need a compatible zip in your systems-path, see http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Windows#zip.exe for a place to download it. The svn-client is not necessarily needed for building sources (if you not use svn-sources) and newer tortoise-svn has it included, so there is no longer the need to download it seperately.

sorinev · « **Reply #14 on:** July 21, 2013, 11:33:08 am »

I downloaded the zip 2.3.3 linked on that page. I tried settings the environment variable in codeblocks to ZIPCMD with value of C:\zip-2.3.3 and also tried changing ZIPCMD to just zip instead. That didn't work.

I also added C:\zip-2.3.3 to the windows "Path" area under advanced system properties -> environment variables, still no go.

Finally I just edited update.bat to change

Code

set ZIPCMD=zip

to

Code

set ZIPCMD="C:\zip-2.3.3\bin\zip.exe"

and now I no longer get "zip" not recognized, etc. messages spammed in the console window if I run update.bat myself; it actually does a few things now. But if I try to build codeblocks again, it still gives me the zip error.

If I'm doing something wrong, I'm not kidding when I say I need an idiot's guide. "Right click this, select this, type this exact thing, press ok. Now do this next thing by opening this menu, then..." etc. I've never built such a complicated application before. Everything I've done to date has ranged from single source file compiles, to projects with at most a couple dozen source files, with no extra settings, dependencies, dlls, etc. This whole thing is very new to me, so remember that what you take for granted is currently rocket science to me and akin to playing darts blindfolded and facing the wrong direction. Or like trying to hit a bullet with a smaller bullet while riding a horse, blindfolded.

Jenna · « **Reply #15 on:** July 21, 2013, 12:10:48 pm »

You need to add the folder where the zip.exe resides to your systems (windows I guess) search path.

BlueHazzard · « **Reply #16 on:** July 21, 2013, 05:24:16 pm »

i have updated the wiki a little bit. Can someone please check it?

greetings

ollydbg · « **Reply #17 on:** July 21, 2013, 05:44:37 pm »

Quote from: BlueHazzard on July 21, 2013, 05:24:16 pm

i have updated the wiki a little bit. Can someone please check it?

greetings

Good work, I think all your changes recently are OK, thanks.

sorinev · « **Reply #18 on:** July 22, 2013, 08:08:32 am »

Between google, the wiki, and this thread, I've been messing around with it for two days trying to get it to work and it's just not having it. I solve one thing, and another problem pops up. I solve that one, and the one I solved before comes back. Rinse and repeat.

I'm going to have to give up on this for now and come back when I'm more experienced with large projects and can actually figure out what the hell I'm doing and what needs to be done, through experience, and without tons of searching. Again, I appreciate the speedy replies and help you guys have offered.

LETARTARE · « **Reply #19 on:** July 22, 2013, 05:49:40 pm »

@BlueHazzard
Okay, very good job.

Maybe we could replace

Quote

CFLAGS ?= -fno-keep-inline-dllexport

Quote

CXXFLAGS ?= -fno-keep-inline-dllexport

by

Quote

CPPFLAGS ?= -fno-keep-inline-dllexport

I checked the Makefile, but we still control ...

and add after

Code

or 
mingw32-make -fmakefile.gcc SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 CPPFLAGS=-fno-keep-inline-dllexport

Thank you again

stahta01 · « **Reply #20 on:** July 22, 2013, 06:17:16 pm »

Quote from: LETARTARE on July 22, 2013, 05:49:40 pm

@BlueHazzard
Okay, very good job.

Maybe we could replace
Quote
CFLAGS ?= -fno-keep-inline-dllexport
Quote
CXXFLAGS ?= -fno-keep-inline-dllexport
by
Quote
CPPFLAGS ?= -fno-keep-inline-dllexport
I checked the Makefile, but we still control ...

and add after
Code
or 
mingw32-make -fmakefile.gcc SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 CPPFLAGS=-fno-keep-inline-dllexport 
Thank you again

Feel free to post that on the wxWidgets forum; it will likely be ignored.

FYI: This is NOT a CB Makefile; if you think I am wrong please say why you think it is a CB Makefile.

Tim S.

LETARTARE · « **Reply #21 on:** July 22, 2013, 07:28:34 pm »

hello @stahta01

by BlueHazard

Quote

i have updated the wiki a little bit. Can someone please check it?

I read the excellent work BlueHazard on WIKI.
http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Windows
where the two lines is, and I just wanted to show him a simplification.
But you're right, I should have done on the wiki !
Thanks.

sorinev · « **Reply #22 on:** July 26, 2013, 10:21:40 am »

I finally did it. 6 days later. Minor issue with the contrib plugins when trying to build the Nassi Shneiderman diagram tool/plugin - it looks I need to download AND build boost myself, then set up the global variable editor for "boost"? Other than that, it works.

Next step. Do you guys have some kind of overall system architecture view for the Code::Blocks source that generally shows how the parts/files work and flow and go together? I don't think I'll get very far just poking around in source files trying to follow things at this point in my knowledge.

ollydbg · « **Reply #23 on:** July 26, 2013, 11:29:44 am »

Quote from: sorinev on July 26, 2013, 10:21:40 am

I finally did it. 6 days later. Minor issue with the contrib plugins when trying to build the Nassi Shneiderman diagram tool/plugin - it looks I need to download AND build boost myself, then set up the global variable editor for "boost"? Other than that, it works.

Yes, that need boost library, only this plugin is depend on the boost library. I think you can download some prebuild boost library some internet, for me, I never build Nassi Shneiderman myself, I just skip building this cbp in the contributes plugins

.

Quote

Next step. Do you guys have some kind of overall system architecture view for the Code::Blocks source that generally shows how the parts/files work and flow and go together? I don't think I'll get very far just poking around in source files trying to follow things at this point in my knowledge.

I'm not sure that there are some document about this, but here I can explain all what I know:

src/src -> this contains code for building "codeblocks.exe"
src/sdk -> codeblocks.dll
src/base -> some base library needed for sdk, like tinyxml
src/include -> all the header files of sdk
plugins-> all the plugins, there are two kind of plugins, the core plugins and the contribute pluings (in a contrib subfolder)
src/devel -> all the build output (mainly binaries containing debug information)
src/output ->when you run "update.bat", it will copy from devel folder, but strip all the debug information
src/templates and src/scripts contains project wizard scripts

Is that enough? If not, just ask here.

sorinev · « **Reply #24 on:** July 27, 2013, 04:59:48 am »

Quote from: ollydbg on July 26, 2013, 11:29:44 am

Yes, that need boost library, only this plugin is depend on the boost library. I think you can download some prebuild boost library some internet, for me, I never build Nassi Shneiderman myself, I just skip building this cbp in the contributes plugins .

Alright, since I'm trying to build everything else under the sun (wxwidgets, codeblocks, qt, getting qt5 to work with codeblocks), I may as well throw some boost building in there too. I built everything in the workspace for the sake of thoroughness, as that's just how I am. I'm probably not going to actually use 95% of that stuff, at least in the foreseeable future, but I like knowing it's there.

Quote from: ollydbg on July 26, 2013, 11:29:44 am

I'm not sure that there are some document about this, but here I can explain all what I know:

src/src -> this contains code for building "codeblocks.exe"
src/sdk -> codeblocks.dll
src/base -> some base library needed for sdk, like tinyxml
src/include -> all the header files of sdk
plugins-> all the plugins, there are two kind of plugins, the core plugins and the contribute pluings (in a contrib subfolder)
src/devel -> all the build output (mainly binaries containing debug information)
src/output ->when you run "update.bat", it will copy from devel folder, but strip all the debug information
src/templates and src/scripts contains project wizard scripts

Is that enough? If not, just ask here.

Thanks, and that is indeed useful. But what I actually meant was when looking at the IDE itself, how am I going to know, filewise, where something else? For example, if I'm looking at xyz area of the IDE, which source file do I find xyz in? What I'm really looking for is some kind of structure chart, organizational chart, etc. that I can get a good overall view of everything from. Even a written tree or outline would work.

Also, I've never built such a large project before. My biggest project is a win32/c++ project that I wrote with about 11k lines. I can just put a breakpoint in it, hit F8, and that's that. Is that really possible with projects as big as codeblocks?

Jenna · « **Reply #25 on:** July 27, 2013, 07:24:02 am »

To make it clear: you do not need a prebuild boost library, the headers are enough.
At least I never compiled anything of boost and building C::B it works fine on windows.
About setting up the global boost-variable: http://forums.codeblocks.org/index.php/topic,15817.msg106443.html#msg106443 .

sorinev · « **Reply #26 on:** July 27, 2013, 08:54:24 am »

Quote from: jens on July 27, 2013, 07:24:02 am

To make it clear: you do not need a prebuild boost library, the headers are enough.
At least I never compiled anything of boost and building C::B it works fine on windows.
About setting up the global boost-variable: http://forums.codeblocks.org/index.php/topic,15817.msg106443.html#msg106443 .

Thanks, that did it. I already had the global variable set up right. I tried looking around for the file that the output log told me it couldn't find myself last night, but I didn't find it. So I'm glad that adding the $(#boost) bit to the compiler search path automagically did the trick for me.

sorinev · « **Reply #27 on:** August 05, 2013, 01:56:37 am »

Well, I've got the Windows + TDM-GCC build process for Code::Blocks down to three easy steps. SVN Update; Build; Update.bat; done.

But now I've got a new problem! I've got another system that I'm running Kubuntu 12.10 64-bit on (it's actually a VMware guest on my Windows system), and I'm trying to build from source. I've got it to the point where it starts compiling, but partway through, it stops. The error is:

Code

notebookstyles.h:13:25: fatal error: gtk/gtk.h: No such file or directory

I do have GTK install. I've never really gotten familiar with Linux, just tooled around a bit here and there, so I'm not sure what steps to take to resolve it. I googled around and found this issue as it relates to building gtk projects from within codeblocks, but I couldn't find anything involving the gtk header error for building codeblocks itself.

stahta01 · « **Reply #28 on:** August 05, 2013, 02:04:31 am »

Quote from: sorinev on August 05, 2013, 01:56:37 am

Code

notebookstyles.h:13:25: fatal error: gtk/gtk.h: No such file or directory

Make sure you install the dev packages for GTK.

Tim S.

sorinev · « **Reply #29 on:** August 05, 2013, 04:00:08 am »

I've now installed libgtk2.0-dev and libgtk-3-dev, but still stopping at the same spot. Was there anything else I was supposed to get? My searches really only turned up those two.

stahta01 · « **Reply #30 on:** August 05, 2013, 05:25:28 am »

Quote from: sorinev on August 05, 2013, 04:00:08 am

I've now installed libgtk2.0-dev and libgtk-3-dev, but still stopping at the same spot. Was there anything else I was supposed to get? My searches really only turned up those two.

I suggest doing the NON CB build because it might give better directions on the prereqs.

http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Linux

Or maybe try these pre-reqs
http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_nightly_build_on_Ubuntu

Tim S.

blauzahn · « **Reply #31 on:** August 05, 2013, 07:51:55 pm »

Did you suceed in compiling cb?

Compiling cb from the commandline works on Ubuntu 12.10, once the ./configure script ran sucessfully
(see wiki or file BUILD). It then shows:

Code

*************************************************
* Code::Blocks source tree has been configured. *
*************************************************

If you do not want do install boost and can live without the NassiShneiderman-plugin,
then change the configure to:

Code

./configure --with-contrib-plugins=all,-NassiShneiderman

If memory serves me, to satisfy configure I had to install:
libgtk2-common
libgtk2.0-dev
wx-common
wx2.8-headers
libwxbase2.8-0
libwxbase2.8-dev
libwxgtk2.8-0
libwxgtk2.8-dev

sorinev · « **Reply #32 on:** August 06, 2013, 04:43:03 am »

Quote from: blauzahn on August 05, 2013, 07:51:55 pm

Did you suceed in compiling cb?

I did not.

Quote from: blauzahn on August 05, 2013, 07:51:55 pm

Compiling cb from the commandline works on Ubuntu 12.10, once the ./configure script ran sucessfully
(see wiki or file BUILD). It then shows:

Code
*************************************************
* Code::Blocks source tree has been configured. *
*************************************************
If you do not want do install boost and can live without the NassiShneiderman-plugin,
then change the configure to:

Code
./configure --with-contrib-plugins=all,-NassiShneiderman
If memory serves me, to satisfy configure I had to install:
libgtk2-common
libgtk2.0-dev
wx-common
wx2.8-headers
libwxbase2.8-0
libwxbase2.8-dev
libwxgtk2.8-0
libwxgtk2.8-dev

I checked for those packages, and it says that I already have all of them installed.

sorinev · « **Reply #33 on:** August 06, 2013, 07:07:00 am »

When trying to build the plugins:

./configure --with-contrib-plugins=all seems to fail at:

No package 'hunspell' found.

Last night, I tried apt-getting this and searching the package manager for it, but I got nothing useful. Today, apt-get doesn't tell me there's no hunspell anymore, so it actually installed that. But I still get the error. It says something about if I installed anything using a non-standard prefix, but I've done everything from the system install itself, to apt getting everything, to making things, all with default options; nothing different or special.

Jenna · « **Reply #34 on:** August 06, 2013, 08:19:56 am »

It's libhunspell-dev on debian-based systems.

sorinev · « **Reply #35 on:** August 06, 2013, 10:16:36 am »

Quote from: jens on August 06, 2013, 08:19:56 am

It's libhunspell-dev on debian-based systems.

That did the trick, thank you for the assist. I also needed libgamin-dev and libboost-dev. However, after I did make && make install, this happened.

Code

make[6]: Nothing to be done for `install-exec-am'.
 /bin/mkdir -p '/usr/local/include/codeblocks/scripting/sqplus'
 /usr/bin/install -c -m 644 SqPlusConst.h SquirrelBindingsUtils.h SquirrelVM.h sqplus.h SquirrelObject.h '/usr/local/include/codeblocks/scripting/sqplus'
/usr/bin/install: cannot remove ‘/usr/local/include/codeblocks/scripting/sqplus/SqPlusConst.h’: Permission denied
/usr/bin/install: cannot remove ‘/usr/local/include/codeblocks/scripting/sqplus/SquirrelBindingsUtils.h’: Permission denied
/usr/bin/install: cannot remove ‘/usr/local/include/codeblocks/scripting/sqplus/SquirrelVM.h’: Permission denied
/usr/bin/install: cannot remove ‘/usr/local/include/codeblocks/scripting/sqplus/sqplus.h’: Permission denied
/usr/bin/install: cannot remove ‘/usr/local/include/codeblocks/scripting/sqplus/SquirrelObject.h’: Permission denied
make[6]: *** [install-sdkHEADERS] Error 1
make[6]: Leaving directory `/home/sorinev/devel/trunk/src/include/scripting/sqplus'
make[5]: *** [install-am] Error 2
make[5]: Leaving directory `/home/sorinev/devel/trunk/src/include/scripting/sqplus'
make[4]: *** [install-recursive] Error 1
make[4]: Leaving directory `/home/sorinev/devel/trunk/src/include/scripting'
make[3]: *** [install-recursive] Error 1
make[3]: Leaving directory `/home/sorinev/devel/trunk/src/include'
make[2]: *** [install] Error 2
make[2]: Leaving directory `/home/sorinev/devel/trunk/src/include'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/sorinev/devel/trunk/src'
make: *** [install-recursive] Error 1

Is this something that I need to address, or have I reached the end and am good to go?

BlueHazzard · « **Reply #36 on:** August 06, 2013, 10:42:33 am »

i think you have to do "sudo make install" unless you use a installation directory with write permission (use --prefix=/path/to/install/with/write/permission in the configure preocess)

sorinev · « **Reply #37 on:** August 06, 2013, 10:53:23 am »

I've been using sudo when doing make and make install, I kept getting permission denied failures midway through otherwise. So it still does it even with sudo. Which I find weird.

I'm also building the source through the codeblocks IDE I got through apt-get. The IDE portion of the build was successful, and the contrib plugins workspace seems to be going ok too. I'm use the cbp files that have "unix" in their names, as I'm assuming that's what I was supposed to choose.

The building-codeblocks-using-codeblocks-itself method seems to be going a lot cleaner than a raw compile on the command line. Although maybe, I guess, it helps that I've been installing all of these dev libraries the last couple of days.

BlueHazzard · « **Reply #38 on:** August 06, 2013, 01:58:43 pm »

Quote from: sorinev on August 06, 2013, 10:53:23 am

I've been using sudo when doing make and make install, I kept getting permission denied failures midway through otherwise. So it still does it even with sudo. Which I find weird.

never use sudo where it is not needed. You cut your own rights. Use sudo only if it is needed...

sorinev · « **Reply #39 on:** August 06, 2013, 10:19:53 pm »

Well yeah, I try not to. But when I get permission denied errors, I really don't know what the alternative is.

So I've got the IDE built, and the contrib plugins built, and I did the ./update, but the plugins don't seem to load when I start codeblocks? All the stuff present in my Windows version of the svn build is missing from my Linux svn build.

Jens' page seems to be saying that the contrib plugins can't be used on Ubuntu? Really?!

I guess I don't really use them, but still...

Jenna · « **Reply #40 on:** August 06, 2013, 10:30:30 pm »

Quote from: sorinev on August 06, 2013, 10:19:53 pm

Well yeah, I try not to. But when I get permission denied errors, I really don't know what the alternative is.

So I've got the IDE built, and the contrib plugins built, and I did the ./update, but the plugins don't seem to load when I start codeblocks? All the stuff present in my Windows version of the svn build is missing from my Linux svn build.

Jens' page seems to be saying that the contrib plugins can't be used on Ubuntu? Really?! I guess I don't really use them, but still...

I never wrote this.
You can use the contrib-plugins in ubuntu without any issues.
But you can not use the contrib-plugins-packages from my site, as ubuntu uses different lib-versions the debian does.

And I do not build ubuntu-packages.
I could do, but I personally don't like (and of course don't use) ubuntu (except for testing purposes) and I build packages for three versiond of fedora, two CentOS/RedHat versions and two debian versions (all in 32 and 64-bit) and this binds enough of my resources.

blauzahn · « **Reply #41 on:** August 06, 2013, 10:57:01 pm »

If you see only the ubuntu-version, your compiled programm is either not installed or not started.
I have even uninstalled the ubuntu version of codeblocks to avoid conflicts. But before you start
uninstalling that, at least you can see, if you can start /usr/local/bin/codeblocks from the commandline.

If you still lack a sucessful installation, try only:

Code

make

watch the result. And only when it looks ok (no error visible, instead: "Nothing to be done for `all-am'."), then enter:

Code

sudo make install

If that does not work, check if you can write (as sudoer) to that directory at all. e.g.

Code

sudo install --directory /usr/local/include/codeblocks/scripting/sqplus
sudo touch /usr/local/include/codeblocks/scripting/sqplus/mytouchtest.txt

sorinev · « **Reply #42 on:** August 06, 2013, 10:57:10 pm »

I must have missed some part of the process somewhere then. The contrib plugins were successfully built, so I think there's some step I haven't done. I assumed I was supposed to run the ./update file? (which I did).

Code

output/share/codeblocks            is full of all of the individual contrib zip files.
output/share/codeblocks/plugins    is full of all the matching contrib .so files.

sorinev · « **Reply #43 on:** August 06, 2013, 11:02:23 pm »

Quote from: blauzahn on August 06, 2013, 10:57:01 pm

at least you can see, if you can start /usr/local/bin/codeblocks from the commandline.

Yep, it starts ok from that directory the first try, just the contrib plugins are missing.

Jenna · « **Reply #44 on:** August 06, 2013, 11:16:37 pm »

Do you use C::B to build C::B or do you use the automake-system ?
You wrote about both, if I remember correctly.

For automake you do not need the update-scripts.
Just (the simplest example):

./bootstrap
./configure --with-contrib-plugins=all
make
sudo make install
codeblocks -v

Better would be:

./bootstrap
mkdir build
cd build
-./configure --prefix=/home/username/whatever-you-like --with-contrib-plugins=all
make -jx (where x is the amount of your cpu-cores+1)
make install
/home/username/whatever-you-like/bin/codeblocks -v

Both example assume you start from the root of C::B's sources.
The second one makes it easier to remove the whole build-tree, does not litter the sources with intermediate files and keeps your copy of C::B in a folder below your home-folder, so there can not be any access-right issues and you can keep multiple versions of C::B on one system (including "official" builds below /usr).

The -v parameter is not needed for normal use, but it gives more debug-messages if something went wrong, as it seems to be in your case.

sorinev · « **Reply #45 on:** August 07, 2013, 05:35:10 am »

Quote from: jens on August 06, 2013, 11:16:37 pm

Do you use C::B to build C::B or do you use the automake-system ?

You wrote about both, if I remember correctly.

Yeah, I tried both. First, I tried the command line method. ./boostrap, ./configure, etc. But I had so-so luck with that.

Second, I tried the 'use C::B to build C::B' route, and it went fantastically and without a hitch, aside from the contrib plugins not loading. My process was:

apt-get install codeblocks - I end up with 12.11
Go to ~/devel/trunk/src/ and open codeblocks-unix.cbp
Build - success
Now, while still in ~/devel/trunk/src/ open ContribPlugins-unix.workspace
Build Workspace - success
Still in ~/devel/trunk/src/ and do ./update
Output folder is generated, just like on Windows, with following contents as pictured:

Quote from: jens on August 06, 2013, 11:16:37 pm

The -v parameter is not needed for normal use, but it gives more debug-messages if something went wrong, as it seems to be in your case.

i tried that, from the output folder pictured above, and nothing in the console seemed to indicate any problems. But in the IDE, going to Plugins -> Manage Plugins pops up the plugins management window with the following message box popped up on top of it (does not happen when starting codeblocks normally):

Code

Failed to create a temporary file name
(error 13: Permission denied)

In the list of plugins on that Manage Plugins dialog, the contrib plugins are not listed. Install New only looks for .cbplugin filenames, but the contribs exist as .zip and/or .so.

Jenna · « **Reply #46 on:** August 07, 2013, 06:11:16 am »

If you use C::B to build C::B, you need to run it through the wrapper-script run.sh (on linux and alike systems, not on windows !).
from src-folder, e.g. output/run.sh -v, or any other C::B commandline parameter instead of the -v .

Nevertheless, the autotools should work. Did you try to build it below your home-folder ?

sorinev · « **Reply #47 on:** August 07, 2013, 06:44:22 am »

That worked. So every time that I run it, I have to actually start it through ./run.sh? Alrighty.

News:

Author Topic: Building CodeBlocks source (Read 41321 times)