libcrypto/openssl : Which to use

[Aditya Kousik]

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/f04927cf/attachment.html>