Ld, the GNU linker has an interesting feature, it can combine object files to create one monolithic object file. The example below combines StdOut.obj ( function to write to the console window ) and the dependency StrLen.obj ( string lenght calculator ) to output one file named Modules.obj
\PellesC\bin\poasm /AIA32 StrLen.asm
\PellesC\bin\poasm /AIA32 StdOut.asm
\PellesC\bin\poasm /AIA32 Sample.asm
C:\msys64\mingw32\i686-w64-mingw32\bin\ld -r -m i386pe -o Modules.obj StdOut.obj StrLen.obj
C:\Masm64\bin64\link /SUBSYSTEM:CONSOLE /LIBPATH:\PellesC\Lib\Win Sample.obj Modules.obj kernel32.lib user32.lib
Sadly have to say, that is a bad idea, as no COMDATs :(
Hi Timo,
I guess you are referring to the duplicate symbols issue. Polink cannot link those combined object files. This is why I used MS Link. I think my example should be fine as it's a very simple one.
Hi Erol,
Basically a nice idea to avoid using msvcrt.dll in some projects with poasm.
Hi Timo,
Thanks, it's all about practical programming. Right tool for the right job.
but... when is this useful??
I can only think of two things to do with an object file:
1) pass it to the linker
2) put in in a library/archive, and pass that to the linker
I mean, normally you have the source code, and anything of importance that needs to change in the object file is better handled by editing the source code and rebuild.
If you don't have the source code, well... disregarding any legal issues, if you don't known exactly what you are doing, random changes will probably cause more harm than good (and don't expect tools at this level to warn you much).
Hi Pelle,
The purpose of merging object modules is to provide only one monolytic object file to the linker. Nothing fancy. As you said, it's preferable to create a static library.
OK. I still don't see the point in having a tool that combines object files, but never mind. Not important.