I tried to do exactly as your 'hello' application to see if I could compile and link.
Among some other output, I got this message on 'make O=obj_path':
Library dependencies missing: stdlibs in directory '/home/incal/core/l4re-snapshot-2013123021/src/l4/pkg/hi/server/src'; aborting.
Cflags dependencies missing: stdlibs in directory '/home/incal/core/l4re-snapshot-2013123021/src/l4/pkg/hi/server/src'; aborting. Stop.
Before I did that, it told me to 'make O=obj_path config' from src/l4, which I did, though I didn't setup anything explicitly. I had to fetch 'pkg-config' from the repos, but that worked great, only it wouldn't work less the terminal had at least 80 columns - turns out, in the Linux VT, I have 73 columns (i.e., char width), and in X, in urxvt 78. But xterm was configurable in .Xresources like this:
xterm*geometry: 80x28
Just sayin'.
What is "stdlibs"? It sounds like the C standard library except for the trailing "s".
I tried to remove the "include" stuff from the C source, as well as the 'puts' and 'sleep' (to just make it return 0) - this, I thought, would make it independent of any library routines, however, I got the same error message.
On Sat Feb 08, 2014 at 20:05:41 +0100, Emanuel Berg wrote:
I tried to do exactly as your 'hello' application to see if I could compile and link.
Among some other output, I got this message on 'make O=obj_path':
Library dependencies missing: stdlibs in directory '/home/incal/core/l4re-snapshot-2013123021/src/l4/pkg/hi/server/src'; aborting.
Cflags dependencies missing: stdlibs in directory '/home/incal/core/l4re-snapshot-2013123021/src/l4/pkg/hi/server/src'; aborting. Stop.
Before I did that, it told me to 'make O=obj_path config' from src/l4, which I did, though I didn't setup anything explicitly. I had to fetch 'pkg-config' from the repos, but that worked great, only it wouldn't work less the terminal had at least 80 columns - turns out, in the Linux VT, I have 73 columns (i.e., char width), and in X, in urxvt 78. But xterm was configurable in .Xresources like this:
xterm*geometry: 80x28
Just sayin'.
I can recommend 'make textconfig' and 'make oldconfig' for your convenience.
What is "stdlibs"? It sounds like the C standard library except for the trailing "s".
It's an alias in the build system to group the necessary libraries required for building a program. Did you build the tree to a successful end before you compiled your own program?
I tried to remove the "include" stuff from the C source, as well as the 'puts' and 'sleep' (to just make it return 0) - this, I thought, would make it independent of any library routines, however, I got the same error message.
You need to build the tree so that all that functionality is available for your program. The error you're getting happens before anything is built because of the requirements for building as listed in the Makefile are not fulfilled and thus building makes no sense because it would fail.
Adam
Adam Lackorzynski adam@os.inf.tu-dresden.de writes:
I can recommend 'make textconfig' and 'make oldconfig' for your convenience.
Thanks, yes, 'make O=... oldconfig' did it but 'make O=... textconfig' complained:
make: *** No rule to make target `textdconfig'. Stop.
What is "stdlibs"? ...
It's an alias in the build system to group the necessary libraries required for building a program. Did you build the tree to a successful end before you compiled your own program?
You mean there is something else to "build" except for compiling and linking? In that case, no, what I did was:
1) (manually) create the src directory tree, with the Makefiles, mimicking the selfsame tree for 'hello'; and, created a dir in .../obj/l4/x86/pkg
2) 'make O=... config' (or 'oldconfig') in .../src/l4
3) 'make O=...' in .../src/l4/pkg/program
You need to build the tree ...
Is this tree (for 'hello') not the (filesystem) tree:
.../src/l4/pkg/hello/server/src
- ? If it is, are you saying setting it up is automatized by some tool?
On Mon Feb 10, 2014 at 23:34:01 +0100, Emanuel Berg wrote:
Adam Lackorzynski adam@os.inf.tu-dresden.de writes:
I can recommend 'make textconfig' and 'make oldconfig' for your convenience.
Thanks, yes, 'make O=... oldconfig' did it but 'make O=... textconfig' complained:
make: *** No rule to make target `textdconfig'. Stop.
Indeed, textconfig is only there in the kernel. Sorry, mixed that up.
What is "stdlibs"? ...
It's an alias in the build system to group the necessary libraries required for building a program. Did you build the tree to a successful end before you compiled your own program?
You mean there is something else to "build" except for compiling and linking? In that case, no, what I did was:
- (manually) create the src directory tree, with the
Makefiles, mimicking the selfsame tree for 'hello';
That's ok for creating your own package.
and, created a dir in .../obj/l4/x86/pkg
That is not necessary, and will be done automatically by the build system.
- 'make O=... config' (or 'oldconfig') in .../src/l4
Yes. After that you do: make O=... -j4
And wait until finished. The file l4defs.mk.inc must be there in your build tree (at .../l4defs.mk.inc) otherwise it did not run through successfully.
- 'make O=...' in .../src/l4/pkg/program
Yes.
You need to build the tree ...
Is this tree (for 'hello') not the (filesystem) tree:
.../src/l4/pkg/hello/server/src
- ? If it is, are you saying setting it up is
automatized by some tool?
As said, the approach of looking at an existing package is ok for building your own.
Adam
Adam Lackorzynski adam@os.inf.tu-dresden.de writes:
Yes. After that you do: make O=... -j4
Yes, that was the piece out.
And wait until finished.
Right, that took some time. Because the application was so basic, it must be some other thing going on. But if this can't be explained in a couple of sentences, no worries, I'm getting there...
The file l4defs.mk.inc must be there in your build tree (at .../l4defs.mk.inc) otherwise it did not run through successfully.
Yes, it is there, so it worked. Thank you!
On Wed Feb 12, 2014 at 20:47:45 +0100, Emanuel Berg wrote:
Adam Lackorzynski adam@os.inf.tu-dresden.de writes:
Yes. After that you do: make O=... -j4
Yes, that was the piece out.
And wait until finished.
Right, that took some time. Because the application was so basic, it must be some other thing going on. But if this can't be explained in a couple of sentences, no worries, I'm getting there...
In a couple of sentences? Give me a try. When you compile a program on your desktop, you need quite a bit of support functionality, such as some libraries, linker scripts etc. Those you just install and then it works. If you want to compile a program for another OS you this need support functionality as well. And that's what you have built.
Adam
Adam Lackorzynski adam@os.inf.tu-dresden.de writes:
In a couple of sentences? Give me a try.
No, actually I thought it was perhaps much to ask, that's what I meant. As for me, if you don't mind writing several pages, that would be great :)
When you compile a program on your desktop, you need quite a bit of support functionality, such as some libraries, linker scripts etc. Those you just install and then it works. If you want to compile a program for another OS you this need support functionality as well. And that's what you have built.
So building (compiling and linking + some extra glue) is that "OS intense" even with the same compiler (and associated tools), the same language, and, not the least, on the same architecture?
Also, is the "support functionality" persistent (not application/source dependent), i.e., will the process be much faster the next time I do it? (Actually I'll try this in one second, but I ask anyway.)
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*?
Except for the usual stuff (target, libraries, and sources), there are a couple of recurring things, like
include $(L4DIR)/mk/prog.mk
(and more) that perhaps would make more sense (to me) if you could provide me with a "hit list" what must be done to build an application. If I know "what" must be done, I think I could identify the "how" by just looking at other Makefiles.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
So building (compiling and linking + some extra glue) is that "OS intense" even with the same compiler (and associated tools), the same language, and, not the least, on the same architecture?
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.
Also, is the "support functionality" persistent (not application/source dependent), i.e., will the process be much faster the next time I do it? (Actually I'll try this in one second, but I ask anyway.)
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.
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.
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. ;)
(and more) that perhaps would make more sense (to me) if you could provide me with a "hit list" what must be done to build an application. If I know "what" must be done, I think I could identify the "how" by just looking at other Makefiles.
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.
Cheers, Bjoern - -- Dipl.-Inf. Bjoern Doebel Mail: doebel@tudos.org TU Dresden, OS Chair Phone: +49 351 463 38 799 Noethnitzer Str. 46 Fax: +49 351 463 38 284 01187 Dresden, Germany WWW: http://www.tudos.org/~doebel - -- "When the seagulls follow the trawler, it's because they think sardines will be thrown into the sea." (Eric Cantona)
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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.
Staying with my original example: If you compiled the Linux _kernel_, you'd also still have to compile the C library etc. before running a Hello World application on this system. Same with Fiasco (aka the kernel) and L4Re.
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?
As I said, if you add a new application to L4Re, you won't have to compile the C library again.
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?
Why not start with a simple L4 application with a rather simple Makefile (e.g., l4/pkg/hello) and copy stuff from there? Basically the answer is that you only have to set the SRC_C/SRC_CC and REQUIRES_LIBS make variables and the build system will do the rest for you.
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.
For an overview (which might include parts of what you already read) the "Introduction to Fiasco.OC and L4Re" slides in the wiki might be useful.
On the complex lab there are 4 slide sets - the first two might include some useful information about what needs to go into an L4Re Makefile, if that is what you're specifically searching for.
Cheers, Bjoern - -- Dipl.-Inf. Bjoern Doebel Mail: doebel@tudos.org TU Dresden, OS Chair Phone: +49 351 463 38 799 Noethnitzer Str. 46 Fax: +49 351 463 38 284 01187 Dresden, Germany WWW: http://www.tudos.org/~doebel - -- "When the seagulls follow the trawler, it's because they think sardines will be thrown into the sea." (Eric Cantona)
Björn Döbel doebel@os.inf.tu-dresden.de writes:
Why not start with a simple L4 application with a rather simple Makefile (e.g., l4/pkg/hello) and copy stuff from there? Basically the answer is that you only have to set the SRC_C/SRC_CC and REQUIRES_LIBS make variables and the build system will do the rest for you.
If you read the first couple of messages in this very thread, you'll see that I have done just that.
I put some helpers in this file [1] - after setting up the src tree, and the obj dir, I had to 'oldconfig', then '-j4', and finally 'make'. That it was that complicated for just a toy program tells me there is no way around it, if I ever am to write a serious application, I need to understand the process.
Now, I have a C++ project, consisting of two files, that also has a ned Lua file.
It has the following includes:
#include <l4/re/env> #include <l4/cxx/ipc_stream> #include <l4/re/util/object_registry> #include <iostream>
I have been unable to compile it because I don't know what needs to be done. In the code provided, there are typically exports, and a module list (the flags in 'qhello' of my file, perhaps), use of ned, inclusion of the mk file I mentioned earlier, and more, so again, it is a bit to much to digest without knowing what it all does. A "hit list" (1, 2, 3, done) would be helpful.
On the complex lab there are 4 slide sets - the first two might include some useful information about what needs to go into an L4Re Makefile, if that is what you're specifically searching for.
Yes, but any reading is fine. Right now I don't know how to compile. But I'll read anything you suggest.
[1] http://user.it.uu.se/~embe8573/conf/.zsh/l4.rc
Hi Emanuel,
it looks like you have some very basic misunderstandings of the build system. Looking at what the script you used seems to have done I recommend starting from scratch, because I suspect you abused the build directory to a point where it is no longer worth saving.
You main misunderstanding seems to be the use of the O= / OBJDIR= setting. This points to the root of your builddirectory. This means the build directory for the whole l4re tree. Not a new one for each package. As previous commenters on this thread wrote: when you use a runtime environment for another system the build system has to know about all the packages you want to use and how to find them.
So please: start from scratch (you can still use your packages you wrote of course).
Here are the basic steps you get you started with the runtime (which you could also have found at http://os.inf.tu-dresden.de/L4Re). I assume you already have a working / built Fiasco.OC kernel.
A) Download L4Re as instructed here: http://os.inf.tu-dresden.de/L4Re/download.html (I used the snapshot) B) Follow the steps at http://os.inf.tu-dresden.de/L4Re/build.html 1) Extract the source files 2) Go to the extracted source (l4re-snapshot-2013123021/src/l4) 3) Execute 'make B=path/to/builddir' with a build dir that is NOT inside the source directory! 4) Execute 'make O=path/to/builddir config' to configure your l4re system. 5) Type 'make O=path/to/builddir' (! in the directory 'l4re-snapshot-2013123021/src/l4'! You never change directories in these steps!!!) Let this last step run to completion!! You do not have a working L4RE tree if it does not complete successfully. Now you have a complete and working l4re source tree. You NEVER have to touch anything in the build directory.
If you do not want to type the O= part of the make command everytime just put that line into 'src/l4/Makeconf.local'. Then it will be added automatically.
C) You can now proceed to test your L4Re setup. Provide the file src/l4/conf/Makeconf.boot with the correct paths to the fiasco build directory (MODULE_SEARCH_PATH and command (QEMU_PATH) respective options (QEMU_OPTIONS). Look at the example file in the same directory for verbose information on the config. Start a qemu with fiasco and an example application by typing 'make qemu' at the src/l4 directory (if you did not follow above advise about Makeconf.local include O=path/to/builddir but pointing it to the ROOT of the build dir! No fancy directory guessing please!) and selecting the application.
Once this works you can write your own application:
D) 1) Go into src/l4/pkg and make a new directory by doing 'mkdir myhello' then change into the new directory. 2) issue the command '../../mk/tmpl/inst' to instantiate a template application. Edit the Control files with the correct dependencies (or remove the templates if you do not think you need any) and then edit server/src/main.cc at your leisure. I just used: #include <stdio.h> int main(int argc, char **argv) { printf("My Hello!"); return 0; }
3) To build the new application just issue 'make' (if you did not follow above advise about Makeconf.local include O=path/to/builddir but pointing it to the ROOT of the build dir! No fancy directory guessing please!) .
4) To have a new configuration in the dialog window of the qemu boot to choose from edit src/l4/conf/mdoules.list and add a new entry. I used: entry myhello roottask moe --init=rom/myhello module l4re module myhello
5) Now, in src/l4, type 'make qemu' again (if you did not follow above advise about Makeconf.local include O=path/to/builddir but pointing it to the ROOT of the build dir! No fancy directory guessing please!) and you should see your new myhello entry and be able to boot it.
I hope this gets you started...
Kind regards,
- Marcus
On 2014-02-19 17:48, Emanuel Berg wrote:
Björn Döbel doebel@os.inf.tu-dresden.de writes:
Why not start with a simple L4 application with a rather simple Makefile (e.g., l4/pkg/hello) and copy stuff from there? Basically the answer is that you only have to set the SRC_C/SRC_CC and REQUIRES_LIBS make variables and the build system will do the rest for you.
If you read the first couple of messages in this very thread, you'll see that I have done just that.
I put some helpers in this file [1] - after setting up the src tree, and the obj dir, I had to 'oldconfig', then '-j4', and finally 'make'. That it was that complicated for just a toy program tells me there is no way around it, if I ever am to write a serious application, I need to understand the process.
Now, I have a C++ project, consisting of two files, that also has a ned Lua file.
It has the following includes:
#include <l4/re/env> #include <l4/cxx/ipc_stream> #include <l4/re/util/object_registry> #include <iostream>
I have been unable to compile it because I don't know what needs to be done. In the code provided, there are typically exports, and a module list (the flags in 'qhello' of my file, perhaps), use of ned, inclusion of the mk file I mentioned earlier, and more, so again, it is a bit to much to digest without knowing what it all does. A "hit list" (1, 2, 3, done) would be helpful.
On the complex lab there are 4 slide sets - the first two might include some useful information about what needs to go into an L4Re Makefile, if that is what you're specifically searching for.
Yes, but any reading is fine. Right now I don't know how to compile. But I'll read anything you suggest.
Marcus Hähnel mhaehnel@os.inf.tu-dresden.de writes:
it looks like you have some very basic misunderstandings
I have yet to read *one line* that describes how to use this system!
You main misunderstanding seems to be the use of the O= / OBJDIR= setting. This points to the root of your builddirectory. This means the build directory for the whole l4re tree.
Aha, I thought it was the path of the future object files that was the result of compilation (of my program)!
In that case, I might as well have it as an environmental variable as it is unlikely to change or collide with anything else.
(l4re-snapshot-2013123021/src/l4) 3) Execute 'make B=path/to/builddir' with a build dir that is NOT inside the source directory! 4) Execute 'make O=path/to/builddir config' to configure your l4re system. 5) Type 'make O=path/to/builddir' (! in the directory l4re-snapshot-2013123021/src/l4'! You never change directories in these steps!!!) Let this last step run to completion!! You do not have a working L4RE tree if it does not complete successfully. Now you have a complete and working l4re source tree. You NEVER have to touch anything in the build directory.
OK I'LL GET BACK TO YOU!!!
Marcus Hähnel mhaehnel@os.inf.tu-dresden.de writes:
I hope this gets you started...
Yes, that worked!
Now compilation time is normal.
Amazing thing is, I didn't do half (actually close to zero) of that stuff the first time around, so how it still worked is a mystery!
This - now modified with new paths -
qhello () { core=~/core fiasco=$core/l4re-snapshot-2013123021/src/kernel/fiasco/fiasco-build/fiasco x86_bin=$core/l4re-build/bin/x86_586 l4f=$x86_bin/l4f
DISPLAY=":0" \ qemu-system-i386 \ -kernel $x86_bin/bootstrap \ -append "bootstrap -modaddr 0x01100000" \ -initrd "$fiasco -serial_esc\ ,$l4f/sigma0\ ,$l4f/moe --init=rom/$1\ ,$l4f/l4re\ ,$l4f/$1" \ -serial stdio }
- must have been a pretty good function, right? :)
Perhaps you should publish that tutorial on the home page?
If you don't count the O= stuff,
Makeconf.local Makeconf.boot mk/tmpl/inst
were all new to me.
As for
- To have a new configuration in the dialog window
of the qemu boot to choose from edit src/l4/conf/modules.list and add a new entry. I used: entry myhello roottask moe --init=rom/myhello module l4re module myhello
this brings me to another thing, namely - how do you know what modules you need? They seem to correspond to the -initrd options (in the qemu wrapper, above).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
Amazing thing is, I didn't do half (actually close to zero) of that stuff the first time around, so how it still worked is a mystery!
Fact is, it didn't.
This - now modified with new paths -
qhello () { core=~/core fiasco=$core/l4re-snapshot-2013123021/src/kernel/fiasco/fiasco-build/fiasco
x86_bin=$core/l4re-build/bin/x86_586
l4f=$x86_bin/l4f
DISPLAY=":0" \ qemu-system-i386 \ -kernel $x86_bin/bootstrap \ -append "bootstrap -modaddr 0x01100000" \ -initrd "$fiasco -serial_esc\ ,$l4f/sigma0\ ,$l4f/moe --init=rom/$1\ ,$l4f/l4re\ ,$l4f/$1" \ -serial stdio }
- must have been a pretty good function, right? :) Perhaps you
should publish that tutorial on the home page?
When you download the L4Re snapshot and unpack the tarball you end up with a directory such as l4re-core-<snapshotname>. In the top level of this directory there is a file called README, which we assumed people would find themselves attracted to ... read. Quoting from this file from now on...
QEMU ====
To run the built system under QEMU, go to an appropriate l4/ obj-directory of your choice, such as obj/l4/x86, and run: make qemu This will display a dialog menu to let you choose an entry to boot. For example, choose 'hello' and you should see the system starting and finally see "Hello World" scroll by periodically.
If you don't count the O= stuff,
Makeconf.local
Tips and tricks ===============
If you're just building for one build directory you can do the following to avoid the O=... argument on every make call.
Put O=/path/to/the/build-dir into L4DIR/Makeconf.local
Makeconf.boot
Configuring Images and Search Paths ===================================
The configuration file to configure the contents of images and generally the entries to boot is src/l4/conf/modules.list containing entries sections with modules for each entries listed. The search paths required to find the binaries and files are configured through Makeconf.boot file(s). Locations in the the src-directory as well as in the obj-directories are checked. The locations are src/l4/conf/Makeconf.boot and obj-dir/conf/Makeconf.boot. The paths can be configured globally or per make target. Please refer to src/l4/conf/Makeconf.boot.example for usage examples.
mk/tmpl/inst
Adding your own code ====================
[..]
The directory l4/mk/tmpl contains a template package directory layout structure and shows how a package might look like. It also contains examples on what to do in the Makefiles.
were all new to me.
Done quoting for now.
We highly appreciate any hints on how to improve that documentation. Claiming it isn't there doesn't help us a lot, though.
Cheers, Bjoern
Björn Döbel doebel@os.inf.tu-dresden.de writes:
Amazing thing is, I didn't do half (actually close to zero) of that stuff the first time around, so how it still worked is a mystery!
Fact is, it didn't.
I got the same result for the simple hello world demo.
What didn't work was compilation - or rather, that "worked", only it unintentionally included - I don't know - perhaps the whole L4Re?
You might remember I said compilation time was crazy and you told me several times it was normal, this was the remap of the C library, etc. On the other hand, obviously it was impossible for you to suspect the O= error, and the lesson is perhaps you should publish code first thing, instead of as a last resort.
were all new to me.
Done quoting for now.
We highly appreciate any hints on how to improve that documentation. Claiming it isn't there doesn't help us a lot, though.
Hold it - I have never said there isn't any documentation - I said I have never seen or read it (apart from those general microkernel descriptions, which were good). I will read every article you mention, including this README file, which you mention in a very negativistic way, but - I guess it's OK if you really thought I said "there isn't any documentation".
But actually I can say the style I prefer. Check out the documentation for Gnus [1]. They (or perhaps "he") has collected everything in one PDF, suitable for printing. Second best (or they complement each other, I guess) is just a list of links to individual articles and tutorials.
[1] http://www.gnus.org/manual.html
Adam Lackorzynski adam@os.inf.tu-dresden.de writes:
and, created a dir in .../obj/l4/x86/pkg
That is not necessary, and will be done automatically by the build system.
Doesn't look like that to me. On 'make O=... oldconfig', it says
bash: /home/incal/core/l4re-snapshot-2013123021/obj/l4/x86/pkg/client/Kconfig.generated: No such file or directory make: *** [/home/incal/core/l4re-snapshot-2013123021/obj/l4/x86/pkg/client/Kconfig.generated] Error 1
But after 'mkdir client' it works.
l4-hackers@os.inf.tu-dresden.de
-
Adam Lackorzynski -
Björn Döbel -
Emanuel Berg -
Marcus Hähnel