Closed josch closed 8 years ago
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.
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.
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
.
I still have to update this in fuzzylite 5.0.
ping about the fix in fuzzylite 5.1... seems that the commits are not easily appliable on the latest stable release...
Thanks, but can you be more specific? What exactly is the problem?
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:
Thanks!
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.
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.
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.
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.
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?
The error messages I am having were part of my original issue report right at the top. Just click on the first link.
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.
@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 :)
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.
Thanks @LocutusOfBorg and @jcrada !
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
orstd::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