Compiling DROPS' dietlibc on FreeBSD
der_julian at web.de
Tue Sep 13 18:13:04 CEST 2005
On Tue, 13 Sep 2005 17:14:23 +0200
Frank Mehnert <fm3 at os.inf.tu-dresden.de> wrote:
> On Tuesday 13 September 2005 16:31, Julian Stecklina wrote:
> > On Tue, 13 Sep 2005 11:27:21 +0200 (DFT)
> > "Martin Pohlack" <mp26 at os.inf.tu-dresden.de> wrote:
> > > Hi,
> > >
> > > I currently don't have access to the source code, but I think you
> > > should look up how the gcc include path is generated. The
> > > '-I/include' and the missing 'stdarg.h' seem to point to this.
> > I changed GCCDIR_x86 to /usr, so /usr/include gets passed and most
> > of dietlibc seems to compile. But I am missing l4/* include files.
> > What is the required order of building? How do I install header
> > files where the build scripts find them?
> This is generally a bad idea since you should use the headers which
> the LibC is build against. To fix your problem with stdarg.h go please
> check the following:
> gcc -print-search-dirs|sed -ne 's+^install: \(.*[^/][^/]*\)/\?+\1+p'
Removing \? seems to give the intended results. Does this change
semantics? Thanks for the hint.
> To build the L4 tree, perform make in $(L4DIR)/pkg. That ensures that
> at first all headers of all packages are installed into
> $(L4DIR)/include. After that, check that directory for the headers.
> cd l4/pkg; gmake
... Generating cpu_reserve-server.c
cpu_reserve-client.c cpu_reserve-client.h cpu_reserve-sys.h"
CC=gcc33 ../../../../tool/dice/src/dice -P-DRAM_BASE=0x0
-P-DUSE_DIETLIBC=y -P-DSYSTEM_x86_586_l4v2 -P-DARCH_x86 -P-DCPUTYPE_586
-P-I/home/blitz/drops/include -P-nostdinc -P-DUSE_DIETLIBC=y
In file included from ../cpu_reserve.idl:1:
dice/dice-corba-types.h:77:26: l4/sys/types.h: No such file or
directory ../cpu_reserve.idl:1:26: l4/sys/types.h: No such file or
directory ../cpu_reserve.idl:2:30: l4/dm_mem/dm_mem.h: No such file or
I am still missing headers. :) I tried gmake install in kernel/ and
tools/, but it did not help.
> You are talking about $(L4DIR)/mk/include.mk. As far as I see, printf
> "%P " delivers filenames as 'foo bar buz' instead of 'foo\nbar\nbuz'.
> I assume that the perl script would complain about '\n's. As this
Which perl script?
> seems to not work on your box, this could be the reason why crt0.h
> cannot be found ...
I actually thought the results of this find invocation are only
processed in Makefiles/shell scripts which treat \n as whitespace.
When someone says "I want a programming language in which I
need only say what I wish done," give him a lollipop. - Alan Perlis
More information about the l4-hackers