Library dependencies missing: stdlibs in directory
emanuel.berg.8573 at student.uu.se
Tue Feb 18 22:45:20 CET 2014
Björn Döbel <doebel at 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
>> 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 , 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,
>> 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
> ? The slides at
> 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
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.
underground experts united:
More information about the l4-hackers