OSDev.org

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. It finishes without problems. Then when I try "make all", it runs for about 1 minute and then shows 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.

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

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.

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...

@solar.
I will check it.

Solar wrote: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.

Kevin wrote:

Solar wrote: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.

HardCoder wrote: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.

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

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.

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.

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

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.

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 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". 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.

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..