Hello,
after changing minimal parts of dietlibc's build procedure, I get as far as cd pkg/dietlibc ; gmake actually doing something but it fails with the following error:
... Compiling lib/__v_printf.o LD_PRELOAD=/home/blitz/src/l4/tool/gendep/libgendep.so GENDEP_TARGET=lib/__v_printf.o GENDEP_BINARY=cc1 gcc33 -c -nostdinc -DRAM_BASE=0x0 -DUSE_DIETLIBC=y -DSYSTEM_x86_686 -DARCH_x86 -DCPUTYPE_686 -DL4API_ -I../include -I.. -I../../../idl/OBJ-x86- -I/include -gstabs+ -g -O2 -fno-strict-aliasing -march=i686 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations /home/blitz/src/l4/pkg/dietlibc/lib/dietlibc/lib/__v_printf.c -o lib/__v_printf.o /home/blitz/src/l4/pkg/dietlibc/lib/dietlibc/lib/__v_printf.c:2:20: stdarg.h: No such file or directory In file included from /home/blitz/src/l4/pkg/dietlibc/lib/dietlibc/lib/__v_printf.c:7: ../dietstdio.h:12:20: stdarg.h: No such file or directory In file included from ../dietstdio.h:52, from /home/blitz/src/l4/pkg/dietlibc/lib/dietlibc/lib/__v_printf.c:7: ../include/stdio.h:7:20: stdarg.h: No such file or directory In file included from ../dietstdio.h:52, from /home/blitz/src/l4/pkg/dietlibc/lib/dietlibc/lib/__v_printf.c:7:
The include directories look bogus, but I am quite puzzled where they come from. Maybe my directory layout is somehow different from what is expected? Any hint is greatly appreciated.
Regards,
Hi,
after changing minimal parts of dietlibc's build procedure, I get as far as cd pkg/dietlibc ; gmake actually doing something but it fails with the following error:
Are these "minimal changes" Linux2BSD-translations only?
... Compiling lib/__v_printf.o LD_PRELOAD=/home/blitz/src/l4/tool/gendep/libgendep.so GENDEP_TARGET=lib/__v_printf.o GENDEP_BINARY=cc1 gcc33 -c -nostdinc -DRAM_BASE=0x0 -DUSE_DIETLIBC=y -DSYSTEM_x86_686 -DARCH_x86 -DCPUTYPE_686 -DL4API_ -I../include -I.. -I../../../idl/OBJ-x86- -I/include -gstabs+ -g -O2 -fno-strict-aliasing -march=i686 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations /home/blitz/src/l4/pkg/dietlibc/lib/dietlibc/lib/__v_printf.c -o lib/__v_printf.o /home/blitz/src/l4/pkg/dietlibc/lib/dietlibc/lib/__v_printf.c:2:20: stdarg.h: No such file or directory In file included from /home/blitz/src/l4/pkg/dietlibc/lib/dietlibc/lib/__v_printf.c:7: ../dietstdio.h:12:20: stdarg.h: No such file or directory In file included from ../dietstdio.h:52, from /home/blitz/src/l4/pkg/dietlibc/lib/dietlibc/lib/__v_printf.c:7: ../include/stdio.h:7:20: stdarg.h: No such file or directory In file included from ../dietstdio.h:52, from /home/blitz/src/l4/pkg/dietlibc/lib/dietlibc/lib/__v_printf.c:7:
Does your BSD/gcc have a stdarg.h ?
If NO: There is a stdarg.h in pkg/dietlibc/lib/contrib/dietlibc/include, but as it is not sym-linked into my dietlibc-directory, I guess it is not used and we rely on the a system-wide stdarg.h instead. Try adding stdarg.h to your contrib_files.lst
If YES: Then something seems to get wrong with your GCCINCDIR build variable. This one (in your output it seems it is /include) should point to the location of stdarg.h. GCCINCDIR is set when you do a "make config" in your L4 directory.
The include directories look bogus, but I am quite puzzled where they come from.
The paths look the same with my version of dietlibc (apart from the GCCINCDIR).
Good luck Bjoern
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.
But I'm not sure whether dietlibc will build on a bsd, because its author seems "a little bit" affixed to Linux ;-).
Martin
Hello,
after changing minimal parts of dietlibc's build procedure, I get as far as cd pkg/dietlibc ; gmake actually doing something but it fails with the following error:
... Compiling lib/__v_printf.o LD_PRELOAD=/home/blitz/src/l4/tool/gendep/libgendep.so GENDEP_TARGET=lib/__v_printf.o GENDEP_BINARY=cc1 gcc33 -c -nostdinc -DRAM_BASE=0x0 -DUSE_DIETLIBC=y -DSYSTEM_x86_686 -DARCH_x86 -DCPUTYPE_686 -DL4API_ -I../include -I.. -I../../../idl/OBJ-x86- -I/include -gstabs+ -g -O2 -fno-strict-aliasing -march=i686 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations /home/blitz/src/l4/pkg/dietlibc/lib/dietlibc/lib/__v_printf.c -o lib/__v_printf.o /home/blitz/src/l4/pkg/dietlibc/lib/dietlibc/lib/__v_printf.c:2:20: stdarg.h: No such file or directory In file included from /home/blitz/src/l4/pkg/dietlibc/lib/dietlibc/lib/__v_printf.c:7: ../dietstdio.h:12:20: stdarg.h: No such file or directory In file included from ../dietstdio.h:52, from /home/blitz/src/l4/pkg/dietlibc/lib/dietlibc/lib/__v_printf.c:7: ../include/stdio.h:7:20: stdarg.h: No such file or directory In file included from ../dietstdio.h:52, from /home/blitz/src/l4/pkg/dietlibc/lib/dietlibc/lib/__v_printf.c:7:
The include directories look bogus, but I am quite puzzled where they come from. Maybe my directory layout is somehow different from what is expected? Any hint is greatly appreciated.
Regards,
Julian Stecklina
Lisp nearing the age of 50 is the most modern language out there. GC, dynamic, reflective, the best OO model extant including GFs, procedural macros, and the only thing old-fashioned about it is that it is compiled and fast. -- Kenny Tilton, comp.lang.python
On Tue, 13 Sep 2005 11:27:21 +0200 (DFT) "Martin Pohlack" mp26@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?
... Compiling _exit.o LD_PRELOAD=/home/blitz/src/l4/tool/gendep/libgendep.so GENDEP_TARGET=_exit.o GENDEP_BINARY=cc1 gcc33 -c -DRAM_BASE=0x0 -DUSE_DIETLIBC=y -DSYSTEM_x86_586_l4v2 -DARCH_x86 -DCPUTYPE_586 -DL4API_l4v2 -I../../../../idl/OBJ-x86-l4v2 -I../../../../../../include/x86/l4v2 -I/home/blitz/drops/include/x86/l4v2 -I../../../../../../include/l4v2 -I/home/blitz/drops/include/l4v2 -I../../../../../../include/x86 -I/home/blitz/drops/include/x86 -I../../../../../../include -I/home/blitz/drops/include -nostdinc -DUSE_DIETLIBC=y -I../../../../../../include/dietlibc -I/home/blitz/drops/include/dietlibc -I/usr/include -gstabs+ -g -O2 -fno-strict-aliasing -march=i586 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations /home/blitz/src/l4/pkg/dietlibc/lib/backends/l4_start_stop/_exit.c -o _exit.o /home/blitz/src/l4/pkg/dietlibc/lib/backends/l4_start_stop/_exit.c:13:26: l4/crtx/crt0.h: No such file or directory /home/blitz/src/l4/pkg/dietlibc/lib/backends/l4_start_stop/_exit.c:14:26: l4/util/util.h: No such file or directory
But I'm not sure whether dietlibc will build on a bsd, because its author seems "a little bit" affixed to Linux ;-).
I have high hopes. It cannot be _that_ difficult. But if someone could explain to me where the advantage of find -printf "%P " over find -print is (which is POSIX) I would be partially enlightened. ;)
Regards,
Julian,
On Tuesday 13 September 2005 16:31, Julian Stecklina wrote:
On Tue, 13 Sep 2005 11:27:21 +0200 (DFT)
"Martin Pohlack" mp26@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'
should deliver you the gcc directory. Starting from that directory, ./include contains stdarg.h. I assume that the sed script probably does not work on your BSD box. Perhaps you find a fix. You find the original code in $(L4DIR)/mk/Makeconf, variable GCCDIR_f.
L4 headers are installed to $(L4DIR)/include when you perform make inside a $(L4DIR/pkg/<package>/include directory. Therefore, crt0.h should be located in $(L4DIR)/include/l4/crtx/crt0.h.
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.
But I'm not sure whether dietlibc will build on a bsd, because its author seems "a little bit" affixed to Linux ;-).
I have high hopes. It cannot be _that_ difficult. But if someone could explain to me where the advantage of find -printf "%P " over find -print is (which is POSIX) I would be partially enlightened. ;)
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 seems to not work on your box, this could be the reason why crt0.h cannot be found ...
Frank
On Tue, 13 Sep 2005 17:14:23 +0200 Frank Mehnert fm3@os.inf.tu-dresden.de wrote:
Julian,
On Tuesday 13 September 2005 16:31, Julian Stecklina wrote:
On Tue, 13 Sep 2005 11:27:21 +0200 (DFT)
"Martin Pohlack" mp26@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 LD_PRELOAD=/home/blitz/src/l4/tool/gendep/libgendep.so GENDEP_TARGET="cpu_reserve-server.c cpu_reserve-server.h cpu_reserve-client.c cpu_reserve-client.h cpu_reserve-sys.h" GENDEP_BINARY=cpp0 GENDEP_DEPFILE=.cpu_reserve.idl.d 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-DL4API_l4v2 -P-I../../../../include/x86/l4v2 -P-I/home/blitz/drops/include/x86/l4v2 -P-I../../../../include/l4v2 -P-I/home/blitz/drops/include/l4v2 -P-I../../../../include/x86 -P-I/home/blitz/drops/include/x86 -P-I../../../../include -P-I/home/blitz/drops/include -P-nostdinc -P-DUSE_DIETLIBC=y -P-I../../../../include/dietlibc -P-I/home/blitz/drops/include/dietlibc -P-I/usr/local/lib/gcc-lib/i386-portbld-freebsd5.4/3.3.6/gcc-lib/i386-portbld-freebsd5.4/3.3.6/include ../cpu_reserve.idl 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 directory
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.
Regards,
On Tuesday 13 September 2005 18:13, Julian Stecklina wrote:
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.
Still to be investigated.
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 LD_PRELOAD=/home/blitz/src/l4/tool/gendep/libgendep.so GENDEP_TARGET="cpu_reserve-server.c cpu_reserve-server.h cpu_reserve-client.c cpu_reserve-client.h cpu_reserve-sys.h" GENDEP_BINARY=cpp0 GENDEP_DEPFILE=.cpu_reserve.idl.d 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-DL4API_l4v2 -P-I../../../../include/x86/l4v2 -P-I/home/blitz/drops/include/x86/l4v2 -P-I../../../../include/l4v2 -P-I/home/blitz/drops/include/l4v2 -P-I../../../../include/x86 -P-I/home/blitz/drops/include/x86 -P-I../../../../include -P-I/home/blitz/drops/include -P-nostdinc -P-DUSE_DIETLIBC=y -P-I../../../../include/dietlibc -P-I/home/blitz/drops/include/dietlibc -P-I/usr/local/lib/gcc-lib/i386-portbld-freebsd5.4/3.3.6/gcc-lib/i386-portb ld-freebsd5.4/3.3.6/include ../cpu_reserve.idl 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 directory
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?
Please look at $(L4DIR)/mk/include.mk. The script ``installscript'' is a perl script.
Frank
On Tue, 13 Sep 2005 18:24:01 +0200 Frank Mehnert fm3@os.inf.tu-dresden.de wrote:
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?
Please look at $(L4DIR)/mk/include.mk. The script ``installscript'' is a perl script.
Oh my god... Pity to the poor soul that has written this script... but not much pity as he forgot to comment it. ;)
Regards,
On Tuesday 13 September 2005 18:43, Julian Stecklina wrote:
On Tue, 13 Sep 2005 18:24:01 +0200
Frank Mehnert fm3@os.inf.tu-dresden.de wrote:
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?
Please look at $(L4DIR)/mk/include.mk. The script ``installscript'' is a perl script.
Oh my god... Pity to the poor soul that has written this script... but not much pity as he forgot to comment it. ;)
I fixed both issues (``find . -name *.h -print'', and the GCC sed script), the fixes should be available from our remote CVS tomorrow.
Frank
On Thu, 15 Sep 2005 17:20:39 +0200 Frank Mehnert fm3@os.inf.tu-dresden.de wrote:
On Tuesday 13 September 2005 18:43, Julian Stecklina wrote:
On Tue, 13 Sep 2005 18:24:01 +0200
Frank Mehnert fm3@os.inf.tu-dresden.de wrote:
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?
Please look at $(L4DIR)/mk/include.mk. The script ``installscript'' is a perl script.
Oh my god... Pity to the poor soul that has written this script... but not much pity as he forgot to comment it. ;)
I fixed both issues (``find . -name *.h -print'', and the GCC sed script), the fixes should be available from our remote CVS tomorrow.
Thanks. I'll check it out and see how far that gets the build process.
Regards,
l4-hackers@os.inf.tu-dresden.de