lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi] Forcing linking of the library modules (again)


From: Vadim Zeitlin
Subject: [lmi] Forcing linking of the library modules (again)
Date: Fri, 15 Aug 2014 22:47:32 +0200

 Hello,

 We had briefly discussed this before in

        http://lists.nongnu.org/archive/html/lmi/2005-11/msg00011.html

but I've recently realized that the problem I had back then has never been
actually fixed and I'm now running into it when executing the GUI tests.

 Even before explaining what the problem actually is, I'd like to propose
my solution which, for the first instance of the problem, would be this
patch:

----------------------------------------------------------------------------
diff --git a/main_wx.cpp b/main_wx.cpp
index d2f8fae..0eb0ffb 100644
--- a/main_wx.cpp
+++ b/main_wx.cpp
@@ -44,9 +44,15 @@
 #include "skeleton.hpp"

 #include <wx/init.h>                    // wxEntry()
+#include <wx/link.h>

 #include <string>

+// This is required to ensure that the corresponding object file is not simply
+// discarded by an optimized linker (such as MSVC one) as otherwise the code
+// setting up the progress meter creator would simply not be executed at all.
+wxFORCE_LINK_MODULE(progress_meter_wx)
+
 IMPLEMENT_APP_NO_MAIN(Skeleton)
 IMPLEMENT_WX_THEME_SUPPORT

diff --git a/progress_meter_wx.cpp b/progress_meter_wx.cpp
index 4747101..1ae961a 100644
--- a/progress_meter_wx.cpp
+++ b/progress_meter_wx.cpp
@@ -30,12 +30,15 @@

 #include "wx_utility.hpp"               // TopWindow()

+#include <wx/link.h>
 #include <wx/progdlg.h>
 #include <wx/utils.h>                   // wxMilliSleep()

 #include <ios>                          // std::fixed, 
std::ios_base::precision()
 #include <sstream>

+wxFORCE_LINK_THIS_MODULE(progress_meter_wx)
+
 namespace
 {
 // Implicitly-declared special member functions do the right thing.
----------------------------------------------------------------------------

[Please notice that if you agree with applying the patch above, there is no
 need to read the rest of this message, just let me know and I'll prepare
 the full patch. But here are more explanations, just in case:]


 The comment added by the patch basically explains what is going on: when
building lmi_wx.exe using MSVC, the file progress_meter_wx.cpp, which is
part of the skeleton library, is simply not linked in at all because the
main program doesn't reference any of its symbols and Microsoft linker
completely discards all the object files which it considers to be unneeded.
This results in set_progress_meter_creator() being never called, as the
global "ensure_setup" variable in this file is never initialized because
it's simply not present in the final binary.

 The fix works by ensuring that the main program does reference some symbol
from this file, this symbol is created by wxFORCE_LINK_THIS_MODULE() and
referenced by wxFORCE_LINK_MODULE(). To the best of my knowledge, this is
the simplest possible solution and doesn't have any drawbacks -- except for
the need to add the two lines in each of N files needing to be referenced
and N+1 lines to main_wx.cpp to reference them.

 For completeness, I could also use the linker /include option to
explicitly reference the symbol, which would avoid the need to modify
main_wx.cpp. But progress_meter_wx.cpp and {file,system}_command_wx.cpp
would still need to be modified because they don't contain any symbols that
could be used right now, the only public symbol in system_command_wx.cpp
for example is "address@hidden@@3_NC" which is probably not
something I can use at all as the hex number embedded inside it can
probably change. So I don't really see any advantage to using this.

 Finally, while the problem is MSVC-specific currently, it's not impossible
that other linkers, possibly including future versions of binutils, could
behave like this as well, while annoying in this particular case, there is
a huge benefit, in terms of the size of the final binaries, to discard the
unused object files when using static libraries.

 So would you be willing to apply the patch adding these macros to all the
affected files (once I find all of them...)? This would fix MSVC build I
use for debugging and shouldn't have any negative effects for anything
else.

 Thanks in advance,
VZ

reply via email to

[Prev in Thread] Current Thread [Next in Thread]