Can't compile debuggergdb.o on Mac OS Yosemite!

[Easior Lars]

Hello, everyone.

It's well-known that the binary ball of Code::Blocks on Mac OS is out-of-date. Some bugs are needed to be fixed. e.g. Changing the font of Editor in Code::Blocks makes it crash. Hence I try to build Code::Blocks from source codes on Mac OS Yosemite.

Firstly, I install wxmac by homebrew and download codeblocks_13.12-1.tar.gz from SF.net and unpack it somewhere. Following the instructions on http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Mac_OS_X and applying some patches, then I run the following command lines in the terminal:

Code

$ mkdir cocobuild & cd cocobuild
$ ../configure --prefix="${HOME}/Developer/CodeBlocks" --with-contrib-plugins="yes,-FileManager,-NassiShneiderman,-spellchecker" CXXFLAGS='-D _WCHAR_H_CPLUSPLUS_98_CONFORMANCE_'
$ make

It is no lucky for me. The debuggergdb plugin is failed to compile with the following error:

Code

../../../../src/include/prep.h:33:75: error: use of overloaded operator '==' is ambiguous (with operand types 'const std::__1::shared_ptr<GDBWatch>' and 'int')
        template<typename T> bool equals(T const& rhs) const { return rhs == 0; }
                                                                      ~~~ ^  ~
../../../../src/include/prep.h:44:99: note: in instantiation of function template specialization 'nullptr_t::equals<std::__1::shared_ptr<GDBWatch> >' requested here
    template<typename T> inline bool operator==(T const& lhs, const nullptr_t& rhs) { return  rhs.equals(lhs); }
                                                                                                  ^
../../../../src/plugins/debuggergdb/debuggergdb.cpp:501:27: note: in instantiation of function template specialization 'operator==<std::__1::shared_ptr<GDBWatch> >' requested here
        if (m_localsWatch == nullptr)
                          ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:4765:1: note: candidate function [with _Tp = GDBWatch]
operator==(const shared_ptr<_Tp>& __x, nullptr_t) _NOEXCEPT
^
../../../../src/include/prep.h:33:75: note: built-in candidate operator==(int, int)
        template<typename T> bool equals(T const& rhs) const { return rhs == 0; }

Anyone know what happened?

[oBFusCATed]

There is a declaration of nullptr_t class in prep.h.
You'll have to check if the conditionals are correct for you compiler.
I guess it should detect that this feature is present in clang and not use it.

Probably #include <stddef.h> is missing and should be added in an else clause.

[Easior Lars]

There is a declaration of nullptr_t class in prep.h.
You'll have to check if the conditionals are correct for you compiler.
I guess it should detect that this feature is present in clang and not use it.

Probably #include <stddef.h> is missing and should be added in an else clause.

You are right about the existence of the conditionals in prep.h, however there isn't an else clause. In fact, the codes you mentioned are as follows:

Code

#if    !(__GNUC__ == 4 && __GNUC_MINOR__ >= 6 && defined __GXX_EXPERIMENTAL_CXX0X__) \
    && !(defined(__clang__) && __has_feature(cxx_nullptr))
    // it is a const object...
    const class nullptr_t
    {
    public:
        // constructor
        nullptr_t() {}
        // convertible to any type of null non-member pointer...
        template<typename T> operator T* () const{ return (T*)0; }
        // or any type of null member pointer...
        template<typename C, typename T> operator T C::* () const { return (T C::*)0; }
        // support operator overloading (== and !=)
        template<typename T> bool equals(T const& rhs) const { return rhs == 0; }
    private:
        // can't take address of nullptr
        void operator&() const;
        // can't copyable
        nullptr_t(const nullptr_t&);
        const nullptr_t& operator=(const nullptr_t&);
    } nullptr_;
    #define nullptr nullptr_

    template<typename T> inline bool operator==(const nullptr_t& lhs, T const& rhs) { return  lhs.equals(rhs); }
    template<typename T> inline bool operator==(T const& lhs, const nullptr_t& rhs) { return  rhs.equals(lhs); }
    template<typename T> inline bool operator!=(const nullptr_t& lhs, T const& rhs) { return !lhs.equals(rhs); }
    template<typename T> inline bool operator!=(T const& lhs, const nullptr_t& rhs) { return !rhs.equals(lhs); }
#endif

It's unfortunate that I can't figure out where the #include <stddef.h> should be added. In other words, I don't know how to fix it.
Could you tell me how to check if the conditionals are correct for my compiler?

