Hello Aditya,
* Aditya Kousik <adit267.kousik@...9...> [2015-04-30 21:47:56 -0700]:
Thanks for the replies. Yes, right after I posted the mail, I noticed the native port of 'sqlite' already there. I just have four more dependencies to port. libpcap-dev, boost-1.5, dbus, and pkg-config. I've been creating port and hash files for these to download the sources, but writing the makefile is turning out to be a challenge.
How do I write a makefile for the targets, if the original compilation does a ./configure followed by make && make install. My main application is built with waf. So any input will help withdrew the porting.
There is a porting guide [1] that explains how to port libraries to Genode and features detailed examples. Basically, you just monitor what the original build system does, i.e., what flags are used, what source files are compiled and so on. The tricky part is to decide what actually is needed to use the library on Genode. For example, as you observed, there is no extra libdl on Genode. There is none because the mechanism libdl provides is already part of the libc [2]. You are just fine if you link the application using this library against it.
I do not know which application you are trying to port but when skimming your list of dependencies I can tell you right away you will not need to port pkg-config. What you probably need is the information pkg-config can give you on your host system, i.e., what compiler and linker flags are used that you *might* need to consider when porting the library. I can also tell you right away, that you probably end up writing a backend for dbus that can be used on Genode. Well, at least you have to figure out how to use the functionality that is already there or - depending on the requirements - how to extend it (*).
So, for better or worse, porting in general involves more than just wrapping up the original build system and writing a Makefile. But that is what makes porting fun, challenging and sometimes frustrating ☺
Regards Josef
[1] http://genode.org/documentation/developer-resources/porting [2] repos/libports/src/libc/dynamic_linker.cc
(*) Since there is no support for local UNIX sockets and our TCP/IP stack is directly linked against the application you most likely will not be able to reuse the POSIX backend without extending the libc.