vlink always links all modules from library

[sparhawk]

In my utillity library, I put each function into a seperate source file, as I expected that at linktime, only the modules will be included which are actually referenced.

Now I noticed that always the whole library seems to be linked into the final executable, even if the code is never called, so I wonder what I am doing wrong?

An example can be found here: https://github.com/skeetor/amiga-uti.../from_decu16.s

All modules use

    section .text,code

So maybe this is the reason?
Should I put each module into a separate section?

The linker command is this:

/opt/amiga/bin//vlink -b amigahunk -Bstatic -nostdlib CMakeFiles/Choplifter.dir/main.s.o CMakeFiles/Choplifter.dir/intro/CopperAnimation.s.o -o ../bin/Choplifter.exe /opt/amiga/utils/lib/libAmigaUtils.a

All code is compiled with vasm and the sample project can be found here (just in case): https://github.com/skeetor/container/tree/cp_dev

I attached a sample binary where you can see that the symbols are included, like 'fromDecimalU32' but this function is nowhere called in my code. When I look in Monam I can see that not only the symbol is lsted, but the code is also there.

[Thomas Richter]

Originally Posted by sparhawk

In my utillity library, I put each function into a seperate source file, as I expected that at linktime, only the modules will be included which are actually referenced.

Now I noticed that always the whole library seems to be linked into the final executable, even if the code is never called, so I wonder what I am doing wrong?

How do you build your library then? If just by linking the binaries, then the linker will put them into one hunk. You either need an object module librarian, such as the SAS/C "OML" utility, or a specialized linker for that which does not merge all the hunks.

[sparhawk]

The library itself is just linked with 'ar'

amiga-ar qc ../lib/libAmigaUtils.a snprintf.cpp.o vsnprintf.cpp.o SystemTakeover.s.o WaitRaster.s.o DebugPowerLED.s.o GFXLibrary.s.o MouseHelper.s.o dos/DOSLibrary.s.o dos/WriteString.s.o strlen.s.o from_decu16.s.o from_decu32.s.o from_decs.s.o to_decu16.s.o to_decs16.s.o to_decu32.s.o to_decs32.s.o mem/memcpyl.s.o mem/memcpyw.s.o mem/zcopyb.s.o mem/zcopyw.s.o mem/zcopyl.s.o copper/CreateCopperList.s.o copper/CreateCopperListC.s.o math/div32.s.o math/mult32.s.o
amiga-ranlib ../lib/libAmigaUtils.a

I stripped the paths to make it easier to read.

This library is then linked as I wrote above.

vlink -b amigahunk -Bstatic -nostdlib CMakeFiles/Choplifter.dir/main.s.o CMakeFiles/Choplifter.dir/intro/CopperAnimation.s.o -o ../bin/Choplifter.exe /opt/amiga/utils/lib/libAmigaUtils.a

So I can not use 'ar' for that? Or should I use gcc ld for linking?

[phx]

Don't know what your amiga-ar is creating. Probably a Unix ar-library? Have a look into the map file (-M) to see what vlink has done with it.

Unix libraries are supported by vlink, but you have to specify it as a library (-l option). You added it as another object file to the command line, so it is regarded as an object file instead as a library. In your case, you may try:

vlink ... -L../lib -lAmigaUtils

BTW, making a real hunk-format linker-library for AmigaOS is really simple:

join obj1.o objN.o as mylib.lib

(or use 'cat' when under Unix)
Then link with:

vlink ... -Lpathtomylib -lmylib

[sparhawk]

I checked the manual for vlink and found an option which seems to do what I wanted:

-gc-all

removes all the modules which are not referencedfrom the final binary.

My 'amiga-ar' ist just a wrapper for bebbos m68k tools, because on some of them I need to filter certain parameters which are not supported, but are used by CMake (That's mostly for gcc though).

[sparhawk]

Originally Posted by phx

Unix libraries are supported by vlink, but you have to specify it as a library (-l option). You added it as another object file to the command line, so it is regarded as an object file instead as a library. In your case, you may try:

Thanks for pointing that out. Since the linked binary always worked, I haven't noticed that. I wrote some CMake modules to support m68k-amigaos from bebbo, so it seems I have some of the compiler definition scripts wrong because if I had set it up correct, CMake should have created that library parameter.

[sparhawk]

After fixing the issue, that my library was not linked like a library, it turned out, that this was also the reason why it didn't throw away unreferenced modules. I didn't need the '-gc-all' switch after that fix and binaries are now as small as they should be.

[phx]