<div>Problem: Certain object files cannot be placed in an archive file (a static library) and referenced with {$linklib myarchive} is a pascal unit. I don't know why and would like some advice.</div><div><br></div>I am attempting to link a static library (an archive of object files) built on Linux using mingw-w64 for Windows target and have a problem and a question. I've built the static library libSDL2.a (also known as an archive of object files) and dynamic library libSDL2.dll for Windows using the mingw-w64 compiler on Linux fine. Previously I've been linking to the dynamic library on Windows without problems, but now I want the option to compile using the static library.<div>
<br></div><div>Putting {$linklib SDL2} in my package source code causes a few unresolved references when attempting to compile an application. </div><div><br></div><div>Examples:</div><div><br></div><div><div>> Error: Undefined symbol: _strdup</div>
<div>> Error: Undefined symbol: _itoa</div><div>> Error: Undefined symbol: ___divdi3</div><div>> Error: Undefined symbol: ___udivdi3</div></div><div><br></div><div>I can resolve these missing symbols using nm to search object and archive files in the /usr/i686-w64-mingw32/lib/:</div>
<div><br></div><div>> i686-w64-mingw32-nm -o *.a | grep udivdi3</div><div><br></div><div>One by one I find all the missing symbols and copy the archive containing what's missing to a folder inside my package directory and adding an additional {$linklib foundarchive} to my sources. This works fine.</div>
<div><br></div><div>The problem is certain archives or object files refuse to work with this technique. </div><div><br></div><div>Both ___divdi3 and ___udivdi3 are in the i686-w64-mingw32 libgcc.a archive. </div><div><br>
</div><div>I can extract the object files _divdi3.o and _udivdi3.o which contain the missing functions from libgcc.a using i686-w64-mingw32-ar x libgcc.a _divdi3.o and _udivdi3.o.</div><div><br></div><div>I can link these two object files in my source code using {$l /path/to/files/_divdi3.o} and {$l /path/to/files/_udivdi3.o} and everything compiles okay and the programs run great.</div>
<div><br></div><div>I can even insert _divdi3.o into libSDL2.a and remove {$l /path/to/files/_divdi3.o} from my source. But there is problem is with _udivdi3.o.</div><div><br></div><div>For whatever reason if I put _udivdi3.o into an archive, such as libSDL2.a, or if I create an archive with just that file in it, such as </div>
<div><br></div><div>> i686-w64-mingw32-ar rcs libudivdi3.a _udivdi3.o</div><div><br></div><div>I still cannot use {$linklib udivdi3}. When I attempt to build I still get:</div><div><br></div><div><div>> Error: Undefined symbol: ___udivdi3</div>
</div><div><br></div><div>It's only by using code like {$l /path/to/files/_udivdi3.o} that I can get fpc to see the missing symbol ___udivdi3. This presents a problem because I must use the full path to _udivdi3.o (mind you my sources are in a package). If I want other people to reuse my package this presents a problem, as their paths may differ from mine.</div>
<div><br></div><div>What I'd really like is to find out how I can place _udivdi3.o inside a archive and get fpc to resolve ___udivdi3 when {$linklib myarchive} or {$linklib SDL2} is used.</div>