Hello
I'm trying to port libsqlite which is a dependency for another application (which I'm also trying to port). The build of this library is a one line compilation. But it requires a -ldl flag for dynamically loaded libraries (it uses dlopen() and dlfcn.h). I've tried getting the source for this, to no avail so far. Is there a way to link libraries directly from the linux host. Intuitively, that doesn't seem to work. Thoughts on how to move forward?
Thanks and regards, Aditya
On Thu, Apr 30, 2015 at 04:31:34PM -0700, Aditya Kousik wrote:
Hello
I'm trying to port libsqlite which is a dependency for another application (which I'm also trying to port). The build of this library is a one line compilation. But it requires a -ldl flag for dynamically loaded libraries (it uses dlopen() and dlfcn.h). I've tried getting the source for this, to no avail so far. Is there a way to link libraries directly from the linux host. Intuitively, that doesn't seem to work. Thoughts on how to move forward?
Thanks and regards, Aditya
Hey
I'm assuming you are using Noux, but I have a native sqlite port arleady. https://github.com/genodelabs/genode/issues/1398
I haven't used Noux in a while but I think you could link to a native library. Right now my port only uses the native file system session, but I have the libc VFS code and I've been meaning to make two version of library for either method. If thats useful I could get that done that in the next day or two.
Emery
I don't know everything about Genode, but it sounds like I can maybe help you. Libdl/dlfcn is part of glibc. You can download the source code here: https://sourceware.org/git/?p=glibc.git;a=tree;f=dlfcn;h=f7d4dfdce29d99c2221... Genode includes a dynamic linker, so you could possibly implement the dlfcn functions yourself (if you do so, please share your code), you could see if someone who understands the dynamic linker better could do it, or you could try to find a workaround. Note that Genode's libc does have dlfcn.h, but the default implementation just gives an error message.
On Thu, Apr 30, 2015 at 11:31 PM, Aditya Kousik <adit267.kousik@...9...> wrote:
Hello
I'm trying to port libsqlite which is a dependency for another application (which I'm also trying to port). The build of this library is a one line compilation. But it requires a -ldl flag for dynamically loaded libraries (it uses dlopen() and dlfcn.h). I've tried getting the source for this, to no avail so far. Is there a way to link libraries directly from the linux host. Intuitively, that doesn't seem to work. Thoughts on how to move forward?
Thanks and regards, Aditya
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
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.
Thanks, Aditya On Apr 30, 2015 9:05 PM, "Nobody III" <hungryninja101@...9...> wrote:
I don't know everything about Genode, but it sounds like I can maybe help you. Libdl/dlfcn is part of glibc. You can download the source code here: https://sourceware.org/git/?p=glibc.git;a=tree;f=dlfcn;h=f7d4dfdce29d99c2221... Genode includes a dynamic linker, so you could possibly implement the dlfcn functions yourself (if you do so, please share your code), you could see if someone who understands the dynamic linker better could do it, or you could try to find a workaround. Note that Genode's libc does have dlfcn.h, but the default implementation just gives an error message.
On Thu, Apr 30, 2015 at 11:31 PM, Aditya Kousik <adit267.kousik@...9...> wrote:
Hello
I'm trying to port libsqlite which is a dependency for another application (which I'm also trying to port). The build of this library is a one line compilation. But it requires a -ldl flag for dynamically loaded libraries (it uses dlopen() and dlfcn.h). I've tried getting the source for this, to no avail so far. Is there a way to link libraries directly from the linux host. Intuitively, that doesn't seem to work. Thoughts on how to move forward?
Thanks and regards, Aditya
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
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.
Well, it seems that I was mostly wrong about dlfcn functions not being implemented. That's nice to know. 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.
------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
If I get the order of the .port and libports/lib/mk/<port-name>.mk right, DIRS and DIRS_CONTENT are the generated/copied headers during the build; and INC_DIR in the .mk file configures make to look at the current folder for local includes.
I'm asking this because if the include files that appear in contrib-<hash>/src/lib/include have multiple dependencies, the build will still work, right? I'm guessing the headers in the DIRS are just for the genode application to include and the build system takes the actual src while compiling.
Thanks, Aditya
On Sat, May 2, 2015 at 7:52 AM, Nobody III <hungryninja101@...9...> wrote:
Well, it seems that I was mostly wrong about dlfcn functions not being implemented. That's nice to know. 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 [image: ☺]
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.
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello Aditya,
* Aditya Kousik <adit267.kousik@...9...> [2015-05-04 20:15:16 -0700]:
If I get the order of the .port and libports/lib/mk/<port-name>.mk right, DIRS and DIRS_CONTENT are the generated/copied headers during the build; and INC_DIR in the .mk file configures make to look at the current folder for local includes.
Yes, directories in DIRS get populated from the content in DIRS_CONTENT while preparing the port. Basically, the populated include directory should only contain the files that are needed on Genode. The same goes for the src directory, although we do not do that for most small libraries/applications but only for larger ones (VirtualBox, Linux sources etc).
I'm asking this because if the include files that appear in contrib-<hash>/src/lib/include have multiple dependencies, the build will still work, right? I'm guessing the headers in the DIRS are just for the genode application to include and the build system takes the actual src while compiling.
Actually, these header files are also used by the library/application itself. If the libraries depend on other libraries you only have to add the library to the LIBS variable in the .mk file and the build system will try to pick up the matching import-<port-name>.mk file. This in return will extend INC_DIR, that is used by the build system to generate the right compiler flags.
On that account, the INC_DIR variable in the import file should only contain the public header paths used by other libraries/applications. In the lib/target.mk file it is fine to point the build system and thereby the compiler to other directories in addition, e.g. $(REP_DIR)/src/lib/<port-name> or even contrib-<hash>/src. In this regard, the SDL port is a good example.
Regards Josef
Thank you for the response. I've sort of generated a port for a part of the boost libraries. It builds the src/lib/boost in the contrib folder, the dummy application links the library also. (How do I run applications built on linux_x86 platform?) The boost libraries are mainly .hpp files. By dependencies, I meant, header files #including other header files.
For instance: for simplicity, if I set DIRS_CONTENT(include/regex) := src/lib/boost/boost/regex/regex.hpp. But the actual header file simply has more includes to header files in the same directory, does the build system recognise this?
Cheers Aditya On May 4, 2015 22:56, "Josef Söntgen" <josef.soentgen@...1...> wrote:
Hello Aditya,
- Aditya Kousik <adit267.kousik@...9...> [2015-05-04 20:15:16 -0700]:
If I get the order of the .port and libports/lib/mk/<port-name>.mk right, DIRS and DIRS_CONTENT are the generated/copied headers during the build; and INC_DIR in the .mk file configures make to look at the current folder for local includes.
Yes, directories in DIRS get populated from the content in DIRS_CONTENT while preparing the port. Basically, the populated include directory should only contain the files that are needed on Genode. The same goes for the src directory, although we do not do that for most small libraries/applications but only for larger ones (VirtualBox, Linux sources etc).
I'm asking this because if the include files that appear in contrib-<hash>/src/lib/include have multiple dependencies, the build will still work, right? I'm guessing the headers in the DIRS are just for the genode application to include and the build system takes the actual src while compiling.
Actually, these header files are also used by the library/application itself. If the libraries depend on other libraries you only have to add the library to the LIBS variable in the .mk file and the build system will try to pick up the matching import-<port-name>.mk file. This in return will extend INC_DIR, that is used by the build system to generate the right compiler flags.
On that account, the INC_DIR variable in the import file should only contain the public header paths used by other libraries/applications. In the lib/target.mk file it is fine to point the build system and thereby the compiler to other directories in addition, e.g. $(REP_DIR)/src/lib/<port-name> or even contrib-<hash>/src. In this regard, the SDL port is a good example.
Regards Josef
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
I'm facing some issues trying to compile the library. In the lib/mk folder, I've added a boost.mk file, which I initially did not set SRC_CC to any value since most of the boost libraries are inline functions. But some components need to be built, so when I added a sample file like this:
BOOST_DIR = $(call select_from_ports,boost)/src/lib/boost SRC_CC := $(BOOST_DIR)/libs/chrono/src/*.cc INC_DIR += $(BOOST_DIR) vpath %.cc $(BOOST_DIR)/libs/chrono/src LIBS += libc SHARED_LIB = yes
During build, it gives me the following error Library boost MERGE boost.lib.so /usr/local/genode-gcc/bin/genode-x86-ld: cannot find /media/adikou/work/proj/genode/contrib/boost-ccb441998a237b6f3a301a2fd5956aca99eb9bc8/src/lib/boost/libs/chrono/src/*.o: No such file or directory
On Mon, May 4, 2015 at 11:04 PM, Aditya Kousik <adit267.kousik@...9...> wrote:
Thank you for the response. I've sort of generated a port for a part of the boost libraries. It builds the src/lib/boost in the contrib folder, the dummy application links the library also. (How do I run applications built on linux_x86 platform?) The boost libraries are mainly .hpp files. By dependencies, I meant, header files #including other header files.
For instance: for simplicity, if I set DIRS_CONTENT(include/regex) := src/lib/boost/boost/regex/regex.hpp. But the actual header file simply has more includes to header files in the same directory, does the build system recognise this?
Cheers Aditya On May 4, 2015 22:56, "Josef Söntgen" <josef.soentgen@...1...> wrote:
Hello Aditya,
- Aditya Kousik <adit267.kousik@...9...> [2015-05-04 20:15:16 -0700]:
If I get the order of the .port and libports/lib/mk/<port-name>.mk
right,
DIRS and DIRS_CONTENT are the generated/copied headers during the build; and INC_DIR in the .mk file configures make to look at the current
folder
for local includes.
Yes, directories in DIRS get populated from the content in DIRS_CONTENT while preparing the port. Basically, the populated include directory should only contain the files that are needed on Genode. The same goes for the src directory, although we do not do that for most small libraries/applications but only for larger ones (VirtualBox, Linux sources etc).
I'm asking this because if the include files that appear in contrib-<hash>/src/lib/include have multiple dependencies, the build
will
still work, right? I'm guessing the headers in the DIRS are just for the genode application to include and the build system takes the actual src while compiling.
Actually, these header files are also used by the library/application itself. If the libraries depend on other libraries you only have to add the library to the LIBS variable in the .mk file and the build system will try to pick up the matching import-<port-name>.mk file. This in return will extend INC_DIR, that is used by the build system to generate the right compiler flags.
On that account, the INC_DIR variable in the import file should only contain the public header paths used by other libraries/applications. In the lib/target.mk file it is fine to point the build system and thereby the compiler to other directories in addition, e.g. $(REP_DIR)/src/lib/<port-name> or even contrib-<hash>/src. In this regard, the SDL port is a good example.
Regards Josef
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Aditya,
On 05/05/2015 05:18 PM, Aditya Kousik wrote:
SRC_CC := $(BOOST_DIR)/libs/chrono/src/*.cc
...
/usr/local/genode-gcc/bin/genode-x86-ld: cannot find /media/adikou/work/proj/genode/contrib/boost-ccb441998a237b6f3a301a2fd5956aca99eb9bc8/src/lib/boost/libs/chrono/src/*.o: No such file or directory
you cannot use '*.cc' as wildcard but you may use make's '$(wildcard ...)' function instead.
Cheers Norman
Wow. That worked, but opened a huge can of worms. For some reason or the other, the compiler can't include <cstddef> or <utility> or such _cplusplus based headers. Could this be a C++ version issue?
Thanks, Aditya
On Tue, May 5, 2015 at 8:29 AM, Norman Feske <norman.feske@...1...> wrote:
Hi Aditya,
On 05/05/2015 05:18 PM, Aditya Kousik wrote:
SRC_CC := $(BOOST_DIR)/libs/chrono/src/*.cc
...
/usr/local/genode-gcc/bin/genode-x86-ld: cannot find
/media/adikou/work/proj/genode/contrib/boost-ccb441998a237b6f3a301a2fd5956aca99eb9bc8/src/lib/boost/libs/chrono/src/*.o:
No such file or directory
you cannot use '*.cc' as wildcard but you may use make's '$(wildcard ...)' function instead.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Aditya,
On 05/05/2015 05:41 PM, Aditya Kousik wrote:
Wow. That worked, but opened a huge can of worms. For some reason or the other, the compiler can't include <cstddef> or <utility> or such _cplusplus based headers. Could this be a C++ version issue?
it may be less obscure. I guess that you will need to add the standard C++ library 'stdcxx' (from repos/libports/) to 'LIBS'.
Cheers Norman
My goodness, I'm glad it's daytime in Dresden. Thank you, Dr. Norman. I assumed libc would have the std headers; Adding stdcxx helped. It's tough to keep track of which features of linux are already included in the LIBS I've added. stdcxx still throws undefined references for the math functions (how do I include the -lm version of Genode?) For instance, a fundamental linking in most of the applications is -lrt. Is this available? And also, is there a track of ported libraries, so I don't bug the list with every roadblock I hit.
Cheers Aditya
On Tue, May 5, 2015 at 8:55 AM, Norman Feske <norman.feske@...1...> wrote:
Hi Aditya,
On 05/05/2015 05:41 PM, Aditya Kousik wrote:
Wow. That worked, but opened a huge can of worms. For some reason or the other, the compiler can't include <cstddef> or <utility> or such _cplusplus based headers. Could this be a C++ version issue?
it may be less obscure. I guess that you will need to add the standard C++ library 'stdcxx' (from repos/libports/) to 'LIBS'.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello Aditya,
On Tue, May 05, 2015 at 09:13:19AM -0700, Aditya Kousik wrote:
My goodness, I'm glad it's daytime in Dresden. Thank you, Dr. Norman. I assumed libc would have the std headers; Adding stdcxx helped. It's tough to keep track of which features of linux are already included in the LIBS I've added. stdcxx still throws undefined references for the math functions (how do I include the -lm version of Genode?)
the dependency to libm is missing from the declarations in stdcxx. I fixed this in our staging branch already but you may just add
LIBS += libm
to your target.mk file.
Regards
Thank you very much for the immense help. It was enough for me to build a subset of the boost libraries and I've been able to do that, the sample application also links the built library. The entire porting process is quite interesting - the build system's sophistication greatly helps. Kudos!
On Tue, May 5, 2015 at 9:20 AM, Christian Helmuth < christian.helmuth@...1...> wrote:
Hello Aditya,
On Tue, May 05, 2015 at 09:13:19AM -0700, Aditya Kousik wrote:
My goodness, I'm glad it's daytime in Dresden. Thank you, Dr. Norman. I assumed libc would have the std headers; Adding stdcxx helped. It's tough to keep track of which features of linux are already included in the LIBS I've added. stdcxx still throws undefined references for the math
functions
(how do I include the -lm version of Genode?)
the dependency to libm is missing from the declarations in stdcxx. I fixed this in our staging branch already but you may just add
LIBS += libm
to your target.mk file.
Regards
Christian Helmuth Genode Labs
http://www.genode-labs.com/ · http://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main