sysml / clickos

The Click modular router: fast modular packet processing and analysis
http://www.read.cs.ucla.edu/click/
Other
136 stars 35 forks source link

Implementing a new element, which is using an external library, into ClickOS #14

Closed nszilard closed 8 years ago

nszilard commented 9 years ago

Hi everyone!

I'm trying to implement a new element, which is using an external library, that requires c++11 compiler. With Click, I could just simply build the library, then run make / make install commands to get my element working, but with ClickOS, I encountered with the following problem:

After I have built the library, I modified the "clickos/minios/config.mk.in" file as: CLICK_EXTRA_ELEMENT_GROUPS = etc/"My_element"/ , where "My_element" is the folder, where I have the .cc and .hh files and also the external library itself.

Then I run ./configure, make / make install commands but when I try to build the ClickOS image with make minios, I get the following error:

error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.

But if I configure ClickOS like this: ./configure CXXFLAGS="-std=c++11" --enable-minios --enable-local --with-xen=$XEN_ROOT --with-linux=/home/$USER/linux-3.16.7 --with-linux-map=/home/$USER/linux-3.16.7 I still get the same error.

So my question would be, how could I implement a new element that is using an external library into ClickOS?

Thanks in advance for help, Szilárd

fmanco commented 9 years ago

Hello

I need more information about the actual issue. Can you please post the output of the build (in verbose mode)? Also which external libraries are you compiling in, etc.

Best Filipe

nszilard commented 9 years ago

I'm trying to use Kodo network coding library and use a modified makefile that contains flags based on its manual that can be seen in point 8 here: http://kodo-docs.steinwurf.com/en/latest/including_kodo_in_your_application.html.

In the meanwhile I've kept trying and now I think I can concretize the problem a bit more: I can compile with this command in Click: g++ -std=gnu++11 -fPIC -DCLICK_USERLEVEL -DPACKAGE_NAME=\"click-samplepackage\" -DPACKAGE_TARNAME=\"click-samplepackage\" -DPACKAGE_VERSION=\"2.0.1\" -DPACKAGE_STRING=\"click-samplepackage\ 2.0.1\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DHAVE_CONFIG_H -I . -I ../elements/nc/ -I /usr/local/include -I /usr/local/share/click/src -I ../elements/nc/kodo/bundle_dependencies/boost-abe3de/1.11.0 -I ../elements/nc/kodo/bundle_dependencies/sak-1bdcea/14.0.1/src -I ../elements/nc/kodo/bundle_dependencies/fifi-8960fd/19.0.0/src -I ../elements/nc/kodo/src -I ../elements/nc/kodo/bundle_dependencies/platform-bccd32/1.3.0/src -I ../elements/nc/kodo/bundle_dependencies/cpuid-4d8071/3.3.1/src -I ../elements/nc/kodo/bundle_dependencies/recycle-b2469b/1.2.0/src -MD -MP -c ../elements/nc/common_functions.cc -o ~/clickos/minios/build/click/elements/common_functions.o

for the minios however, I have to use additional includes and -D flags, that requires the presence of -I /home/szilard/clickos/include flag. This eventuates erros. If I try to run the g++ command above with the additional -I /home/szilard/clickos/include using a built-in click .cc file, then it will compile it. However, if I change this element to my common_function.cc then I get the following error:

In file included from ~/mini-os/include/errno.h:116:0, from ~/mini-os/include/arch/cc.h:17, from ~/toolchain/x86_64-root/x86_64-xen-elf/include/lwip/lwip/arch.h:43, from ~/toolchain/x86_64-root/x86_64-xen-elf/include/lwip/lwip/debug.h:35, from ~/toolchain/x86_64-root/x86_64-xen-elf/include/lwip/lwip/opt.h:46, from ~/toolchain/x86_64-root/x86_64-xen-elf/include/lwip/lwip/sockets.h:37, from ~/mini-os/include/posix/netinet/in.h:5, from /usr/local/include/clicknet/ip.h:12, from ../elements/nc/common_functions.cc:23: /usr/include/c++/4.9/bits/stl_iterator.h: In constructor ‘std::reverse_iterator<_Iterator>::reverse_iterator()’: /usr/include/c++/4.9/bits/stl_iterator.h:121:28: error: class ‘std::reverse_iterator<_Iterator>’ does not have any field named ‘get_current’ reverse_iterator() : current() { }

This is strange, because when I try to build a built-in Click element which also uses the #include <clicknet/ip.h> directive then I did not get any error message.

If you need any further information then please let me know. Thanks in advance for the help!

fmanco commented 9 years ago

So if I understand it correctly you can compile this element for user-level click, but not for minios. Correct?

Can you try to compile for linuxmodule. Also can you provide the full output of the compilation in verbose mode both for userlevel and minios?

I think the problem here is that the library uses STL which AFAIK is not supported in the minios driver. If you check minios/stub.mk you can see -nostdinc being defined.

nszilard commented 9 years ago

Yes, you are right, we compiled successfully the element for user level (we didn't even tried as linuxmodule because the userlevel was fine for us)

We checked the minios/stub.mk file and it really comprises the -nostdinc flag but only as a CFLAGS but we are not sure whether this causes the errors because we have cc files which requires g++. Nevertheless we can managed to create a simple file that contains only one line (#include ) which produces the same error (attached as compile.out). So we think if we could address this issue then we could compile the original files as well.

We also attach the output of the user level compilation of the click element which also use the library "functional" (through the calls of the third party library kodo). This is the one without errors.

As we understand it correctly minios is not prepared for this if so then does a workaround exist?

Thanks in advance

click_element_build : http://pastebin.com/fx6G3qiS

compile.out : http://pastebin.com/bMYC1q7e

fmanco commented 9 years ago

Hi

I guess the problem comes from using the standard C++ libs from the system. We compile MiniOS with Newlib as opposed to glibc and I think that's what causing problems.

MiniOS is indeed not prepared for this. In the past we managed to compile a full toolchain using Newlib, that way we could use the standard c++ libraries. Unfortunately we don't have any code/makefiles for this anymore, but it shouldn't be very difficult to achieve. You can maybe give it a try.

Best

fmanco commented 8 years ago

Hi, do have updates. Should I close this?

Thanks