libcrypto/openssl : Which to use

[Aditya Kousik]

Hello all,

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.

Cheers,
Aditya.

On Fri, May 8, 2015 at 2:51 PM, Aditya Kousik <adit267.kousik at ...9...>
wrote:

> 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
> files.
>
> 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.
>
> Cheers,
> Aditya
>
> 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
>> libc
>> > 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
>> exports
>> > and adding a mk file for the libc-kern component. I'm wondering if I
>> should
>> > 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
>> grepped
>> > 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
>> well
>> > as src/ folder, which one actually becomes the INC_DIR in .mk file?
>> Because
>> > whatever changes I made when I set the include/ folder as INC_DIR were
>> not
>> > getting reflected during compilation. So, there's a side query about
>> that.
>>
>> 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.
>>
>>
>> Regards
>> Josef
>>
>> (*) 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.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> _______________________________________________
>> genode-main mailing list
>> genode-main at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20150508/fbbea893/attachment.html>