GCC linker weirdness - Page 1
Forum section: electronics / general

author: blueskull
author_rank: Unknown
timestamp: August 24, 2020, 05:44:52 pm
content: I have a folder full of .c files, I compile all of them into a .a library, which contains certain functions needed by the C runtime like _sbrk(), and then I compile my user code, link the user code object file, .a, and newlib together. LD complains not being able to fund _sbrk().If I put the .c file including _sbrk(), and compile it with my user code, newlib links well. Why is it happening?More visually, here's a rough file tree view:bsp/main.cbsp/lib/driver_xx.cbsp/lib/syscall.cIf I pack all driver_xx.c and syscall.c together to driver.a, LD will not be able to find system call functions like _sbrk() in syscall.o in driver.a, but if I pack the .a without syscall.o, and compile syscall.c with main.c then link them against driver.a, it will work fine.I tried to link all .o with .a, with and without -Llib -ldriver.a.Why is that?

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 24, 2020, 06:24:35 pm
content: Not all architectures munge function names by prepending an underscore. In particular, Linux does not. Are you sure you are using sbrk() and not a function named _sbrk() in your own code?Furthermore, recent versions of GCC are sensitive to parameter order. Typically, you'll want to use option flags first, then source files (objects), and finally libraries. Also, you'll want to use GCC for linking, and not LD, because GCC can provide the correct options to LD when it calls it for the linking.What is theexactcompilation and link commands?

author: andersm
author_rank: Super Contributor
timestamp: August 24, 2020, 07:07:50 pm
content: I'm guessing an input file ordering issue. See eg.herefor an explanation of why it matters.

author: mfro
author_rank: Regular Contributor
timestamp: August 24, 2020, 07:19:13 pm
content: Quote from: blueskull on August 24, 2020, 05:44:52 pmYou are aware that this command line doesn't look for lib/driver.a but for lib/libdriver.a instead?

author: bson
author_rank: Unknown
timestamp: August 24, 2020, 08:11:55 pm
content: Quote from: blueskull on August 24, 2020, 05:44:52 pm-lfoo is useful when you want the compiler/linker to search library paths. -L adds something to its search paths. Also looks forlibdriver, not driver. Since you likely perform only static builds without shared objects (.so's) it will only look for a .a.Since you want a specific static library of your own, just include it directly as an input file to the linker. A .a (archive) is just like a zip or jar file, a collection of other files. When you link with one it's as if you specified all the .o's contained on the command line. So you can simply use 'gcc -o outputfile file1.o file2.o lib/drivers.a' and it's as if you had enumerated all the contents of drivers.a directly on the command line. In this case 'drivers.a' is a good name to avoid confusing it with an actual installed common library.

author: westfw
author_rank: Super Contributor
timestamp: August 24, 2020, 10:42:01 pm
content: QuoteQuote.o files within a .a library will need careful ordering as well, won't they? Or use of ranlib ?