Hi, I must have been doing something wrong, I checked again and specifying the namespace explicitly works!
I also got errors in ssl.hpp related to accessing ssl_domain::pn_domain from connection_options::impl qpid-proton/proton-c/bindings/cpp/src/connection_options.cpp: In member function `void proton::connection_options::impl::apply(proton::connection&)': qpid-proton/proton-c/bindings/cpp/include/proton/ssl.hpp:125: error: `pn_ssl_domain_t* proton::internal::ssl_domain::pn_domain()' is protected qpid-proton/proton-c/bindings/cpp/src/connection_options.cpp:83: error: within this context qpid-proton/proton-c/bindings/cpp/include/proton/ssl.hpp:125: error: `pn_ssl_domain_t* proton::internal::ssl_domain::pn_domain()' is protected qpid-proton/proton-c/bindings/cpp/src/connection_options.cpp:94: error: within this context I think this is due to 'friend class connection_options' not allowing the inner private connection_options::impl class to access its private methods. For my purposes making pn_domain() public was sufficient. Thanks again for your help! Alexandre On ven., 2016-02-19 at 12:28 -0500, Alan Conway wrote: > On Thu, 2016-02-18 at 13:27 -0500, Andrew Stitcher wrote: > > On Wed, 2016-02-17 at 10:51 +0000, TRUFANOW Alexandre wrote: > > > Hi, > > > > > > I am attempting to compile proton and the C++ binding using GCC > > > 3.4 > > > > This is a very old compiler (from no later than 2006), and we don't > > test on it (although we are striving currently to support C++03). > > > > Going forward it is not too unlikely that we will move to using C++11 > > features for our implementation. So if you can use a more recent > > version of gcc (or clang) then you will be better off. > > > > > > > and > > > get the following error when compiling the C++ bindings. (compiler > > > flags > > > have been removed in proton-c/CMakeLists.txt: -pedantic-errors > > > -Wno-variadic-macros) > > > > > > > [ 33%] Building CXX object proton-c/bindings/cpp/CMakeFiles/qpid- > > > > proton-cpp.dir/src/acceptor.cpp.o > > > > In file included from /tmp/qpid-proton-0.12.0/proton- > > > > c/bindings/cpp/src/contexts.hpp:28, > > > > from /tmp/qpid-proton-0.12.0/proton- > > > > c/bindings/cpp/src/acceptor.cpp:26: > > > > /tmp/qpid-proton-0.12.0/proton- > > > > c/bindings/cpp/include/proton/container.hpp:129: error: > > > > declaration > > > > of `void proton::container::link_options(const > > > > proton::link_options&)' > > > > /tmp/qpid-proton-0.12.0/proton- > > > > c/bindings/cpp/include/proton/link_options.hpp:60: error: changes > > > > meaning of `link_options' from `class proton::link_options' > > > > make[2]: *** [proton-c/bindings/cpp/CMakeFiles/qpid-proton- > > > > cpp.dir/src/acceptor.cpp.o] Error 1 > > > > make[1]: *** [proton-c/bindings/cpp/CMakeFiles/qpid-proton- > > > > cpp.dir/all] Error 2 > > > > > > From what I understand, this is due to a clash between the class > > > proton::link_options and the method proton::container::link_options > > > which cannot have the same name. > > > > As far as I can tell (and the compilers we test on seem to agree) > > there > > is no name clash here (it is probably a name lookup bug in the > > compiler)! > > > > We came across this error (changes meaning) a lot when we were re- > naming things and it is probably not referring to the different > namespaces but to the fact that the unqualified name "link_options" is > being used to refer to two different things in the same context: a > member function and a class. > > > You could try explicitly making the declaration: > > > > void link_options(const proton::link_options&); > > I would have expected that to work since it makes the second use > qualified. You could try adding a "class" qualifier to tell the > compiler that you are *intentionally* referring to two different > things, that is what we usually do when there is a member function that > is also a class name: > > PN_CPP_EXTERN void link_options(const class link_options &); > > or maybe even > > PN_CPP_EXTERN void link_options(const class proton::link_options &); > > It might not work either but it just might sidestep the name resolution > quirks in the older compiler. If it does let us know and we'll include > the fix in next release. > ******************************* This e-mail contains information for the intended recipient only. It may contain proprietary material or confidential information. If you are not the intended recipient you are not authorised to distribute, copy or use this e-mail or any attachment to it. Murex cannot guarantee that it is virus free and accepts no responsibility for any loss or damage arising from its use. If you have received this e-mail in error please notify immediately the sender and delete the original email received, any attachments and all copies from your system.