[oBFusCATed]

Place an #error line inside the conditionals.
One thing you could do to verify that this is causing the problem is to include stddef.h/cstddef.h in the cpp file fails to compile.

[Easior Lars]

There is a declaration of nullptr_t class in prep.h.
You'll have to check if the conditionals are correct for you compiler.
I guess it should detect that this feature is present in clang and not use it.

I have known what happened. Clang++ is the default compiler of Xcode 6 on Mac OS. There are some different implements of shared_ptr under different C++ standards. For compiling debuggergdb.o, CXXFLAGS="-std=c++11" is needed.

[oBFusCATed]

This is a very complex matter.
First we should know which c++ std lib is used to compile all dependencies of cb (wxwidgets in particular).
Then we'll have to compile everything with that library.

Do you know if the libstdc++ available on osx has the tr1 extensions?

[Easior Lars]

This is a very complex matter.
First we should know which c++ std lib is used to compile all dependencies of cb (wxwidgets in particular).
Then we'll have to compile everything with that library.

Firstly, I means that I can successfully build Code::Blocks from SVN repository by the below command lines

Code: bash

$ ./configure --prefix="${HOME}/Developer/CodeBlocks" \
             --with-contrib-plugins="yes,-FileManager,-NassiShneiderman,-spellchecker" \
                   CXXFLAGS='-std=c++11'
$ make

with wxWidgets 3.0.2 installed from homebrew. The following codes

Code: c++

// Add std::shared_ptr in a namespace, so different implementations can be used with different compilers
namespace cb
{
#if __cplusplus >= 201103L || defined(_LIBCPP_VERSION)
    using std::shared_ptr;
    using std::static_pointer_cast;
    using std::weak_ptr;
#else
    using std::tr1::shared_ptr;
    using std::tr1::static_pointer_cast;
    using std::tr1::weak_ptr;
#endif
}

in prep.h are why I have said that the different c++ standard has different implement of share_ptr.

Do you know if the libstdc++ available on osx has the tr1 extensions?

I can't answer your question because my c++ knowledge is not enough to properly use smart point. Maybe, you can give me a example to check whether libstdc++ is available on OS X. However, I guess it's Yes.

Till tonight, I have made a lot of *.cbps for Code::Blocks source codes and CB plugins on Mac OS X. The mac_pack under src directory of source codes was updated to mac_pack30 by me. I don't know how to commit them to the CB repository. In virtue of those files likewise on MS Windows, I have made a SVN version of CB binary bundle on Yosemite. Unfortunately, The CodeBlocks.app is full of bugs. For examples, a lots of *.xrc for plugins are lost. Changing font size of CB Editor makes CodeBlocks.app crash. Is it a proper way to discuss those problems in this thread on CB forum?

[Easior Lars]

Do you know if the libstdc++ available on osx has the tr1 extensions?

I do some research. The quick answer is
http://stackoverflow.com/questions/13445742/apple-and-shared-ptr.
I also look at the directory of Xcode SDK for tr1/memory, 

Code: bash

$ cd /Applications/Xcode.app/Contents/
$ find  . -iname 'memory' | grep  MacOSX
./Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/c++/4.2.1/ext/memory
./Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/c++/4.2.1/memory
./Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/c++/4.2.1/tr1/memory
./Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1/ext/memory
./Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1/memory
./Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1/tr1/memory

It assures my guess.

[Easior Lars]

This is a very complex matter.
First we should know which c++ std lib is used to compile all dependencies of cb (wxwidgets in particular).
Then we'll have to compile everything with that library.

Now, everything seems clear to me. My wxWidgets is installed by homebrew with clang's default c++ std library, i.e.

Code: bash

$ otool -L libwx_osx_cocoau_core-3.0.dylib | grep libc
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)

The g++ compiler afforded by Xcode is the same as clang++. Let's check the default c++ standard and _LIBCPP_VERSION:

Code: bash

$ nano -w teststd.cpp
#include <iostream>
int main() {
  std::cout << __cplusplus << "\n";
  std::cout << _LIBCPP_VERSION << "\n";
}
$ g++ teststd.cpp
$ ./a.out
199711
1101

it means that smart points in cb namespace should be offered by C++ header tr1/memory. The fact that tr1::shared_ptr is included in libstdc++ is why we can't build CB on Mac OS Yosemite. So using -std=c++11 is the solution.

Another solution is to build wxWidgets and Code::Blocks along with options -stdlib=libstdc++.