Porting Binutils: On the way to self hosting

[Muneer]

Hi,

Please bear with me. I am really thrilled in seeing my Os self hosted. So after having newlib ported and gcc recompiled and porting nasm to my Os. I am now trying to port binutils. As always it simply wont finish compiling .

This time I tried to compile my binutils with this.

Code: Select all

../binutils-2.21/configure --host=i586-elf --target=i586-elf --prefix=/home/HardCoder/Downloads/binutils/binutils  --disable-nls 

It finishes without problems. Then when I try "make all", it runs for about 1 minute and then shows

Code: Select all

/bin/bash ./libtool --tag=CC   --mode=link i586-elf-gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2   -o size size.o bucomm.o version.o filemode.o ../bfd/libbfd.la ../libiberty/libiberty.a  
libtool: link: i586-elf-gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -o size size.o bucomm.o version.o filemode.o  ../bfd/.libs/libbfd.a ../libiberty/libiberty.a
../bfd/.libs/libbfd.a(bfdio.o): In function `real_fopen':
/home/HardCoder/Downloads/binutils/build-binutils/bfd/../../binutils-2.21/bfd/bfdio.c:81: undefined reference to `fcntl'

more undefined reference follow. Seeing as it is the linker error. I guess that many build-system libraries being dragged along. Can it be the problem. If so how do I avoid it. I tried editing the makefile many times trying to hardcode the ld location etc but to no success.

Anyone ever had experience with this problem? Also it works if I try to make a cross compiler with the build-system's gcc.

[Kevin]

Looks like your libc is incomplete. You'll need to implement fcntl().

[Muneer]

I have implemented all the 18 or 20 such stub functions before porting. Is there still functions to be written.. Could you please give more info on it.

[Solar]

Or perhaps his libc does implement fcntl, and binutils just doesn't find the lib?

A quick check of ./configure --help turned up --with-stage1-libs, --with-boot-libs, and --with-build-sysroot as candidates for further investigation...

[Muneer]

@solar.
I will check it.

[Kevin]

Or perhaps his libc does implement fcntl, and binutils just doesn't find the lib?

Wouldn't it complain that it can't find the library file then?

Except if it finds something, but not exactly what you expected it to find.

[Solar]

Or perhaps his libc does implement fcntl, and binutils just doesn't find the lib?

Wouldn't it complain that it can't find the library file then?

If it isn't told to look for it? I don't see explicit mention of a libc on the command line before the error, and I honestly don't know how GCC / binutils behave in this specific constellation.

[gerryg400]

I have implemented all the 18 or 20 such stub functions before porting. Is there still functions to be written.. Could you please give more info on it.

You probably need to implement some more functions. I've implemented enough to compile dash and here's a slightly out of date list that I needed for that. You will need to implement fcntl. The probable reason it's not listed as a stub is that none of the standard clib functions sits on top of it.

Code: Select all

_execve
_exit
abort
chdir
close
creat
dup
dup2
fcntl
fork
fstat
getcwd
getdents
getegid
geteuid
getgid
getgroups
getpgrp
getpid
getppid
getuid
lseek
lstat
mmap
munmap
open
pipe
pread
pwrite
read
setegid
seteuid
setgid
setpgid
setuid
stat
tcgetpgrp
tcsetpgrp
umask
wait
wait3
wait4
waitpid
write
kill
killpg
sigaction
sigaddset
sigdelset
sigemptyset
sigfillset
sigismember
signal
sigprocmask
sigsuspend
brk
sbrk
syslog
clock_gettime
clock_nanosleep
clock_settime
gettimeofday
nanosleep
timer_create
timer_delete
timer_settime

[Muneer]

Thanks for the info and list. I am feeling too sleepy and tired to implement it today. Will post the results.

[Muneer]

After implementing the five functions that binutils referred to as undefined namely fcntl, umask, chmod, access, lstat and adding it to the libc.a(removing the old syscall.o) using ar utility, now it says mutliple defenitions in libc.a and libg.a of almost all the functions I have implemented. Seeing it as a debugging enabled libc, I copied the libc.a to libg.a (because someone told iibc.a also comes with debugging info).

Anyways now the multiple defenitions error vanished only to be replaced with a new one called "implicit declaration of function utime and lstat". Knowing it as the old and frequent gcc message which appears when you havent declared the prototype, I checked the file in which this error occurs named "binutils-2.21/binutils/rename.c". It clearly had #include <sys/stat.h> wherein the prototype for lstat is declared. but following the "#include <utime.h>", function utime is not declared. Well the latter makes sense since I cant see it declared. But lstat was implemented by me in syscalls.o and inserted to libc.a using ar utility. The implicit error to lstat just doesnt make sense. Also I couldnt find utime in the list provided by gerryg400. Is it something I should implement Any help would be much appreciated.

EDIT: I also noticed that the functions "access" and "chmod" were not in the list provided by gerryg400. But I implemented them in syscalls.c. Can it contribute to the problem

EDIT: After removing those "access" and "chmod" compiling returns undefined references. So that proves they are valid inside syscalls.c and not provided by newlib. So 2 more in gerryg400's list.

EDIT: @gerryg500 : which version of binutils did you port to your Os hoping that I maybe relieved of this mess if I use that version.

[gerryg400]

I use 1.19.0

My list is not exhaustive, it's simply a list of functions I had to add to make a single program (dash shell) compile. I'm adding new functions every day. In fact I've added so many functions myself that I've considered dropping newlib completely.

In Linux both access and chmod are kernel calls and so it's not surprising that they don't exist.

There will be many others.

[Muneer]

Where you referring to newlib 1.19.0, because I cant find binutils 1.19.0 anywhere

[gerryg400]

Ooops, that's newlib 1.19.0

I haven't ported binutils yet, just dash shell.

Hmm, I'll try to compile binutils 2.21.1 and see what happens.

[Edit] Tried building a self-hosted binutils-2.20.1, and I'm still missing some functions including pathconf. Guess that needs to go on my todo list.

[Muneer]

I finally managed to get binutils to successfully "configure" and "make all" after implementing these additional syscalls apart from newlibs 19 essential syscalls.

lstat
chmod
access
umask
fcntl
utime
chown
rmdir
sysconf
getwd

Also I had to add

Code: Select all

extern int utime(const char *path, void *times); 
extern int lstat(const char *path, void *buf);

to the binutil-2.21/binutils/rename.c. This solved the implicit declaration problem of lstat and utime in rename.c

@gerryg400 : I did not get any undefined reference to pathconf but instead got sysconf.

I am still having trouble in "sudo make install".

Code: Select all

libtool: install: chmod 644 /home/HardCoder/Downloads/binutils/final/lib/libbfd.a
libtool: install: i586-elf-ranlib /home/HardCoder/Downloads/binutils/final/lib/libbfd.a
./libtool: line 1115: i586-elf-ranlib: command not found
make[5]: *** [install-bfdlibLTLIBRARIES] Error 127

I reckon my old problem. Must have to hardcode the path somewhere. This has happened to me before. Can anyone point out why it works when i586-elf-ranlib is entered into the terminal. But make cannot find it or in this case libtool in make.

[Muneer]

Hoooray ,
I got it worked. Had to hardcode the path of i586-elf-ranlib in
build-binutils/binutils/libtool
build-binutils/bfd/libtool
build-binutils/opcodes/libtool


here is a screenshot of ld with "-v" as arguement.



The output is different from ld "-v" on my ubuntu
GNU ld (GNU Binutils for Ubuntu) 2.21.0.20110327
---- But actually who cares..