> Oliver St?neberg wrote: > > > > > > Oliver St?neberg wrote: > > > > > > > I finally got around to trying to update FLAC for the MAME/MESS > > > > project again. There were several issues I was able to fix and will > > > > submit patches later, but I hit one roadblock with GCC and clang: > > > > > > > > src/lib/libflac/libFLAC/stream_encoder.c:1696:43: error: cast from function call > > > > of type 'double' to non-matching type 'FLAC__int32' (aka 'int') > > > > [-Werror,-Wbad-function-cast] > > > > ...FLAC__int32 tukey_parts = (FLAC__int32)strtod(specification+14, 0); > > > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > src/lib/libflac/libFLAC/stream_encoder.c:1717:43: error: cast from function call > > > > of type 'double' to non-matching type 'FLAC__int32' (aka 'int') > > > > [-Werror,-Wbad-function-cast] > > > > ...FLAC__int32 tukey_parts = (FLAC__int32)strtod(specification+15, 0); > > > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > 2 errors generated. > > > > > > What build system are you using and what versions of GCC and Clang? > > > What OS? > > > > clang 3.5 on ubuntu 14.04 and GCC (MinGW-w64) 4.9.1 on Windows 7. > > > You still didn't sat which build system. The reason I ask is that > if you were building using one of the build systems shipped with FLAC, > there would not be a path like > > src/lib/libflac/libFLAC/stream_encoder.c > > which suggests that you imported the FLAC sources into your own source > tree and your building it with your own build system. > > Sorry, but we cannot support your custom build system :-).Sorry...overlooked that. Yes, it is a custom build system, but what does have to do with the code causing a warning with GCC/clang, that is enabled by default? Unless you disable this warning in your build system. Just using autoconf or cmake instead of gcc/clang directly doesn't make them compiler behave differently - unless you tell them to ;)
Oliver St?neberg wrote:> Sorry...overlooked that. > > Yes, it is a custom build system, but what does have to do with the > code causing a warning with GCC/clang, that is enabled by default?I don't know, its your build system and I haven't seen it, nor do I have the time and motivation to look at it (unless of course you were paying me for my time). I willing give my time to maintain FLAC. I have not signed up to spend my time on your project.> Unless you disable this warning in your build system.Well, you can look at our build system for yourself, but I can assure you that when I'm compiling FLAC in development (ie configured using "./configure --enable-werror") I am compiling with: -Wall -Wextra -Wstrict-prototypes -Wmissing-prototypes -Waggregate-return -Wcast-align -Wnested-externs -Wshadow -Wundef -Wmissing-declarations -Wunreachable-code -Winline -Wdeclaration-after-statement -Werror> Just using > autoconf or cmake instead of gcc/clang directly doesn't make them > compiler behave differently - unless you tell them to ;)Our autotool build system generates at least one header file (config.h, in the top level directory). Unless your build system generates the exact same header file, the results will be different. Our build system does not deisplay that warning (as you can easily prove for yourself, hint trying building with "V=1 make" so see the full compiler invocation). That should be the end of this discussion. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
> I don't know, its your build system and I haven't seen it, nor do > I have the time and motivation to look at it (unless of course you > were paying me for my time). I willing give my time to maintain > FLAC. I have not signed up to spend my time on your project.And I am willing to looking at FLAC and spent my time to fix compiler warnings to make it more portable and fixing potential issue and you are being such a dick to me. As mentioned in my first mail I have some patches lined up. Very smart move to turn off a external contributor. Also I mentioned in my first mail, that I have no idea what the intention of that code is, so maybe just telling that instead of telling me might have given me the change to fix it myself and then submit that.> > Unless you disable this warning in your build system. > > Well, you can look at our build system for yourself, but I can assure > you that when I'm compiling FLAC in development (ie configured using > "./configure --enable-werror") I am compiling with: > > -Wall -Wextra -Wstrict-prototypes -Wmissing-prototypes > -Waggregate-return -Wcast-align -Wnested-externs -Wshadow -Wundef > -Wmissing-declarations -Wunreachable-code -Winline > -Wdeclaration-after-statement -WerrorWow...that's a lot. We had to disable just one warning for now. I got the feeling that list might have some obsolete ones in it.> > Just using > > autoconf or cmake instead of gcc/clang directly doesn't make them > > compiler behave differently - unless you tell them to ;) > > Our autotool build system generates at least one header file (config.h, > in the top level directory). Unless your build system generates the > exact same header file, the results will be different.I am aware of that and it appears you have no clue what autotool actually does, since the file won't be "the exact same header fiile" since autotool generates a completely different one for each system you use...> Our build system does not deisplay that warning (as you can easily > prove for yourself, hint trying building with "V=1 make" so see the > full compiler invocation). That should be the end of this discussion.The question is what version you are using officially since I haven't seen that warning before myself and I updated FLAC before and didn't get around to commit it in our project and I didn't see it then. I assume it's new to GCC 4.9.x and clang 3.5. LTS or not latest version don't carry that yet and I guess you will run into that yourself as soon as you update.