-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for symbol visibility export files #4747
base: master
Are you sure you want to change the base?
Conversation
This is neat, I'm still worried about using the same name for a file that is different on each platform. Clang supports
version script != linker script
About version scripts, I don't think macOS/Windows supports symbol versioning. |
This is is a bit problematic but the alternative is to have a kwarg per platform (and compiler). That causes kwarg explosion and does not really work either.
I would hazard a guess that
Yes. The point was what should we do if both of those are defined. Or possibly if we should use the same code to handle both as they are semantically similar. |
if cc.get_id() == 'msvc' | ||
suffix = '.sym' | ||
else | ||
suffix = host_machine.system() == 'darwin' ? '-clang.map' : '.map' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
meson.build:14:0: ERROR: Nonexisting file bob-clang.map.
mesonbuild/compilers/c.py
Outdated
@@ -1156,6 +1156,10 @@ def get_linker_always_args(self): | |||
return basic + ['-Wl,-headerpad_max_install_names'] | |||
return basic | |||
|
|||
def get_symbol_export_file_args(self, path): | |||
if self.compiler_type.is_osx_compiler: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does GCC support -exported_symbols_list
on macOS? (Be careful, GCC on Linux interprets -exported_symbols_list
as the -e
flag with the value xported_symbols_list
)
One thing I'm still worried about is that the user needs to implement the exact same "flag matching logic" than Meson in his Maybe a more fail-safe API would be something among the lines of: shared_library(symbol_export_file: {
'version_script': '…',
'msvc': '…',
'macos': '…', # This one seems to be macOS-specific because all symbols seem to need a leading underscore
}) |
mesonbuild/backend/vs2010backend.py
Outdated
@@ -1067,6 +1067,9 @@ def gen_vcxproj(self, target, ofname, guid): | |||
extra_link_args += compiler.get_option_link_args(self.environment.coredata.compiler_options) | |||
(additional_libpaths, additional_links, extra_link_args) = self.split_link_args(extra_link_args.to_native()) | |||
|
|||
unquoted_args, _ = self.get_export_symbol_file_args(compiler, target, absolute_paths=True) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Flake8] [E222] multiple spaces after operator
posted by Sider
mesonbuild/backend/backends.py
Outdated
args += linker.get_symbol_export_file_args(final_path) | ||
dep_files.append(relpath) | ||
return (args, dep_files) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Flake8] [W391] blank line at end of file
posted by Sider
Finally passes on all platforms. Now we need to make the actual decisions on whether to include this or not (and in what form). |
You can replicate that already with something like this: symbol_files = {'windows': 'foo.sym',
...
}
shared_library(..., version_script: symbol_files[host_machine.system()]) |
This won't work, because GCC on macOS will use |
But those two files have different syntax, right? They would need to point to different files then. So in order to make it work, we'd need to parametrize the kwarg both on the compiler and the platform (and, because everything is terrible, possibly other things as well). That's a fairly big state space explosion. |
The version script should work with GCC on all platforms. |
Well if the scripts are unique to a compiler, then the same applies as above, just use the compiler id as the key. If they are not, and you need to specify both a compiler and a platform to know which file to use then you need to do manual work anyway. |
Point is, Meson does the complex matching already, why duplicate the work? Also what happens if Meson's matching changes for a specific OS/compiler combination? |
cf5e7cf
to
2cd1079
Compare
So, odd question. Have we considered implementing one format (any of the existing formats) and having meson automatically create rules to convert said format if necessary? ie, meson always uses a gcc style visibility script, and we convert that to a mac symbol visibility or msvc symbol visibility script at configure or build time? or are there dragons there I'm not thinking of? It would be really nice to not have to define 5 different files to do the same thing (or play the awful #define game) |
Thing I can think of:
The "correct" solution is to use visibility macros rather than linker symbol scripts for everything except GNU style sumbol versioning. That requires code changes, though, and people seem to resist doing that due to various reasons. |
2cd1079
to
2675af2
Compare
2675af2
to
3c73e30
Compare
FWIW, libtool used a simple list file and automatically generated a version script when needed. See -export-symbols here. |
Libtool does not support the Visual Studio linker and it is unknown whether it supports lld either. |
I was just remarking on the interface of giving a simple list of exported symbols. Such a list can be converted to a DEF file for LINK.EXE, and can be passed to |
Note: on macOS symbols need to be prefixed with an underscore. See e.g. https://github.com/emersion/mrsh/blob/master/libmrsh.darwin.sym |
Just realized that there is already |
This is not possible in all cases, for example you might use |
Not finished yet!
Documentation missing. Possibly other stuff missing. Open questions:
symbol_export_files
instead since it can have several