How to link C language libraries?

Question

I am interested in executing a function which is written in C language:-

//filename "CLang.c"
#include<stdio.h>
void fun() {
    printf("Hello World");
}

I want to call this fun() through assembly language which i have written:- (NASM 64bit)

; filename "MyASM.asm"
section .data

section .bss

section .text
global _start
_start:
    call fun
    mov rax,60  ; exit
    mov rdi,1
    syscall

I have created object file by using these commands nasm -f elf64 MyAsm.asm and gcc -c CLang.c. When I merge these two file with gcc gcc MyASM.o CLang.o i get an error as

MyASM.o: In function `_start':
MyASM.asm:(.text+0x0): multiple definition of `_start'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o:(.text+0x0): first defined here
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status

I didn't understand why it says as multiple definition of _start I have written only one _start ???
I have no clue how to attach only gcc libraries with MyASM.o ???

The `gcc` frontend program default links with an object file containing the `_start` function. There are flags you can pass to `gcc` the stops it from linking with such files and the standard library. Please [read the GCC documentation](https://gcc.gnu.org/onlinedocs/). — Some programmer dude, Jun 05 '19 at 17:04
You should be aware that the `_start` routine supplied by the `Scrt1.o` module contains things to set up the environment needed for C programs. If you use your own instead of it, things like `printf` and `malloc` might or might not work. An easier first step would be to use a `main` routine in `C` to call your routine (named something other than `_start`), after which your routine could call other C routines. — Eric Postpischil, Jun 05 '19 at 17:10
That said, GCC has a switch `nostartfiles` to remove the default inclusion of the standard startup files. If that removes more than you want, you can check the GCC documentation for variations on it. Also, using `-v` with GCC will show you the link command it uses, and you can use that to see the paths for the default startup files and then, if there is more than one, explicitly list the ones you do want while using `-nostartfiles` to suppress the default behavior. — Eric Postpischil, Jun 05 '19 at 18:29
@Sanket: notice that you would have exactly the same problem if you removed the `call fun` instruction and tried to link with `gcc` (without `-nostartfiles` or `-nostdlib`) — Peter Cordes, Jun 06 '19 at 01:18

Michael Petch · Accepted Answer · 2019-06-05T19:45:08.137

The error you are getting is because you are defining _start and because you are compiling and linking with the C library (using GCC). The C library defines a _start label that initializes the C run-time. The two _start labels are the reason for the linker complaining about _start being redefined. The C startup code in the library is responsible for transferring control to main when it has properly initialized everything.

If you are using the C library (GLIBC) functions either directly or indirectly you need to ensure the C library is properly initialized by linking in its library and its run-time environment. By default this is something GCC does for you (it can be overridden).

You can define main as an assembly language function like this:

extern fun
section .text
global main
main:
    push rbp           ; Pushing a 64-bit register aligns stack back on 16-byte 
                       ; boundary so the call to `fun` has proper 16-byte
                       ; alignment per the AMD64(X86-64) System V ABI.
    call fun
    xor eax, eax       ; RAX=0 (main's return value)
    pop rbp            ; Restore the stack
    ret                ; Return back to C startup code which will exit for us.

You should be able to use your existing commands to assemble with NASM, compile with GCC, and link with GCC.

You may find some additional information about _start/main and the C runtime that is somewhat related here and information on the -nostartfiles option in the answers to this other question.

There is more information on stack alignment requirements in the answers to this Stackoverflow question

Technically `_start` is defined in the CRT start files, not in libc.so. So it's possible (but not recommended) to link with `gcc -nostartfiles` to just leave out CRT, instead of `gcc -nostdlib` to leave out everything, including libc and CRT. The CRT files come with glibc, but it's probably a good idea to distinguish things here. — Peter Cordes, Jan 17 '21 at 17:04

score -2 · Answer 2 · answered Jun 05 '19 at 18:17

In general, libraries are created from many library source files, and are either built as archive files (libmine.a) that are statically linked into executables that use them, or as shared object files (libmine.so) that are dynamically linked into executables that use them. To link in libraries of these types, use the gcc command line options -L for the path to the library files and -l to link in a library (a .so or a .a):

-L{path to file containing library} -l${library name}

For example, if I have a library named libmine.so in /home/newhall/lib/ then I'd do the following to link it into my program:

$ gcc -o myprog myprog.c  -L/home/newhall/lib -lmine

You may also need to specify and include path so the compiler can find the library header file: -I /home/newhall/include If you create your own shared object files and do not install them in /usr/lib, then you need to set your LD_LIBRARY_PATH environment variable so that the runtime linker can find them and load them at run time. For example, if I put my .so files in a directory named lib in my home directory, I'd set my LD_LIBRARY_PATH enviroment to the following:

# if running bash:
  export LD_LIBRARY_PATH=/home/newhall/lib:$LD_LIBRARY_PATH

  # if running tcsh:
  setenv LD_LIBRARY_PATH /home/newhall/lib:$LD_LIBRARY_PATH

The issue is not providing libraries for GCC to include in the link but suppressing the C run-time object module that is included by default (or, if not suppressing the module, avoiding conflict with it). — Eric Postpischil, Jun 05 '19 at 18:27
The OP's `CLang.c` isn't an actual *library*, the problem is libc. This appears to be a correct answer to a totally different question (about how to use an already-built shared library installed in a custom location). — Peter Cordes, Jun 06 '19 at 01:16

How to link C language libraries?

2 Answers2