GNOME Bugzilla – Bug 749091
glibmm should not rely on gendef on Windows with MSVC but use __declspec(dllexport) instead
Last modified: 2018-05-22 12:11:19 UTC
Created attachment 303059 [details] [review] Missing GLIBMM_API & GIOMM_API for MSVC This is an umbrella bug to track removal of gendef and use of conditional macros GLIBMM_API and GIOMM_API instead for importing/exporting symbols from DLLs on Windows when building with MSVC. It was mentioned in bug 719847, bug 748719 and alike that there is a mixture of import/export macros but gendef is still used. However it would be really nice to build glibmm and the rest the same way as, e.g., libsigc++, i.e. without gendef. I'm attaching a patch that adds missing definitions. It should not cause a havoc on other platforms, but I'd appreciate the feedback. I tested the build on Windows with msys2/mingw32/gcc 4.9.2 and MS VC++ 2012 using CMake. The latter is unofficial and details can be found at https://github.com/mlt/gtkmm . It is not a final solution and shall not break existing build infrastructure. Some things still might be missing. However gtkmm demo and gstreamermm demo compiles and runs fine. Traces of gendef have not been removed.
Do you want the patch pushed to the git repository? Or do you first want it commented and tested by other Windows programmers? Your comment here, and especially bug 719847 comment 5, make me uncertain of your intention.
Mikhail, please reply if you want me to push your patch to the git repository.
Kjell, I apologize for the delay. Upon reviewing I noticed I unintentionally included few commented out lines that shall be gone. I hope that someone would test it first before pushing. At least it would be nice to confirm it does not break anything else so far on other platforms. However I understand it might be tedious to test without adjusting MSVC projects accordingly or having CMake project available. I would like to embed CMakeLists.txt generation into autotools/Makefile files so there won't be a need to maintain separate source files lists. However it makes sense to start a bit earlier, i.e. with libsigc++ as I start building from there on top of MSYS2/MinGW. For a moment I was puzzled whether using CMake on Windows worth it as compared e.g. to Boost.Build provided some anecdotal rumors on BB future. However I think such discussion suits mailing list better. Could we keep it open for a while? I will clean up the patch.
> I hope that someone would test it first before pushing. I can confirm that I can build glibmm with 'make && make check' on my Linux Ubuntu system after I applied your patch. I had to apply it manually to 3 of the files, because I have made changes to glibmm after you filed your patch. BUT, building gtkmm fails! Surprising, isn't it? Explanation: Your patch modifies tools/m4/class_*.m4. They add *MM_API to the generated code. That's all right provided *MM_API is defined, especially if it's defined as an empty string. But GDKMM_API is not defined. The preprocessor replaces undefined macros with 0 (zero), and that's not all right. Of course it's easy to add a suitable definition of GDKMM_API to gtkmm/gdk/gdkmmconfig.h.in. But this may affect an unknown number of other MM modules. When I prepared bug 719847, I found that PANGOMM_API is also undefined. > I would like to embed CMakeLists.txt generation into autotools/Makefile files Have you seen the libsigc++ bug 599709? It discusses CMake. > Could we keep it open for a while? I will clean up the patch. Sure, no problem.
> The preprocessor replaces undefined macros with 0 (zero) No, it does not. It does that in #if statements. Elsewhere GDKMM_API is not replaced. The compiler sees Glib::RefPtr<Gdk::Cursor> GDKMM_API wrap(GdkCursor* object, bool take_copy)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glibmm/issues/12.