From: Jef D. <jef...@ho...> - 2008-05-27 20:50:47
|
Hello, I'm working on a C project that consist mainly of small library for communication over a serial port and some applications built on top of that library. Each function in the library has two different implementations, one for linux (using termios) and one for windows (using win32 api functions). The linux version is of course compiled under linux, and the windows version is cross compiled on the same linux machine (or directly on windows with mingw/msys, but that makes not much difference). $gcc --version gcc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7) $i586-mingw32msvc-gcc --version i586-mingw32msvc-gcc (GCC) 4.2.1-sjlj (mingw32-2) Both versions are compiled with an autotools project (using libtool to build a shared library). It chooses the correct backend, but for the rest, the compiler settings are exactly the same. $./configure && make $./configure --host i586-mingw32msvc && make The resulting linux so file is 97.4KB in size, but the windows dll is 462.2KB, which is almost 5 times larger. What is causing this and is this normal? The win32 object files are only 83.2KB in total and the static library is only a few KB larger (85.2KB). The linux object files are almost twice as large (159.2KB). So I don't understand what is causing this. If I strip both libraries, the sizes are more comparable: 33.7KB for the linux so file and 25.OKB for the windows dll. I'm seeing very similar numbers for the application executables. |
From: Brian D. <br...@de...> - 2008-05-27 21:46:16
|
Jef Driesen wrote: > are almost twice as large (159.2KB). So I don't understand what is > causing this. > > If I strip both libraries, the sizes are more comparable: 33.7KB for the > linux so file and 25.OKB for the windows dll. So, the difference you're seeing is due purely to debug info and not actual code (and therefore mostly irrelevant since debug info does not get loaded into memory, it only takes up disk space.) You will find that the PE platform still defaults to STABS for debug format whereas linux defaults to Dwarf-2, and STABS is much larger because it's an older and cruder format. If you switch to Dwarf-2 debug info (-gdwarf-2 instead of -g) then the sizes should be comparable. Note that this has nothing to do with Dwarf-2 exception handling, using -gdwarf-2 does not affect EH -- that cannot be switched at runtime, it is configured when the compiler is built. Brian |
From: Jef D. <jef...@ho...> - 2008-05-28 07:13:19
|
Brian Dessent wrote: > Jef Driesen wrote: >> The resulting linux so file is 97.4KB in size, but the windows dll is >> 462.2KB, which is almost 5 times larger. What is causing this and is >> this normal? The win32 object files are only 83.2KB in total and the >> static library is only a few KB larger (85.2KB). The linux object files >> are almost twice as large (159.2KB). So I don't understand what is >> causing this. >> >> If I strip both libraries, the sizes are more comparable: 33.7KB for the >> linux so file and 25.OKB for the windows dll. > > So, the difference you're seeing is due purely to debug info and not > actual code (and therefore mostly irrelevant since debug info does not > get loaded into memory, it only takes up disk space.) You will find > that the PE platform still defaults to STABS for debug format whereas > linux defaults to Dwarf-2, and STABS is much larger because it's an > older and cruder format. If you switch to Dwarf-2 debug info (-gdwarf-2 > instead of -g) then the sizes should be comparable. I tried compiling with CFLAGS='-gdwarf-2', but the size reduction is only about 10KB (for both the object files and the final dll). I also tried with CFLAGS='-g0' to disable debug info, and the size reduction is now around 40KB. So I don't think the debug info is the problem here. The size of the object files and static library is reasonable small (even with the debug info), but once those object files get linked to build the dll, the size increase drastically. > Note that this has nothing to do with Dwarf-2 exception handling, using > -gdwarf-2 does not affect EH -- that cannot be switched at runtime, it > is configured when the compiler is built. This is a C project, not C++, so I don't think EH has anything to do with it. |
From: Brian D. <br...@de...> - 2008-05-28 07:39:28
|
Jef Driesen wrote: > I tried compiling with CFLAGS='-gdwarf-2', but the size reduction is > only about 10KB (for both the object files and the final dll). I also > tried with CFLAGS='-g0' to disable debug info, and the size reduction is > now around 40KB. So I don't think the debug info is the problem here. You said already that stripping the DLL eliminates the discrepancy, and that amounts to nothing more than removing sections containing debug info. So of course it's the debug info. Note that changing CFLAGS only affects the debug info generated for your objects. You also have to consider that you may be linking with a library with STABS debug data when linking the DLL -- things such as libmingw, libmingwex, and the dllcrt2.o startup code all contain code that is linked into your DLL and all can have debug info depending on how they were built. The contents of the file is not a mystery. Use objdump -h to see the sections and their sizes. For example, if you build your objects without -g and you still see .stab/.stabstr and/or .debug_* sections, you know that you're pulling in debug data from those other sources. > > Note that this has nothing to do with Dwarf-2 exception handling, using > > -gdwarf-2 does not affect EH -- that cannot be switched at runtime, it > > is configured when the compiler is built. > > This is a C project, not C++, so I don't think EH has anything to do > with it. I never said that EH had anything to do with your size issue, I just wanted to make it clear for the archives that selecting Dwarf-2 vs STABS for the debug format has nothing to do with choosing Dwarf-2 vs SJLJ for the EH method. Brian |
From: Jef D. <jef...@ho...> - 2008-05-28 08:30:20
|
Brian Dessent wrote: > Jef Driesen wrote: > >> I tried compiling with CFLAGS='-gdwarf-2', but the size reduction is >> only about 10KB (for both the object files and the final dll). I also >> tried with CFLAGS='-g0' to disable debug info, and the size reduction is >> now around 40KB. So I don't think the debug info is the problem here. > > You said already that stripping the DLL eliminates the discrepancy, and > that amounts to nothing more than removing sections containing debug > info. So of course it's the debug info. > > Note that changing CFLAGS only affects the debug info generated for your > objects. You also have to consider that you may be linking with a > library with STABS debug data when linking the DLL -- things such as > libmingw, libmingwex, and the dllcrt2.o startup code all contain code > that is linked into your DLL and all can have debug info depending on > how they were built. > > The contents of the file is not a mystery. Use objdump -h to see the > sections and their sizes. For example, if you build your objects > without -g and you still see .stab/.stabstr and/or .debug_* sections, > you know that you're pulling in debug data from those other sources. I checked, and there are indeed .stab and .stabstr sections present. So now that I know where the size increase is coming from, how do I avoid it? Is there a compiler flag to automatically strip the produced binary? I tried CFLAGS='-s', but it only strips the object files, thus producing exactly the same result as with CFLAGS='-g0'. >>> Note that this has nothing to do with Dwarf-2 exception handling, using >>> -gdwarf-2 does not affect EH -- that cannot be switched at runtime, it >>> is configured when the compiler is built. >> This is a C project, not C++, so I don't think EH has anything to do >> with it. > > I never said that EH had anything to do with your size issue, I just > wanted to make it clear for the archives that selecting Dwarf-2 vs STABS > for the debug format has nothing to do with choosing Dwarf-2 vs SJLJ for > the EH method. Then I just misunderstood you. |
From: Lothar M. <mi...@lo...> - 2008-05-28 08:32:06
|
Jef Driesen wrote: [...] > I checked, and there are indeed .stab and .stabstr sections present. So > now that I know where the size increase is coming from, how do I avoid > it? Is there a compiler flag to automatically strip the produced binary? Try -s Best regards, Lothar |
From: Jef D. <jef...@ho...> - 2008-05-28 08:52:25
|
Lothar May wrote: > Jef Driesen wrote: > [...] >> I checked, and there are indeed .stab and .stabstr sections present. So >> now that I know where the size increase is coming from, how do I avoid >> it? Is there a compiler flag to automatically strip the produced binary? > > Try -s If I use compile directly from the shell, this works perfectly and produces a small dll $i586-mingw32msvc-gcc -s -shared $SOURCES -o mylib.dll But with the configure script, the setting seems to affect only my own object files, not the dll. $CFLAGS='-s' ./configure |
From: Brian D. <br...@de...> - 2008-05-28 08:38:43
|
Jef Driesen wrote: > I checked, and there are indeed .stab and .stabstr sections present. So > now that I know where the size increase is coming from, how do I avoid > it? Is there a compiler flag to automatically strip the produced binary? > > I tried CFLAGS='-s', but it only strips the object files, thus producing > exactly the same result as with CFLAGS='-g0'. You can: - strip the library - rebuild the library without debug info - pass '-s' to the linker (i.e. LDFLAGS=-Wl,-s) when linking the DLL (not during compilation, since that won't affect existing objects in the libraries) Brian |
From: Lothar M. <mi...@lo...> - 2008-05-28 08:58:19
|
> You can: > > - strip the library [...] For whatever reason, using "strip" produces larger files than using -s for both compiling and linking. At least in my experience. Best regards, Lothar |
From: Jef D. <jef...@ho...> - 2008-05-28 09:04:45
|
Brian Dessent wrote: > Jef Driesen wrote: > >> I checked, and there are indeed .stab and .stabstr sections present. So >> now that I know where the size increase is coming from, how do I avoid >> it? Is there a compiler flag to automatically strip the produced binary? >> >> I tried CFLAGS='-s', but it only strips the object files, thus producing >> exactly the same result as with CFLAGS='-g0'. > > You can: > > - strip the library This works, but is not really what I'm looking for, because I would like to have it integrated in my autotools project (and I don't know how to that). > - rebuild the library without debug info But in this case, I still get the debug info from those other files (crt,...) that get linked to my library, right? > - pass '-s' to the linker (i.e. LDFLAGS=-Wl,-s) when linking the DLL > (not during compilation, since that won't affect existing objects in the > libraries) This one works great! Thanks for your help! |
From: Brian D. <br...@de...> - 2008-05-28 09:22:02
|
Jef Driesen wrote: > > - rebuild the library without debug info > > But in this case, I still get the debug info from those other files > (crt,...) that get linked to my library, right? What I mean here is rebuild mingw-runtime with CFLAGS=-O2 and you will have a libmingw32, libmingwex, and crt*.o without any debug sections. The binary mingw-runtime package that is at the MinGW download site is built this way (no debug sections) so this must be due to using a self-built or otherwise different build of mingw-runtime on your local installation. Brian |
From: Vincent T. <vt...@un...> - 2008-05-28 08:36:25
|
On Wed, 28 May 2008, Jef Driesen wrote: > I checked, and there are indeed .stab and .stabstr sections present. So > now that I know where the size increase is coming from, how do I avoid > it? Is there a compiler flag to automatically strip the produced binary? > > I tried CFLAGS='-s', but it only strips the object files, thus producing > exactly the same result as with CFLAGS='-g0'. do that at link time (LDFLAGS="-s") if you're using the autotools, use 'make install-strip'. Vincent Torri |
From: Jef D. <jef...@ho...> - 2008-05-28 08:57:43
|
Vincent Torri wrote: > > On Wed, 28 May 2008, Jef Driesen wrote: >> I checked, and there are indeed .stab and .stabstr sections present. So >> now that I know where the size increase is coming from, how do I avoid >> it? Is there a compiler flag to automatically strip the produced binary? >> >> I tried CFLAGS='-s', but it only strips the object files, thus producing >> exactly the same result as with CFLAGS='-g0'. > > do that at link time (LDFLAGS="-s") That doesn't seem to make a difference. But using LDFLAGS='-Wl,-s', as suggested by Brian, does work! > if you're using the autotools, use 'make install-strip'. This only seems to strip the application binaries (exe), not the library (dll). |