Fails to compile with gcc 6 due to deprecated std::auto_ptr

[josch]

Hi,

I was made aware that fuzzylite fails to build from source with gcc 6 on Debian:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811880

The reason seems to be that std::auto_ptr got deprecated in gcc 6 because it is deprecated in the C++0x standard. Instead, std::unique_ptr or std::shared_ptr should be used as appropriate. A good summary can be found in the following stackoverflow question:

http://stackoverflow.com/questions/2404115/is-auto-ptr-deprecated

Since gcc will probably not drop std::auto_ptr, one solution might be to just compile fuzzylite without -Wdeprecated-declarations.

The other, more long term solution would be to repace std::auto_ptr by the appropriate smart pointer.

Thanks!

cheers, josch

[jcrada]

Hi josch,

thank you for reporting the issue.

The std::auto_ptr is automatically replaced everywhere for std::unique_ptr when using C++11 and indicating fuzzylite about it via compiler flag -DFL_CPP11=ON. In the development version at master branch, I have set up the default to build fuzzylite using C++11. However, using gcc-6 installed in MacOSX Capitan via homebrew, I ran into this problem at linking time: ld: symbol(s) not found for architecture x86_64, which may be a bug in gcc-6. I still need to check this in Linux.

Despite the deprecation warning in gcc-6, I think it is convenient to maintain the option to build fuzzylite for C++98 using std::auto_ptr.

On a different matter, I am surprised gcc-6 is deprecating std::auto_ptr when compiling with C++99. What other option do we have when compiling with C++99? std::unique_ptr started from C++11, or C++0x at the earliest, I think.

[josch]

I'm not an expert either and I guess the only way would be using preprocessor directives. But if you say that setting -DFL_CPP11=ON fixes this, it seems that is already what you are doing.

[jcrada]

Hi josch, I had two problems: (1) The ld: symbol(s) not found for architecture x86_64 happened in Mac, and was missing -lstdc++ (2) The deprecation error occurs because gcc-6 compiles with C++11 by default, hence creating the deprecation errors. This has been fixed in CMakeLists.txt by setting -std=c++98 when -DFL_CPP11=OFF.

[jcrada]

I still have to update this in fuzzylite 5.0.

[LocutusOfBorg]

ping about the fix in fuzzylite 5.1... seems that the commits are not easily appliable on the latest stable release...

[jcrada]

Thanks, but can you be more specific? What exactly is the problem?

[josch]

The default compiler in the next Debian release (Stretch) is gcc 6. If fuzzylite 5.1 cannot be compiled with gcc 6 then it cannot be part of the next Debian release. So far, we were unable to backport your patches that make fuzzylite compile with gcc 6 to the 5.1 release. There are four options:

• I end up finding more time in the near future to backport the patches to the 5.1 release
• there is a new fuzzylite release with gcc 6 support
• somebody else (you?) finds some time to make fuzzylite 5.1 compile with gcc 6
• fuzzylite will not be part of the next Debian release (and neither will its reverse dependencies like vcmi)

Thanks!

[jcrada]

Hi josch. I was not aware there were issues with fuzzylite 5.1 on gcc-6. I thought these were resolved with the last commit the other day. Anyway, I have just pushed a new commit defaulting compilation to use FL_CPP11=ON. Still, projects using fuzzylite need to define -DFL_CPP11=ON to avoid issues. Could you please confirm this problem has been solved? Otherwise, I will reopen this issue.

[josch]

They were possibly solved but that commit doesn't apply on top of the 5.1 release. What I would like to have is a patch for the 5.1 release. The commits that appear in this bug seem to be full of patch hunks unrelated to fixing the gcc 6 problem for fuzzylite 5.1.

[jcrada]

As I stated before, the problem is not fuzzylite. The problem is that projects using fuzzylite and compiling with C++11 need to declare the -DFL_CPP11 compiling flag and make sure fuzzylite was compiled with C++11. Otherwise, the error will always appear. The fixes I have submitted are to define by default the -DFL_CPP11 for compilation of fuzzylite, but (again) projects using fuzzylite need to define -DFL_CPP11. Do you think you can work around this?

The alternative is to rename the FL_CPP11 flag to FL_CPP98 flag, so projects requiring C++98 will need to declare FL_CPP98, but this involves too many changes for a patch to fuzzylite 5.1, and ends up with the same problem: projects need to declare -FL_CPPXX=ON when they are compiling with C++98/11.

[josch]

The problem we have in Debian is, that we cannot compile fuzzylite with gcc 6.

The problem is not that we cannot compile software using fuzzylite.

[jcrada]

Do you have a docker image with gcc-6? I have gcc-6 in my mac OS and I am able to successfully build fuzzylite 5.1. Could you please open a new issue and post what error messages are you having?

[josch]

The error messages I am having were part of my original issue report right at the top. Just click on the first link.

[jcrada]

Hi @josch and @LocutusOfBorg, As I have insisted, the fuzzylite library is compiling just fine with g++-6 since the changes I incorporated when I closed this issue. Please, refer to the first four builds in https://travis-ci.org/fuzzylite/fuzzylite/builds/152015995, where you will find fuzzylite 5.1 compiling under g++-6 for the different four combinations of compilation flags, namely FL_USE_FLOAT=ON|OFF and FL_CPP11=ON|OFF.

Could you please revise your environments, and (if needed) create a new issue providing more information about the problems you are experiencing building fuzzylite? Thanks.

[LocutusOfBorg]

@jcrada thanks! actually I saw patches, and I was mostly sure 5.1 needed them. indeed adding FL_CPP11=ON fixes the issue @josch the build is not fine, and there are some symbols changes, I'll try to sort them out, with help from the Ubuntu patch https://patches.ubuntu.com/f/fuzzylite/fuzzylite_5.1+dfsg-3ubuntu1.patch

and NMU if everything is good :)

[jcrada]

Cool. @LocutusOfBorg, if there are symbol changes that is because fuzzylite is compiling with C++11 by default, probably changing pointer values from 0L to std::nullptr, or also using C++11 identifiers (e.g., override, delete). Also, please have in mind that I am reserving the SOVERSION=6 for the next release of fuzzylite 6. I know that it does not need to be related, but I really want it this way.

Please, let me know if there are any further issues. I was not aware you were waiting on this issue as I closed it a several months ago.

[josch]

Thanks @LocutusOfBorg and @jcrada !