Many years ago I built glibmm and giomm (32-bit versions) using Visual Studio 2005. I’m now trying to update to 64-bit builds (still with glibmm-2-44) using VS2019. All the various supporting libs have built okay.
Visual Studio offers a mode called “Link time code generation” which can optimize a Release build (so traditionally, I’ve turned it on for my Release builds - and previously it never caused any problems…) However, I’ve noticed that if I turn it on for my 64-bit VS2019 builds, glibmm and giomm end up with no exported symbols (basically, gendef32.exe produces empty “.def” files). So consequently, giomm can’t find anything when it tries to link to glibmm. 2 questions:-
Is this a known problem?
I’m still using my older version of gendef32.exe. I can’t remember where I got it from but should I be trying a newer version? Or is there maybe a gendef64.exe that I need to use for 64-bit builds?
[Edit…] Since first posting I’ve realised that this happens if I have ANY of the optimizations enabled. When building 64-bit versions of glibmm or giomm I need to have optimizations disabled in order to get a valid .def file (that probably explains why a Debug version builds okay - but it doesn’t seem right somehow…)
In fact can I just ask if .def files are still the recommended way for linking between giomm and glibmm? I just noticed that even though they get generated now (when I disable optimizations) there seems to be a lot of stuff missing - so the link stage still fails…
Thanks for the prompt reply, lb90. The problem is that glibmm and giomm both #define __decspec(dllimport) but they don’t #define__declspec(dllexport) - in fact the header files glibmmconfig.h and giommconfig.h both contain a note saying that this is deliberate and to leave it all up to gendef… gendef worked fine for my 32-bit builds but it seems a bit flaky for 64-bit
I’m quite happy to edit the code but I’m wondering if the strategy got changed later? gtkmm-2.44 is quite old now but I don’t want to update just yet (if I’ll still end up seeing the same problem…)
BTW - I did check with dumpbin /EXPORTS and yes… whenever the .def file is empty, the built DLL contains no exported symbols.
Overnight it occurred to me that this might be due to some change in Visual Studio itself. To me, the term ‘Link time code generation’ implies that the code generation will get delayed somehow - so maybe (in VS2019) it’s been delayed to a point where the code simply isn’t available yet when gendef starts to do its stuff? If that’s the case, it might be necessary to abandon gendef and work with the more usual __declspec(dllexport)
Is there anyone here who still builds with MSVC - even a slightly earlier version such as VS2015 or 2017? All I know is that this wasn’t causing problems in VS2005 and 2008 - but of course it could have happened anytime since then.
As well as glibmm I’ve now managed to reproduce this with giomm, atkmm and cairomm (haven’t tried the other ones yet). So given that it affects several different libraries, where would be the best place to report it?
Also… might it be helpful if someone else can manage to replicate the problem? Is there anyone else here who could try this with an MSVC build?
