Compiling the Hello World example for Linux (gcc)

#1

Hello,

I finally got JUCE to build here on Linux (it actually had some errors in the code itself… don’t know why, but anyway, I fixed them), and also was able to get the example project from the site to build.

So now I want to actually learn how to use JUCE, so I’m trying to compile the Hello World example, and subsequently look at it. I’ve got the #define LINUX in there - the problem is that the code is apparently written for Visual-C++, and will not compile for gcc (?) (this is what my code-savvy friend said when I asked him what he thought the problem was, since I was getting these wierd errors when I tried to compile)

So does anyone have any simple “Hello World” type examples that will compile on Linux? Or any advice? Thanks!

#2

What errors are you talking about? I always check it on linux before releasing, and the demo app works fine…

#3

…
on that note, i’m looking to get into playing with JUCE on linux, but i’m a bit confused as to how to go about it.
i’ve looked at kdevelop and like the environment…
would anyone feel like posting a complete demo project (perhaps the JUCE demo is sufficient!) and a step-by-step walkthrough of how i’d compile and run it?

if not, no worries :slight_smile:

thanks
bigjim

#4

The errors in the actual JUCE code, as opposed to the “Win32 Hello World” example?

What I found was that classes seem to have instances of other classes inside them, but the other class is not declared until after the implementation of the first class. So I just added a declaration of the 2nd class up at the top of the file, and it worked out fine. In some of the cases (or all? don’t remember) the 2nd class was declared inside the first class, but as a “friend”, like this:

class Whatever {

friend class Whatever2;
Whatever2 thing;
}

class Whatever2;

and gcc gave me an error, in which it obviously was misinterpreting what Whatever2 was supposed to be since it didn’t know it was a type that could be used to declare something. This was fixed just by adding “class Whatever2;” at the top of the file

As far as the errors in the Win32 demo program (the one included in the JUCE library itself), I’ll have to recheck the errors when I get to the lab again on Thursday - it’s nothing I recognized, so I didn’t remember exactly what it was.

#5

[quote=“bigjim”]…
on that note, i’m looking to get into playing with JUCE on linux, but i’m a bit confused as to how to go about it.
i’ve looked at kdevelop and like the environment…
would anyone feel like posting a complete demo project (perhaps the JUCE demo is sufficient!) and a step-by-step walkthrough of how i’d compile and run it?

if not, no worries :slight_smile:

thanks
bigjim[/quote]

First, you’ve got to compile JUCE itself. Download the library and unpack it, then go into the folder, go to the build/linux section (approximately) until you get the makefile, type “make”, then watch as it builds. If it encounters errors, go into the files and fix the errors. Then download the example, unpack it, and build that too!

#6

[quote=“Rellik”]The errors in the actual JUCE code, as opposed to the “Win32 Hello World” example?

What I found was that classes seem to have instances of other classes inside them, but the other class is not declared until after the implementation of the first class. So I just added a declaration of the 2nd class up at the top of the file, and it worked out fine. In some of the cases (or all? don’t remember) the 2nd class was declared inside the first class, but as a “friend”, like this:

class Whatever {

friend class Whatever2;
Whatever2 thing;
}

class Whatever2;

and gcc gave me an error, in which it obviously was misinterpreting what Whatever2 was supposed to be since it didn’t know it was a type that could be used to declare something. This was fixed just by adding “class Whatever2;” at the top of the file

As far as the errors in the Win32 demo program (the one included in the JUCE library itself), I’ll have to recheck the errors when I get to the lab again on Thursday - it’s nothing I recognized, so I didn’t remember exactly what it was.[/quote]

sounds a bit odd - I’m always careful about that kind of thing. Are you using a really old version of gcc? Or maybe a bleeding-edge version that’s stricter about these things? I’d love to know where the errors are, if you could give me a list.

#7

(oh, and don’t waste any time messing with the hello world projects - if you’ve not already done so, the demo app is the place to start for loads of example code and projects, etc.)

#8

Sorry, I dont’ know anything about which gcc installation we’re using - and I also don’t remember which errors I had, but I remember one was in the ThreadPool class, I think. If I get a chance I’ll go back and do the whole process again and record what I did.

