OSDev.org

this is a question i have wondered about for a while. how do libraries work? for example, when i write a program for windows or linux i usually start with #include <stdio.h> this is a collection of library functions right? however, isn't it just the prototypes? and does that mean that the actual code for the functions is linked in with the executable? or is the "code" for library functions like printf() just calling a lower-level OS function? and when writing an OS, how do you handle libraries? do both the kernel and stand-alone applications reference libraries, but you just have to write them yourself? do library functions ever call lower-level functions? for example, how does printf() work? does it process the %d's and etc. itself but then call a kernel or lower-level function to actually display the character on the console?

i appreciate any help clearing up my cluttered mind

On Windows, a program links to a .LIB file. That file either provides the functions itself (which get linked inside the program), or redirects to a DLL somewhere.

On Unix, programs link to .a files. That file always provides the functions itself. Alternatively, you can link to a .so file, which will be shared and remain as a separate file.

Linking to a non-shared library (.LIB or .a) is just the same as linking to a normal object file. In fact, static (non-shared) libraries are usually just collections of object files.

When people write OSes.. they usually write some interrupts and some system calls. They make some advanced libraries based on these basic system calls. Like the Printf could be designed using the interrupt for the display and so on.

These libraries are usually distributed as .a and .lib files which contain the compiled code. The .h are usually given to the developers to know which of the functions r present and to the knowledge of the compiler that these all functions can be got from the library file. U will have to write ur own library or get a readymade source from somewhere like the OSKit project.

ok, right now i am using djgpp, nasm, and ld. how does one go about creating a .a library? i can create the .c and .h files, but how do you actually compile them all together to a single library file? also, what format is this file?

ar (in package binutils) is the tool used to ARchive .o files into a single library file (.a) ...

the .h file is not joined to the library but is instead distributed separately (usually in the -dev package of the library)

ok, so once i have created a library, can i simply use its functions in my kernel and applications by linking them with the (ld) parameter -l ? or is there more to it than that?

That's all you need. Note that you'll need to name a library after any modules that refer to it, not before.

Note that you'll need to name a library after any modules that refer to it, not before.

what do you mean by this?
also, what format do the .o files need to be in to be able to make a library? can i use assembly functions and make a .o with nasm to include in the library?

thanks

i guess what Tim means is that is correct, but not (correct me if i'm wrong)

basically, your .o files must have a format that suits the linker: ELF for a linux environment and COFF for a windows environment. ld --help will usually tell you the supported formats.

ok, i understand the command line order now.

right now for my asm & c code i am using the a.out object format. i have used it ever since i followed a tutorial that used it a year ago or something. should i be using something like elf instead? and will this work fine with gcc-compiled c mixing with nasm-compiled asm? and what are the advantages/differences i should be aware of if switching to elf?

I tried to create a string library to include in my kernel, but got this warning from gcc:
i tried using -nostdlib, -nostartfiles, and -nodefaultlibs but i get the same warning every time... i want to be able to write my own library functions, so how can i tell gcc not to look at the standard libraries, or not to look at any "built-in" ones?

thank you

string.h string.c

the option -fno-builtin(or similar look man gcc) will be your friend

-fno-builtin works great. however, now i am unable to get assembly functions in a library to work. i get this error message from gcc:
the command i used to compile is:
main.c string.asm this is compiled like this: and put into the library like this: here is the header file hstring.h: i know i am doing something wrong because main.c is not seeing strfun()!

hmm ... i know that sometimes the linker is sensitive at the return type of the functions ... maybe you should try to put a fake C declaration of strfun with your asm implementation (i mean something like 'fake.c : void f() { strfun();}') that you'd link with your ASM module and see what it gives...

i have done this, i made a new c file and put a dummy call to strfun(1) inside of it, but i still get the same error message when linking main.c to the library. is my syntax in hstring.h correct for declaring an external asm function? and is the code in string.asm correct for making _strfun global?

i appreciate any feedback!