Skip to content

exceptions/exception.h: Try fixing linking on MinGW #46

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

Merged
merged 1 commit into from
Oct 21, 2022

Conversation

fanc999
Copy link
Collaborator

@fanc999 fanc999 commented Oct 20, 2022

Hi,

This attempts to make updates to libxml++config.h.[in|meson] so that we can accomodate exporting the whole xmlpp::exception class on MinGW builds but only export selectively on Visual Studio builds so that we can fix issue #45 (for MnGW) and also avoid having the built binaries from being ABI unstable by avoiding it being tied to a particular STL version.

With blessings, thank you!

@neheb
Copy link
Contributor

neheb commented Oct 20, 2022

I don’t understand the new macro changes

@fanc999
Copy link
Collaborator Author

fanc999 commented Oct 20, 2022

Hi @neheb,

The thing is, we want to differentiate between Visual Studio builds and MinGW builds where it is necessary, because we need to export the whole xmlpp::exception class on MinGW so that the vtable of that class gets exported but we don't want to export the whole xmlpp::exception class on Visual Studio but instead export the members individually so that we can avoid ABI issues (note that Visual Studio export a class's vtable by default). Do things work for you?

@neheb
Copy link
Contributor

neheb commented Oct 20, 2022

Adding both dllexport and visibility on the same define is weird. They do the same thing on mingw.

@fanc999
Copy link
Collaborator Author

fanc999 commented Oct 20, 2022

Hi @neheb,

So, does the update fix your problem? I can always drop dllexport or visibility if things at this point did work for you (merely doing what is done in GLib).

@kjellahl
Copy link
Collaborator

The cross compiler in MinGW can build libxml++ with this fix, both with and without
__attribute__((visibility("default"))) in LIBXMLPP_VISIBILITY_DEFAULT.
If you decide to drop __attribute__((visibility("default"))), LIBXMLPP_VISIBILITY_DEFAULT
would of course be a strange name.

I've installed wine64 now. The ninja test executes all the example programs.

Please merge, unless @neheb has a better idea.

Using the xmlpp::exception class may lead to a linker error on its
vtable on MinGW, unless the whole class is exported, but we also want to
avoid exporting that whole class under Visual Studio, so that we can
avoid having the built DLL/import library being tied to a particular STL
version, so define macros to accomdate such situations and apply it to
the xmlpp::exception class.

This should not affect the ABI stability on Visual Studio builds.

Fixes: libxmlplusplus#45
@fanc999
Copy link
Collaborator Author

fanc999 commented Oct 21, 2022

Hi,

Thanks for the ack (I decided to drop the __declspec(dllexport) for the visibility macro)!

@fanc999 fanc999 merged commit 7fac1fd into libxmlplusplus:master Oct 21, 2022
@kjellahl
Copy link
Collaborator

Yesterday I tested

#define LIBXMLPP_VISIBILITY_DEFAULT __declspec(dllexport) __attribute__((visibility("default")))

and

#define LIBXMLPP_VISIBILITY_DEFAULT __declspec(dllexport)

Now you've chosen

#define LIBXMLPP_VISIBILITY_DEFAULT __attribute__((visibility("default")))

That does not work with the MinGW compiler.

The gcc manual says in the description of __attribute__((dllexport)) on Windows:

You can use __declspec(dllexport) as a synonym for __attribute__((dllexport)) for compatibility with other compilers.
On systems that support the visibility attribute, this attribute also implies “default” visibility.

__declspec(dllexport) seems to imply more than just default visibility.

@fanc999
Copy link
Collaborator Author

fanc999 commented Oct 21, 2022

Oh, sorry...

I will fix that in a bit, when I get my hands on my computer when I get back home.

Sorry about that

fanc999 pushed a commit that referenced this pull request Oct 21, 2022
Apparently it's not enough to decorate a class with
__attribute__((visibility("default"))), so also decorate it with
__declspec(dllexport), via macros as needed.

Pointed out by Kjell in PR #46.
@kjellahl
Copy link
Collaborator

Okay now.

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

Successfully merging this pull request may close these issues.

4 participants