undefined references to c function calls in I/O modules

[kuza]

I'm trying to write my own I/O module.

In the I/O module I have procedures like print_string which call the c functions.
For example print_string calls printf to print a string.

In the I/O module I have extern printf, scanf, putchar
and global print_string, print_int, read_int, print_nl so far

In the main module I type extern (whatever procedure I want to call)

But for some reason I keep getting undefined references to the c functions when I link.

Why is that?

[Rob Neff]

You need to specify which libraries you are using when linking.

When using the linker on Linux, add the -lc switch to the command line to import libc functions.  When importing C functions you can simply use gcc to handle all the appropriate command line switches.  For example, to link your asm module, simply execute

Code: [Select]

gcc -o myexecutablename myasmobj.o -lc
which will also pull in the appropriate startup object files and pass them off to the linker.

For Windows, you want the msvcrt.lib. I don't remember what the command line switch is on Windows as I rarely develop on that platform anymore.

If you encounter any library file not found errors make sure you have the correct library paths specified either in your environment or passed to gcc on the command line.

[Frank Kotler]

Also be aware that MS spells it "_printf", GNU spells it "printf", and OpenWatcom spells it "printf_". Nasm has command line switches for "--prefix _" or "--postfix _" (two hyphens, mandatory space before '_') which will add the underscore... this may mess up  your spelling of "_print_string" though...

Might want to take a look at how Dr. Carter does it - http://www.drpaulcarter.com/pcasm

Best,
Frank

[kuza]

I'm using ld to link it.

The command is like this, (ld -melf_i386 test.o io_library.o -o helloworld)

should I be useing gcc instead.

And I got the idea for my io library from dr carters site

also I'm using mutilib slackware 14.

I have another question: Which is better an io library that uses c function calls or one that is pure assembly? Because I think I can do either one.

on yea one more important piece of infomation this only happens when I call from a module other than the main one.

[Frank Kotler]

An advantage to using gcc is that gcc "knows where the bodies are buried" and can produce the "right" command line for ld. I think you'll need "-lc" in there.

A confusing error I've encountered is to have the thing link without complaint, and a "file not found" error when you try to run it. Seems that, by default, ld (some versions) tries to use "/lib/ld-linux.so.1" as the "interpreter" or "dynamic linker", and this doesn't exist (on some systems). The solution is to tell ld "-I /lib/ld-linux.so.2" (exists on my system). Your system may not have this problem, or the solution may be different (one of the things gcc "knows about").

An advantage to using the C library routines is that they've been better tested than your routines or mine. They're written by trained professionals (you know, the folks who brought us gets()! ). My personal preference is to use scanf/printf if I need floating point conversions, otherwise DIY. If you're running Linux, you can assume that libc is already in memory, and there is very little overhead (but non-zero) to use it. Your routines or mine might be "better" than what the library provides... but it isn't very likely...

I don't know what it means that the problem occurs only when called from a module other than the main one. Possibly a function of where "extern" is defined?

If all else fails, post the code... or a pared down example that shows the problem...

Best,
Frank

[kuza]

Well using gcc fixed my problem thank you guys!!!

Frank what I mean is this.

I call read_int from the main module(the one that has _start in it).
The read_int procedure is in another file/module and it calls scanf.
When I use ld to link the two files together I get (undefined reference to scanf).

I didn't get this problem when the c function calls where only in the main module.

That is what I meant.

But I'll use gcc from now on.