Skip to content
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

boost_stacktrace_impl_return_nullptr as an exported symbol #177

Closed
lufriem opened this issue Aug 27, 2024 · 8 comments · Fixed by #186
Closed

boost_stacktrace_impl_return_nullptr as an exported symbol #177

lufriem opened this issue Aug 27, 2024 · 8 comments · Fixed by #186

Comments

@lufriem
Copy link

lufriem commented Aug 27, 2024

#159 added the 'stacktrace from current exception for MSVC' feature but one (I guess) sideeffect is that I now get an exported symbol 'boost_stacktrace_impl_return_nullptr', which makes MSVS always generate an input library (.lib) for my (non-library, ie EXE) project (its linker just triggers off the __declspec(dllexport) tokens, with no way of suppressing this, see https://developercommunity.visualstudio.com/t/why-is-vs2017-building-an-import-library-for-my-ex/233569#T-N237446-N243028). Due to some (admittedly dodgy) project setup I ran into troubles with this file present (when it did not exist before), which I fixed on my side, but I'm wondering about this export..

I guess there's a reason for having that symbol be exported? I see that using the BOOST_SYMBOL_EXPORT macro I guess I could suppress its creation, but I wouldn't really want to deviate from your default project/configuration defaults..

Sorry for the rambling, I guess my question is, is this expected and something that users just have to deal with?

Thank you

@apolukhin
Copy link
Member

Make a PR with a fix and let the CI run. We'll see, if removing that BOOST_SYMBOL_EXPORT breaks something

@huangqinjin
Copy link
Contributor

You may use /NOIMPLIB linker option to suppress the generation of .lib file. Without BOOST_SYMBOL_EXPORT, no symbol boost_stacktrace_impl_return_nullptr exist and /ALTERNATENAME would not work.

@lufriem
Copy link
Author

lufriem commented Sep 12, 2024

Thank you both for your replies! I also searched around a bit but I'm afraid I'm out of my depth in regards to the boost build system.

One thing I saw that I neglected to mention (sorry!): I'm using a static build of the boost libraries. I found an old thread discussing the 'issue' of boost exporting symbols (also in the context of exception reporting, funnily enough), I suppose under these circumstances (static lib) it would also be possible to globally suppress their creation (as they wouldn't be needed/wanted anyway) using the BOOST_DISABLE_EXPLICIT_SYMBOL_VISIBILITY switch. Under any other circumstances (ie shared library) I don't think that would be a good idea.

@huangqinjin
Copy link
Contributor

I mean to apply /NOIMPLIB to your EXE linker option, not the boost library itself.

@lufriem
Copy link
Author

lufriem commented Sep 12, 2024

Yes thank you I understood that, I was just wondering whether there was still something that could/should be done to the library itself

@huangqinjin
Copy link
Contributor

I have no idea if there is a better method to mimic the __attribute__((weak)) behavior. Maybe just provide a macro to #ifdef-out the symbol if boost_stacktrace_from_exception is linked.

@apolukhin
Copy link
Member

Maybe just provide a macro to #ifdef-out the symbol if boost_stacktrace_from_exception is linked.

Hm, the BOOST_STACKTRACE_DYN_LINK macro is defined if dynamic library is being built. I'll try the ifdefing tomorrow

@lufriem
Copy link
Author

lufriem commented Sep 13, 2024

Thank you both for your efforts!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants