Björn Döbel doebel@os.inf.tu-dresden.de writes:
When you write an application on Linux, you at least implicitly use the C library that comes with your system. The C library in turn maps your requests to the Linux kernel's system call interface.
If you want to run the same application on Fiasco, of course you need a C library as well. And of course this library needs to map your calls to Fiasco/L4Re primitives. So, yes, you need a new C library for a new OS. Same goes for other stuff, such as C++ STL, dynamic loading etc. This is a large part of what gets build when you compile L4Re.
The other part is L4Re-specific libraries that define all the nice L4 abstractions so that you can actually make use of those fancy L4 servers that provide system functionality.
Yes, this makes sense if this problem had to do with building *Fiasco* (and/or L4Re) - which indeed took a while, but that didn't surprise me. What surprised me was that it took ages to compile a "hello world" *application* when I already had compiled the kernel, and, that compilation of the application involved so many steps, from multiple (filesystem) locations, with paths passed as arguments to make, etc.
Sure, that's what an automated build system (e.g., GNU/Make) is there for. To only build things once and when you don't touch them, you don't rebuild.
Yes, I know the purpose of Makefiles, what I meant was, if I compile yet another application, not a "hello world" but a "hello moon", with separate (new) files, will the C library inclusion and remap and the things you mention, which do not relate to anything that separates the "world" from the "moon" (but rather what separates Linux from Fiasco), would all that have to be done again?
What is the rationale for all those trees with Makefiles on each level, not seeming to do much (to the untrained eye, though I know the syntax) while sometimes they are *immense*?
Please read about build systems, especially the GNU/Make manual or a tutorial.
Like I said, I know about Makefiles, but when I used them, they looked like this [1], identifying the source files, the header files, what libraries to include, where to put the object files, and what to name the executable, as well as some accessories, that is practical, typically to remove files.
But I didn't use Makefiles "recursively" and most certainly, for a "hello world" application, I would need *one* directory, and *one* Makefile, which wouldn't deal with my OS (Linux) at all.
And this is what I talk about.
Except for the usual stuff (target, libraries, and sources), there are a couple of recurring things, like
include $(L4DIR)/mk/prog.mk
Yep, all the make magic in L4Re is hidden in l4/mk/*.mk. Not very nice for the untrained eye, though. ;)
So my question remains, apart from the ordinary Makefile stuff, which I just described, what do I have to do - i.e., what is the "unique" Fiasco/L4Re stuff that needs to be included?
Did you already have a look at http://wiki.tudos.org/HOWTOs#Introduction_to_Fiasco.OC_and_L4Re ? The slides at http://www.inf.tu-dresden.de/index.php?node_id=1315 might also be of interest for you.
There are so many links on those pages - if you can point me to the actual articles, I promise to read them.
No, I only read two articles and they were about the Fiasco microkernel architecture - the factories, IPC gates, the UTCB, and such - I haven't seen anything as to how practically make applications and so.
[1] http://user.it.uu.se/~embe8573/game/char/exec/Makefile