<div dir="ltr">Hello all,<div><br></div><div>I've been able to successfully build the ndn-cxx library. I've created a branch at <a href="https://github.com/adikou/genode/tree/ndn-cxx-port" target="_blank">https://github.com/adikou/genode/tree/ndn-cxx-port</a>. I've also added a README in repos/libports/test/ndn-cxx-hacks explaining what needs to be done to get the build working without errors. It involves a heavy number of tweaks rather than valid translations. I decided to make do with that, for now. I aim to build a couple of test cases to test the validity of the port. I'll get back with what I find.</div><div>A personal thank you to Norman Feske, Christian Helmuth, and Josef <span style="font-size:12.8000001907349px;white-space:nowrap">Söntgen, (Emery for the sqlite port) for helping me along the whole way. </span><br></div><div><span style="font-size:12.8000001907349px;white-space:nowrap"><br></span></div><div><span style="font-size:12.8000001907349px;white-space:nowrap">Cheers,</span></div><div><span style="font-size:12.8000001907349px;white-space:nowrap">Aditya.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 8, 2015 at 2:51 PM, Aditya Kousik <span dir="ltr"><<a href="mailto:adit267.kousik@...9..." target="_blank">adit267.kousik@...9...</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello Josef,<div><br></div><div>The porting task is challenging, but interesting. For some reason or the other, during preprocessing, boost kept configuring its files into BSD. This happens because one of #if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__) || defined(__DragonFly__) is throwing TRUE, so the boost configuration follows BSD and hence, was including kqueue. </div><div><br></div><div>Fortunately for me, the hierarchy of config was convenient. There's one reactor.hpp which includes either epoll_reactor, or kqueue_reactor, or dev_poll_reactor, or most importantly - the default was select_reactor.hpp which uses the select call. I was able to fix this by hacking at the config files.</div><div><br></div><div>Which brings me to a general question: How is the build system isolated from the host configurations? How are the preprocess primitives supposed to respond? Can we include a genode-sepcific configuration file to help build in such cases - to direct output of such definitions.</div><div><br></div><div>The only undefined reference I'm facing now, is to sendmsg(), which I'm assuming is a similar misconfiguration issue.</div><div><br></div><div>Cheers,</div><div>Aditya</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 8, 2015 at 2:50 AM, Josef Söntgen <span dir="ltr"><<a href="mailto:josef.soentgen@...1..." target="_blank">josef.soentgen@...1...</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Aditya,<br>
<br>
* Aditya Kousik <<a href="mailto:adit267.kousik@...9..." target="_blank">adit267.kousik@...9...</a>> [2015-05-07 17:08:00 -0700]:<br>
<span><br>
> 2.  Compilation of ndn-cxx goes fine (after adding ndn-cxx-config.hpp).<br>
> The final set of errors are undefined references. I'm facing similar<br>
> problems to the article written about porting SDL_net.<br>
> undefined references to 'kqueue', 'kevent' and 'sendmsg'.<br>
><br>
</span><span>> I've found a few implementations of kqueue(), kevent() in the original libc<br>
> repository : they're defined in kern_event.c which is not present in the<br>
> current libc port. Same for sendmsg. I've been trying to add kevent and<br>
> kqueue by changing the libc port by adding sys/kern to the list of exports<br>
> and adding a mk file for the libc-kern component. I'm wondering if I should<br>
> go to the extent of doing this because just by looking at the code I can<br>
> see that there will be a cascade of dependencies within sys/kern itself<br>
> that I now have to deal with. Suggestions would help - I'm kind of lost<br>
> with this exact decision that was mentioned in porting SDL_net.<br>
<br>
</span>That is the kernel side of FreeBSD's kqueue(2) implementation and is<br>
not part of the libc. If you take a closer look at our libc you will<br>
see that we actually implement the system call functions, i.e., we<br>
provide the functionality normally expected from the kernel.<br>
Therefore, your job would be to write the implementation of the kernel<br>
side of kqueue(2) like it is done for, e.g., select(2) or rather<br>
emulate its behaviour.<br>
<span><br>
> The weirdest part in this, is that I can't seem to find the place in the<br>
> ndn-cxx code that even makes a call or even includes sys/event.h. I grepped<br>
> the words 'kqueue', 'kevent' and 'sendmsg' and they're present in the<br>
> object files but nowhere to be found in the source files!<br>
<br>
</span>Yeah, I bet boost uses kqueue and the like in its asynchronous I/O<br>
backend because it thinks it is running on FreeBSD. Hence, you could<br>
try to configure boost in such a way that it uses poll(2) or select(2)<br>
(that would be the easy way) or you could extend the libc (the not so<br>
easy way). Since you would not gain much performance-wise (*), I would<br>
take the easy way.<br>
<span><br>
> Part 2: Since the contrib/library-<hash>/ folder has both include/ as well<br>
> as src/ folder, which one actually becomes the INC_DIR in .mk file? Because<br>
> whatever changes I made when I set the include/ folder as INC_DIR were not<br>
> getting reflected during compilation. So, there's a side query about that.<br>
<br>
</span>It depends on the include search path and how the headers are included.<br>
If the header files are included locally, by using “#include "..."” that<br>
is, the compiler might take them over the ones specified in INC_DIR.<br>
<br>
So, the import .mk always should use the include/ directory. The lib or<br>
target .mk should also always use the include/ directory but you might<br>
have to overlay certain header files so that local ones in the src/<br>
directory are not picked up if you make changes to them. Ideally,<br>
changes to any files should be made _before_ they are copied to the<br>
include/ directory when preparing the port.<br>
<br>
<br>
Regards<br>
Josef<br>
<br>
(*) In our case, it really depends on how the backend is implemented<br>
    rather than which API is used.<br>
<div><div><br>
------------------------------------------------------------------------------<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href="http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target="_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>
_______________________________________________<br>
genode-main mailing list<br>
<a href="mailto:genode-main@lists.sourceforge.net" target="_blank">genode-main@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/genode-main" target="_blank">https://lists.sourceforge.net/lists/listinfo/genode-main</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>