Exporting Functions from a Win32 Cross Built Static Library

I attempted to build a win32 static library using the i686-w64-mingw32 cross-build toolchain.

I built the object files and the mylib.lib file via a Makefile:

$(program_RELEASE_NAME_WIN_STATIC): $(RELEASE_OBJS_WIN32_STATIC)
    i686-w64-mingw32-gcc-ar rcs $(BUILD_DIR_WIN32)/static/$@ $^

$(BUILD_DIR_WIN32)/static/%.o: %.c $(HEADERS)
    $(RELEASE_LINK_WIN32.c) $< -c -o $@

This gave me the static library mylib.lib. Inspecting this on the linux side with nm I can see all the constituent object files and the functions they contain

No when I inspect mylib.lib on a windows 10 VM, i.e.

DUMPBIN /EXPORTS mylib.lib

I get:

Microsoft (R) COFF/PE Dumper Version 9.00.30729.01
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file mylib.lib

File Type: LIBRARY

  Summary

           C .bss
           C .data
         6AC .drectve
        5EAC .rdata
         444 .rdata$zzz
       29900 .text
          38 .text.unlikely

None of the functions are being exported.

In the relevant header file I mark up the functions I want to export with __declspec(dllexport)

This worked fine when I was producing a .dll, i.e. the functions I marked for export were the only ones that were visible in the .dll file

But for the static library equivalent nothing is being exported?

How are you meant to make functions visible in a win32 .lib file?

dumpbin /exports lists the symbols exported by an executable or DLL. See the DUMPBIN options documentation

A static library isn't an executable or DLL. It's just a bag of object files in Unix ar archive format (which is the same MS LIB format).

dumpbin analyses COFF binaries. When you run:

dumpbin /option... static.lib

it analyses each object file in static.lib according to /option.... But:

dumpbin /exports file.obj

will never report any exports in the object file file.obj because an object file isn't an executable or DLL either. It has no dynamic symbol stable. Only an executable or DLL can expose symbols for dymamic linkage: it is supplied with its dynamic symbol table when it is generated by the linker, which has no hand in producing either an object file or static library.

If you now build an executable or DLL that links any function from your static library that you have qualified with __declspec(dllexport) in the library's header file, then the linker will add that function to the dynamic symbol table of the output executable or DLL, and if you then dumpbin /exports on that executable or DLL, you will see that the function is reported.

An object file may define global symbols. A global symbol (a.k.a public/external symbol) may or may not be exported for dynamic linkage, depending on whether it is qualified __declspec(dllexport) or not. A symbol must be global to be a DLL export.

If you run dumpbin /symbols on your static library, that will report all the symbols in all the object files in the static library, and will classify them as External or Static. The symbols that you have qualified as __declspec(dllexport) will appear amoung the External symbols listed.