OSDev.org

Posted: **Thu Sep 06, 2007 1:05 am**

I've compiled newlib and created libc.a and I've written my glue functions and placed them into libperception.a.

However when I link my test program using the following: (I've pasted the relevant parts from my build shell script).

Code: Select all

...
OUTFILE='AnnoyMe.prog'
...
LIBLOADER=$LIB'/loader.ao' # basically my complex cr0
LIBBIN=$LIB'/lib/libperception.a '$LIB'/lib/libc.a'
LIBLINK=$LIB'/link.ld'
...
LD='i586-elf-ld'
...
$LD -T $LIBLINK -o $OUTFILE $LIBLOADER *.o $LIBBIN
...

Yet when I run the shell script I receive a whole load of errors complaining my glue functions are undefined (I've only pasted one as an example):

Code: Select all

../Library/lib/libc.a(lib_a-makebuf.o): In function `__smakebuf':
/cygdrive/c/perception/Users/Superuser/Source/Library/i586-elf/newlib/libc/stdio
/../../../.././newlib/libc/stdio/makebuf.c:102: undefined reference to `isatty'

I think the problem is because my glue code is in libperception.a while the code trying to call it is in libc.a. I know libperception.a is working, because I can access my glue code fine from within my test program, just not from within newlib.

Here's an example function (my isatty from above) as a reference to what I'm doing:

Code: Select all

int isatty(int file)
{
	return 1;
}

That is stored in isatty.cpp, which gets compiled to isatty.o and placed in libperception.a.

Maybe the error is due to my glue code being C++ instead of C?

Posted: **Thu Sep 06, 2007 1:46 am**

All glue functions should be demanged - that is:

Code: Select all

extern "C" int isatty() {...

You can check this by going to your glue functions' lib.a file and

Code: Select all

nm lib.a | grep isatty

And it should come up clean, unmangled. Also worth a note is that in the newlib documentation, it says newlib requires the function to be called "_isatty", as with the rest of the glue functions (leading underscore), but if you put that underscore in you get link errors. D'oh!

Oh, and do you know if "sigaction" is defined in newlib? (this is just for me, not an answer to your question!

JamesM

Posted: **Thu Sep 06, 2007 8:47 pm**

JamesM wrote:You can check this by going to your glue functions' lib.a file and
Code: Select all
nm lib.a | grep isatty

That returns:

Code: Select all

Andy@tablet /cygdrive/c/perception/Users/Superuser/Source/Library/lib
$ nm libperception.a | grep isatty
isatty.o:
00000000 T isatty

Andy@tablet /cygdrive/c/perception/Users/Superuser/Source/Library/lib
$ nm libc.a | grep isatty
         U isatty

One says T the other says U. I'm guessing this symbol is the return type? I tried changing it the return type to an unsigned int but it still says T.

Posted: **Fri Sep 07, 2007 1:15 am**

MessiahAndrw wrote: One says T the other says U. I'm guessing this symbol is the return type? I tried changing it the return type to an unsigned int but it still says T.

U means Undefined, T means symbol is in a text segment (probably that means that it's a function). Check man page for nm for more info.

Posted: **Fri Sep 07, 2007 1:25 am**

That's good - it means the symbol is defined and unmangled. Try that same nm command on libc.a in the newlib/libc directory, and see if it returns the same result (you're looking for a T).It's possible that your glue functions aren't being linked in properly.

Posted: **Fri Sep 07, 2007 2:43 am**

did you try swapping your libc and libperception in the linker command line?

so
-lperception -lc
becomes
-lc -lperception

in the first case, your program is linked to your os library, and then to the libc, i.e. it resolves all references to isatty, and then creates references. In the second case all references generated by libc are resolved by libperception.

OSDev.org

Yet another person trying to port newlib

Yet another person trying to port newlib