[MDEV-6053] Debug info for static libraries is not included into Windows packages Created: 2014-04-09  Updated: 2018-02-06  Resolved: 2018-02-06

Status: Closed
Project: MariaDB Server
Component/s: Compiling, Packaging
Affects Version/s: 5.5.37, 10.0.10
Fix Version/s: N/A

Type: Bug Priority: Trivial
Reporter: Elena Stepanova Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: debug-info, packaging, windows
Environment:

Windows, cmake 2.8.12+

Issue Links:
Relates
relates to MDEV-6016 Packaging error with cmake 2.8.12 and... Closed

 Description   

This is an offspring of MDEV-6016, which fixed the immediate problem of packages not being built with cmake 2.8.12 due to the missing pdb files.

However, it means that static libraries won't have debug information, which might be sometimes needed. Since including the debug info costs considerable increase of the package size, I think it makes sense to keep it open for now and see if anybody actually requests it.

Here is Wlad's comment and proposed fix (from comments to MDEV-6016):

I tested the mentioned change for debuginfo format from /Zi to /Z7, and it seems to work well. The noticable change is that static libraries will be bigger in size (this of course applies to the libraries themselves, not to programs they link to). So I conclude, if the size of embedded library = 300M does not bother too many people, /Z7 should be quite ok. The whole patch is below.

=== modified file 'cmake/os/Windows.cmake'
 
--- cmake/os/Windows.cmake	2011-06-30 15:46:53 +0000
 
+++ cmake/os/Windows.cmake	2014-04-04 06:02:17 +0000
 
@@ -71,13 +71,15 @@
 
    SET(CMAKE_{type}_LINKER_FLAGS_RELEASE "${CMAKE_${type}_LINKER_FLAGS_RELEASE} /debug")
 
   ENDFOREACH()
 
   
-  # Force static runtime libraries
 
+  # Force static runtime libraries. 
+  # Force /Z7 instead of default /Zi to have debug symbols in static libraries.
 
   FOREACH(flag 
    CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_RELWITHDEBINFO 
    CMAKE_C_FLAGS_DEBUG CMAKE_C_FLAGS_DEBUG_INIT 
    CMAKE_CXX_FLAGS_RELEASE  CMAKE_CXX_FLAGS_RELWITHDEBINFO
 
    CMAKE_CXX_FLAGS_DEBUG  CMAKE_CXX_FLAGS_DEBUG_INIT)
 
    STRING(REPLACE "/MD"  "/MT" "${flag}" "${${flag}}")
 
+   STRING(REPLACE "/Zi"  "/Z7" "${flag}" "${${flag}}")
 
   ENDFOREACH()
 
   
   # Remove support for exceptions

Here are results of my measurements for package size change:

VS 10 / cmake 2.8.5, 4131 before Zi=>Z7
 
  141813729  mariadb-5.5.37-winx64.zip
 
  72740006   mysqlserver.lib
 
  644775646  mariadb-5.5.37-winx64
 
 
 
VS 10 / cmake 2.8.5, 4131 after Zi=>Z7
 
  186232673  mariadb-5.5.37-winx64.zip
 
  223535446  mysqlserver.lib
 
  800908270  mariadb-5.5.37-winx64
 
 
 
VS 11 / cmake 2.8.12 4131 before Zi=>Z7
 
  147336732  mariadb-5.5.37-winx64.zip
 
  74633374   mysqlserver.lib
 
  647495889  mariadb-5.5.37-winx64
 
 
 
VS 11 / cmake 2.8.12 4131 after Zi=>Z7
 
  213447432  mariadb-5.5.37-winx64.zip
 
  602570110  mysqlserver.lib
 
  1182596977 mariadb-5.5.37-winx64



 Comments   
Comment by Daniel Black [ 2018-02-05 ]

Seems like an easy add wlad.

Also the cmake bug for MDEV-6016 was fixed in 3.0

diff --git a/cmake/install_macros.cmake b/cmake/install_macros.cmake
 
index 5ca147d0d60..907cc3f6cb0 100644
 
--- a/cmake/install_macros.cmake
 
+++ b/cmake/install_macros.cmake
 
@@ -52,7 +52,7 @@ FUNCTION (INSTALL_DEBUG_SYMBOLS)
 
     IF(NOT comp)
 
       SET(comp Debuginfo_archive_only) # not in MSI
 
     ENDIF()
 
-    IF(NOT target_type MATCHES "STATIC")
 
+    IF(CMAKE_VERSION VERSION_GREATER 3.0.0 OR NOT target_type MATCHES "STATIC")
 
       INSTALL(FILES $<TARGET_PDB_FILE:${target}> DESTINATION ${ARG_INSTALL_LOCATION} COMPONENT ${comp})
 
     ENDIF()
 
   ENDFOREACH()

Comment by Vladislav Vaintroub [ 2018-02-05 ]

danblack, we use /Z7 since long time now. With it, the debug symbols are inside the object files, and thus inside the static libraries. We also distribute only one static library now, the client library (we do not include embedded into packages anymore), so the size problem no more acute.

Comment by Daniel Black [ 2018-02-06 ]

Ah ok. so this can be closed now?

Comment by Vladislav Vaintroub [ 2018-02-06 ]

danblack, yes, I'm closing it since it is not longer a problem

Generated at Thu Feb 08 07:09:01 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.