Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
Explicitly force building in C++98 mode
GCC 6 defaults to C++14 (or more precisely, gnu++14) instead of C++98
(or gnu++98).

The fdk-aac source doesn't support being built in this mode at the
moment, since it relies on narrowing conversion from unsigned 32 bit
integers to FIXP_DBL (which is a signed data type of the same size).

The same approach is used upstream in Android as well, since
d52f374.

This fixes buliding with GCC 6.
  • Loading branch information
mstorsjo committed May 18, 2016
1 parent 8fe6faf commit 15b128d
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion Makefile.am
Expand Up @@ -12,7 +12,7 @@ AM_CPPFLAGS = \
-I$(top_srcdir)/libFDK/include \
-I$(top_srcdir)/libPCMutils/include

AM_CXXFLAGS = -fno-exceptions -fno-rtti
AM_CXXFLAGS = -fno-exceptions -fno-rtti -std=c++98
libfdk_aac_la_LINK = $(LINK) $(libfdk_aac_la_LDFLAGS)
# Mention a dummy pure C file to trigger generation of the $(LINK) variable
nodist_EXTRA_libfdk_aac_la_SOURCES = dummy.c
Expand Down

1 comment on commit 15b128d

@mstorsjo
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Try changing this to -std=c++11 (or remove this and build with GCC 6) - you'll get errors like these:

libAACenc/src/aacEnc_rom.cpp:661:1: error: narrowing conversion of ‘2180108801u’ from ‘unsigned int’ to ‘FIXP_DBL {aka int}’ inside { } [-Wnarrowing]

The fix in itself should be pretty straightforward I think, just add casts or rewrite the constants from unsigned form to a proper negative value instead.

I'm not too keen on merging fixes for this right now though.

Fraunhofer are aware of the issue and have told me they'll try to fix it at some point (but it's unsure in which code drop it appears). I'm trying to keep the diff to upstream as small as possible, to ease adoption of new versions from upstream, so unless there's some big drawback to just building it in C++98 mode as right now that I'm unaware of (the C++ness of the lib should only be an internal detail AFAIK), I'd just keep doing what we do now and hope for an update from upstream at some point.

Please sign in to comment.