The reason I was interested in the Hello World program was because I wanted to see what had to be changed to port to Linux from Windows, since it’s of a size small enough that I can get a sense for what’s going on. I’ll take a look at the example app code and see if I can make sense of it, though!

#9

That’s easy - nothing at all has to change… Same with the demo app.

#10

Hey bigjim,

I’m just starting to develop in Linux. I’m using KDevelop and it’s pretty sweet. One hint: you can compile “inside” KDevelop by using its [color=darkblue]Project | Import Existing Project…[/color] menu item and then selecting the “Generic C++ Application (Custom Makefile)” setting. While in that dialog browse to directory Rellik mentioned and select the makefile there. Once you’ve done that you should be able to [color=darkblue]Build | Build Project[/color].

Steve

#11

ahh, cool – thanks steve

#12

alternatively, for a slightly lighter dev environment, use the Kate text editor, which has built in c/c++ formatting, and a built in command line window (which you can run make and the app from). Typically you’ll need to fiddle with the settings in Kate to make it work the way you like, but once set up, it works well.

#13

[quote=“jules”]
sounds a bit odd - I’m always careful about that kind of thing. Are you using a really old version of gcc? Or maybe a bleeding-edge version that’s stricter about these things? I’d love to know where the errors are, if you could give me a list.[/quote]

Well, I’m going to take a guess at what Relik was referring to, as it just bit me on the arse.

gcc4 seems to be really pendantic about forward declarations.

To get JUCE to compile on a new SuSE (10.1) install I had to add forward declares on a bunch of classes because gcc wasn’t prepared to give them the benefit of the doubt.

I can’t recall offhand which .h files I needed to update, but for example:

MenuBarModel.h needed a

class MenuBarComponent;

declaration ahead of the MenuBarModel class.

#14

Was it instances of friend class declarations for classes that hadn’t been defined yet?

#15

Mostly, but not always.

Actually I’m having another (more serious) problem, that I’m trying to get to the bottom of. I tried compiling jucedemo with gcc 4.0.2 and when I run the app it explodes soemwhere deep inside. I haven’t yet had a chance to look at where - it was 2am when I was ready to test stuff, and that pretty musch sent m,e off to bed. :wink:

#16

OK, this could be an issue.

I compiled jucedemo on a mandrake box with gcc 3.3 or thereabouts (openGL disabled).

I then compiled in my new suse box with gcc4.02 (openGL also disabled).

If I try to run the 4.02 compiled binary ti either explodes during initialisation, or gives me a screen full of crap[1].

if I run the gcc3 compiled binary on the suse machine it runs fine.

I can upload both binary compiles, and or screen shots if needed.

[1] I was doing this test specifically because my own code is doing the same thing.

#17

I think I’ve been using 4.0.2 as well, but didn’t have any of the compilation problems… Next time I reboot into linux I’ll check the compiler version.

#18

I installed SuSE 10.1, which is probably a little bleeding edge[1], so all libraries are probably running at the latest, or close to latest, stable build.

I have it installed on my desktop and laptop, and both behave the same way with juce. All other compiled libraries (libxml2, libtiff, linpng, libiconv, dctmk and a few others compiled fine - though a few needed some modifications that after googling a little turned about to be needed by other 4.02 users).

I’ll try and see if gdb can give me any clues as to where exceptions are occurring, and why. I have a hunch though that gcc4 does something pedantic with pointer and type casts, so I’ll look into that first and let you know if I work anything out.

[1] no other distro can ever make sense of my laptop’s wireless interface.

#19

Well I think I know what the problem is, though I’m not sure why:

it turns out that my laptop was a red-hering. I’m tired and stupid, and I forgot to make clean, before building the juce demo. I had scp’d the whole unpacked ./juce path to the laptop to test quickly, and consequently the exe was nevr updated from the version off of my desktop.

A clean build later and jucedemo works fine on the laptop. It doesn’t work on the desktop though. The only difference between the two is that the desktop is a 64bit AMD running a 32bit kernel. The laptop is a 32bit CPU.

I got to wondering if gcc was getting confused and trying to compile as a 64bit app, which some of the warnings generated when compiling stuff suggested it might be. My understanding is that this shouldn’t be happening, sop unless there are some compile switches set wrong somewhere in the jucedemo makefile, I’m going to assume the gcc is hosed on my machine.

#20