libcrypto/openssl : Which to use
adit267.kousik at ...9...
Sat May 9 06:35:40 CEST 2015
I've been able to successfully build the ndn-cxx library. I've created a
branch at https://github.com/adikou/genode/tree/ndn-cxx-port. 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.
A personal thank you to Norman Feske, Christian Helmuth, and Josef Söntgen,
(Emery for the sqlite port) for helping me along the whole way.
On Fri, May 8, 2015 at 2:51 PM, Aditya Kousik <adit267.kousik at ...9...>
> Hello Josef,
> 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.
> 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
> 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.
> The only undefined reference I'm facing now, is to sendmsg(), which I'm
> assuming is a similar misconfiguration issue.
> On Fri, May 8, 2015 at 2:50 AM, Josef Söntgen <
> josef.soentgen at ...1...> wrote:
>> Hello Aditya,
>> * Aditya Kousik <adit267.kousik at ...9...> [2015-05-07 17:08:00 -0700]:
>> > 2. Compilation of ndn-cxx goes fine (after adding ndn-cxx-config.hpp).
>> > The final set of errors are undefined references. I'm facing similar
>> > problems to the article written about porting SDL_net.
>> > undefined references to 'kqueue', 'kevent' and 'sendmsg'.
>> > I've found a few implementations of kqueue(), kevent() in the original
>> > repository : they're defined in kern_event.c which is not present in the
>> > current libc port. Same for sendmsg. I've been trying to add kevent and
>> > kqueue by changing the libc port by adding sys/kern to the list of
>> > and adding a mk file for the libc-kern component. I'm wondering if I
>> > go to the extent of doing this because just by looking at the code I can
>> > see that there will be a cascade of dependencies within sys/kern itself
>> > that I now have to deal with. Suggestions would help - I'm kind of lost
>> > with this exact decision that was mentioned in porting SDL_net.
>> That is the kernel side of FreeBSD's kqueue(2) implementation and is
>> not part of the libc. If you take a closer look at our libc you will
>> see that we actually implement the system call functions, i.e., we
>> provide the functionality normally expected from the kernel.
>> Therefore, your job would be to write the implementation of the kernel
>> side of kqueue(2) like it is done for, e.g., select(2) or rather
>> emulate its behaviour.
>> > The weirdest part in this, is that I can't seem to find the place in the
>> > ndn-cxx code that even makes a call or even includes sys/event.h. I
>> > the words 'kqueue', 'kevent' and 'sendmsg' and they're present in the
>> > object files but nowhere to be found in the source files!
>> Yeah, I bet boost uses kqueue and the like in its asynchronous I/O
>> backend because it thinks it is running on FreeBSD. Hence, you could
>> try to configure boost in such a way that it uses poll(2) or select(2)
>> (that would be the easy way) or you could extend the libc (the not so
>> easy way). Since you would not gain much performance-wise (*), I would
>> take the easy way.
>> > Part 2: Since the contrib/library-<hash>/ folder has both include/ as
>> > as src/ folder, which one actually becomes the INC_DIR in .mk file?
>> > whatever changes I made when I set the include/ folder as INC_DIR were
>> > getting reflected during compilation. So, there's a side query about
>> It depends on the include search path and how the headers are included.
>> If the header files are included locally, by using “#include "..."” that
>> is, the compiler might take them over the ones specified in INC_DIR.
>> So, the import .mk always should use the include/ directory. The lib or
>> target .mk should also always use the include/ directory but you might
>> have to overlay certain header files so that local ones in the src/
>> directory are not picked up if you make changes to them. Ideally,
>> changes to any files should be made _before_ they are copied to the
>> include/ directory when preparing the port.
>> (*) In our case, it really depends on how the backend is implemented
>> rather than which API is used.
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> genode-main mailing list
>> genode-main at lists.sourceforge.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users