Common pattern for exporting symbols from shared library for msvc and gcc

[CorrodedCoder]

I'm interested if there is a cleaner looking recipe to support the following pattern of shared library symbol exports across Windows and *nix.

Example function (for illustration purposes only):

extern "C" __attribute__ ((visibility("default"))) int floop(void)
{
    return 42;
}

Example MSVC export definition file Example.def (for illustration purposes only):

LIBRARY	"Example"
VERSION	1.0
EXPORTS
	floop @1

Example gcc linker script (for illustration purposes only):

{
    global:
	floop;

    local:
        *;
};

My, quite possibly hacky, meson.build aiming at a common pattern:

project('Example', 'cpp', meson_version : '>= 0.61.5', default_options : [ 'warning_level=3', 'werror=true'])

if host_machine.system() == 'windows'
	example_export = meson.current_source_dir() / 'Example.def'
	example_link_args = []
else
	example_export = meson.current_source_dir() / 'example.exp'
	example_link_args = [f'-Wl,--version-script,@example_export@']
endif

shared_library('example',
	sources: 'example.cpp',
	vs_module_defs: example_export,
	link_depends: example_export,
	link_args: example_link_args,
	gnu_symbol_visibility: 'inlineshidden'
	)

It does work as I'd hope/expect. As it happens in my actual scenario I am code generating the .def or .exp files depending on compiler, but if I don't specify both files then I get an error because the logic for vs_module_defs expects that you give it a legit file as an argument. My hack above just passes the .exp file.

It's not difficult to work around the problem but I'd be interested if other folks have cleaner ways to accomplish this.

Thanks!
CC

[eli-schwartz]

There are two ways to do this in MSVC, and two ways to do this in GCC.

GCC has version scripts and MSVC has def files. They use different formats, sadly, and involve passing external files to the linker.

GCC also has symbol visibility and MSVC has the dllexport declspec. You can stick this inside a header as a macro and choose the correct one per platform, with the caveat that MSVC is dumb and actually requires you to use different values depending on whether you are building a static or shared library -- and have some extra pain if you want to build both, you have to compile all source files twice in that case.

Your example shows using the first method. The problem is that you always need to define the vs_module_defs, even if the file isn't actually created yet. A dummy file works. It also works if you do morekwargs = {'vs_module_defs': 'the_file.def'} and conditionally pass that to the library target with kwargs: morekwargs. You can even use that to pass the gcc link_args in the else clause.

[CorrodedCoder]

Indeed, I've used various approaches over the years and we've settled on def/exp files for now for consistency in our solution, and indeed it's always a trade off! Thanks for the morekwargs suggestion, I'll look into that. I was just hoping there was a way where I could be more lazy than this 😄

[eli-schwartz]

One day you will be able to be more lazy. I would like to add support for a kwarg that replaces vs_module_defs, and accepts keys including:

• a gcc version script
• a def file
• an apple ld version script
• a plain text file containing a list of symbols

And if needed, meson would automatically convert the last one into whichever more specific one you need but didn't specify.

[CorrodedCoder]

Nice, and see my own answer below that I have seen at least some linkers which take the symbol names to be exported at the command line one by one. I will try and remember the *nix variant I saw.

[CorrodedCoder]

This is it, I think: -Wl,-exported_symbol,_<symbol-name>
Not sure how well supported it is though (perhaps I used it with clang).

[CorrodedCoder]

Well, I found a scons tool I wrote many years ago which:

• Generated a simple def file from a list of symbols for MSVC
• Generated a simple linker script from a list of symbols for gcc
• Generated a set of -Wl,-exported_symbol,_<symbol-name> options for each symbol from the list
  Of course, I only needed to solve the problem for my solution rather than for everyone 😃

[xclaesse]

What I would recommend is using a macro that you set for all your public symbols, like EXAMPLE_API void floop(); and use #10199 to generate a header that defines that macro. Or just copy similar header into your project.

To use it:

library('example', 'example.c',
      gnu_symbol_visibility: 'hidden',
      c_args: '-DEXAMPLECOMPILATION',
    )

[CorrodedCoder]

Thanks - we have taken that route over the years too, but I should have been more specific in my question and said that I was hoping I could tidy up the meson.build file rather than changing our approach, but @eli-schwartz has elegantly disabused me of this notion 😄

[CorrodedCoder]

In fact, I've just remembered another idea I looked at a few years ago which I might try later. Some linkers allow you to specify exported symbol names on the command line at link time. MSVC using link /EXPORT and I'm sure I've seen something similar on *nix somewhere.
Edit: I've found something I did years ago on *nix, not sure how portable it is though (seems like I used it with clang):
-Wl,-exported_symbol,_<symbol-name>