Site navigation

Yikes! adler32.c line 57

Linux
#1

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]

Any ideas?

#2

nothing jumps out at me.

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.

#3

I’m having trouble compiling FLAC too…

[quote]juce_OggVorbisAudioFormat.cpp
juce_WavAudioFormat.cpp
bitbuffer.c
bitmath.c
cpu.c
crc.c
fixed.c
float.c
format.c
lpc_flac.c
md5.c
memory.c
stream_decoder.c
…/…/src/juce_appframework/audio/audio_file_formats/flac/libFLAC/stream_decoder.c: In function ‘FLAC__StreamDecoderInitStatus init_FILE_internal_(FLAC__StreamDecoder*, FILE*, FLAC__StreamDecoderWriteStatus ()(const FLAC__StreamDecoder, const FLAC__Frame*, const FLAC__int32* const*, void*), void ()(const FLAC__StreamDecoder, const FLAC__StreamMetadata*, void*), void ()(const FLAC__StreamDecoder, FLAC__StreamDecoderErrorStatus, void*), void*, FLAC__bool)’:
…/…/src/juce_appframework/audio/audio_file_formats/flac/libFLAC/stream_decoder.c:551: error: cannot convert ‘FLAC__StreamDecoderInitStatus’ to ‘FLAC__StreamDecoderState’ in assignment
…/…/src/juce_appframework/audio/audio_file_formats/flac/libFLAC/stream_decoder.c:554: error: cannot convert ‘FLAC__StreamDecoderInitStatus’ to ‘FLAC__StreamDecoderState’ in assignment
…/…/src/juce_appframework/audio/audio_file_formats/flac/libFLAC/stream_decoder.c: In function ‘FLAC__StreamDecoderInitStatus init_file_internal_(FLAC__StreamDecoder*, const char*, FLAC__StreamDecoderWriteStatus ()(const FLAC__StreamDecoder, const FLAC__Frame*, const FLAC__int32* const*, void*), void ()(const FLAC__StreamDecoder, const FLAC__StreamMetadata*, void*), void ()(const FLAC__StreamDecoder, FLAC__StreamDecoderErrorStatus, void*), void*, FLAC__bool)’:
…/…/src/juce_appframework/audio/audio_file_formats/flac/libFLAC/stream_decoder.c:625: error: cannot convert ‘FLAC__StreamDecoderInitStatus’ to ‘FLAC__StreamDecoderState’ in assignment
…/…/src/juce_appframework/audio/audio_file_formats/flac/libFLAC/stream_decoder.c:628: error: cannot convert ‘FLAC__StreamDecoderInitStatus’ to ‘FLAC__StreamDecoderState’ in assignment
…/…/src/juce_appframework/audio/audio_file_formats/flac/libFLAC/stream_decoder.c: In function ‘FLAC__bool read_metadata_picture_(FLAC__StreamDecoder*, FLAC__StreamMetadata_Picture*)’:
…/…/src/juce_appframework/audio/audio_file_formats/flac/libFLAC/stream_decoder.c:1841: error: cannot convert ‘FLAC__StreamMetadata_Picture_Type*’ to ‘FLAC__uint32*’ for argument ‘2’ to ‘FLAC__bool FLAC__bitbuffer_read_raw_uint32(FLAC__BitBuffer*, FLAC__uint32*, unsigned int, FLAC__bool ()(FLAC__byte, size_t*, void*), void*)’
make[1]: *** […/…/bin/intermediate_linux/Debug/stream_decoder.o] Error 1
make: *** [JUCE] Error 2[/quote]

I don’t know why I’m having these problems… maybe a recent ubuntu update?

#4

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 :frowning:

#5

oh! I must have #define BREAK_BUILD_ON_COMPILING_FREE_LIBS 1

now my build breaks on the PNG library… I see some pattern to my problem but don’t understand this at all.

Maybe I need to take my problem to an Ubuntu forum…

#6

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…

#7

I reinstalled my OS and everything’s fine now (i.e. juce built with no errors). It turns out I’m just a “Linux Weenie”

thanks!

Dan

#8

Well now I’m having the same problems on Ubuntu Feisty.
Is there any restriction to what GCC versions work for compiling JUCE?

#9

It should be fine with anything from gcc3.3 onwards, but I guess it could vary between platforms, and I can’t test them all.

#10

i currently compile juce apps on a gentoo x86 system with gcc 3.4.6 and 4.1.1 without any problem or complain so far…

#11

[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).

#12

I had originally tried premake for codeblocks, but I wiped, re-downloaded, and used premake --target gnu and it all worked flawlessly :smiley:

#13

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?

Thanks,

Bruce

#14

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?

Bruce

#15

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?

Bruce

#16

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.

#17

OT: why has this topic been viewed 4000 times? It’s one of the most-read things on this forum, but I don’t understand why!

#18

maybe the word “Yikes” is attracting people !
who knows, usually coders came out from a Johnny Hart’s comic :slight_smile:

#19