I thought I was able to build juce 1.41 in the past, but it seems I am running into problems tonight… not sure if something in my system has changed that’s breaking the build or what
Here’s my error:
[quote]juce_SubregionStream.cpp
adler32.c
…/…/src/juce_core/io/streams/zlib/adler32.c:57: error: ‘z_uLong z_adler32’ redeclared as different kind of symbol
…/…/src/juce_core/io/streams/zlib/zlib.h:1260: error: previous declaration of ‘z_uLong z_adler32(z_uLong, const z_Bytef*, z_uInt)’
…/…/src/juce_core/io/streams/zlib/adler32.c:57: error: ‘adler’ was not declared in this scope
…/…/src/juce_core/io/streams/zlib/adler32.c:57: error: ‘buf’ was not declared in this scope
…/…/src/juce_core/io/streams/zlib/adler32.c:57: error: ‘len’ was not declared in this scope
…/…/src/juce_core/io/streams/zlib/adler32.c:61: error: expected unqualified-id before ‘{’ token
…/…/src/juce_core/io/streams/zlib/adler32.c:128: error: ‘z_uLong adler32_combine’ redeclared as different kind of symbol
…/…/src/juce_core/io/streams/zlib/zlib.h:1276: error: previous declaration of ‘z_uLong adler32_combine(z_uLong, z_uLong, long int)’
…/…/src/juce_core/io/streams/zlib/adler32.c:128: error: ‘adler1’ was not declared in this scope
…/…/src/juce_core/io/streams/zlib/adler32.c:128: error: ‘adler2’ was not declared in this scope
…/…/src/juce_core/io/streams/zlib/adler32.c:128: error: ‘len2’ was not declared in this scope
…/…/src/juce_core/io/streams/zlib/adler32.c:132: error: expected unqualified-id before ‘{’ token
make[1]: *** […/…/bin/intermediate_linux/Debug/adler32.o] Error 1
make: *** [JUCE] Error 2[/quote]
I assume you’re just building juce here, not anything else right?
Personally I’d delete the juce tree, re-extract the download and try again. If you extracted over a previous version, you may have some version conflicts if some files weren’t updated.
Beyond that, look to see what compiles directly before zlib, as the problem may be earlier in the compilation sequence.
also note, I had succes compiling zlib when I had Juce use zlib.h directly from my system, meaning that in
"juce_GZIPCompressorOutputStream.cpp" and "juce_GZIPDecompressorInputStream.cpp"
I removed the include
and inserted the include:
and I added the Juce hack to zconf.h:
// *** Just a few hacks here to make it compile nicely with Juce..
#define Z_PREFIX 1
#undef __MACTYPES__
#ifdef _MSC_VER
#pragma warning (disable : 4131 4127 4244 4267)
#endif
which worked!
… but when Make proceed building the rest of Juce it broke on FLAC
Have you messed with your include paths? If you’re including some other versions of the zlib or png headers, then that could cause incompatibilities with the ones in the juce tree…
[quote=“Sastraxi”]Well now I’m having the same problems on Ubuntu Feisty.
Is there any restriction to what GCC versions work for compiling JUCE?[/quote]
compiles just fine for me with edgy (mandriva also).
I tried the same. I was enthralled by the ease of the premake > CB conversion (compare to the unearthly grind of an Eclipse project) but now I’m at the adler hitch.
When I look at the CodeBlocks project file, there’s hardly any includes. Wait, that’s all that’s in the premake either. Hmm.
Anyone know what includes I’d want in a standard Linux project that may affect this offhand?
OK, it looks like there’s a slight mod to zlib’s zconf.h to make juce happy with it. My premake’ed CB project and default CodeBlocks install seems to be finding the Ubuntu/installed zlib first, without the mods.
I can’t for the life of me find any sort of master paths for Code::Blocks (does it use GCC’s?) so that’s a bit naff.
So, I defined Z_PREFIX in the project, instead of in the special zconf.h file - the other tweaks seem to be MSC and OSX specific. But that didn’t help.
More digging to do I suppose, unless anyone is a CodeBlocks path order whiz?
So, for anyone following my Linux shenanaigans, in the cold light of day, I started to use the juce make file, not the tantalizingly nice looking C::B project.
Now juce builds in debug, but in release config, it blows up looking for bitbuffer.h while compiling stream_encoder.o - these are all flac files. But bitbuffer.h seems to have been removed from the library! I guess on purpose. I’m buggered if I can find what’s expecting to use that file though. It’s not obvious, and I can’t get to the info to see why (in either the terminal or CodeBlocks).
I’m grep’ing my whole filesystem now. I can only guess it’s a stray include, but I can’t find it.
Meanwhile, if I make juce a dependency for my project, it tries to build with C::B not the custom makefile. Is that just a bug?
OK, sorry. It looks like the Win32 Code::Blocks project refers to bitbuffer.h - so that does need to be updated. When I abortively tried to convert that file to Windows, it scattered some intermediate files in the build folder. Because they were odd, it looks like ‘clean’ ignored them, but the linker was picking them up and trying to be nice. Bless it.
Bit obscure, but there you go. I owe you 3.6kb.
Bruce
PS - As I said, the windows Code::Blocks project is out of date, and I second the request for a Linux C::B project please.
