From: Jason W. <jcw...@gm...> - 2006-07-18 18:41:21
|
I'm compiling a software project for windows and linux, using mingw and gcc. Platform-specific code is very minimal. The app has no resources to speak of, the executable is essentially 100% code. What I find when I finish the compile is the following executable sizes linux release executable: 1,766,572 bytes linux debug executable: 16,613,930 bytes win32 release executable: 2,726,912 bytes win32 debug executable: 98,052,647 bytes !!!! I find it very difficult to believe that a 2.7 MB executable needs an additional 95 MB (!) of debugging symbols to be useful in gdb. This is not a difference between debug and release as far as compiled in code. After i586-mingw32-strip of the win32 debug executable, it's left as a 2,144,768 byte executable. That tells me that there are in fact 95M of debug symbols in there. Am I missing some sort of strange -g option that causes it to emit an executable with sane debug symbols? Any advice about ways of getting this under control? Command options for the various make stages of the build process I'm using are as follows: i586-mingw32-gcc -pipe -O -mthreads -D_WIN32 -c -o x.o x.cpp i586-mingw32-ar -cr y.a x.o i586-mingw32-gcc -pipe -s -O -mthreads -D_WIN32 -o z.exe blahblahblah i586-mingw32-gcc -pipe -g -D_DEBUG -mthreads -D_WIN32 -c -o x.o x.cpp i586-mingw32-ar -cr y.a x.o i586-mingw32-gcc -pipe -g -D_DEBUG -mthreads -D_WIN32 -o z.exe blahblahblah i386-redhat-linux-gcc -pipe -O -pthread -D_REENTRANT -D_LINUX -c -o x.o x.cpp i386-redhat-linux-ar -cr y.a x.o i386-redhat-linux-gcc -pipe -s -O -pthread -D_REENTRANT -D_LINUX -o z.exeblahblahblah i386-redhat-linux-gcc -pipe -g -D_DEBUG -pthread -D_REENTRANT -D_LINUX -c -o x.o x.cpp i386-redhat-linux-ar -cr y.a x.o i386-redhat-linux-gcc -pipe -g -D_DEBUG -pthread -D_REENTRANT -D_LINUX -o z.exe blahblahblah |
From: Brian D. <br...@de...> - 2006-07-18 21:12:55
|
Jason Wenger wrote: > linux release executable: 1,766,572 bytes > linux debug executable: 16,613,930 bytes > win32 release executable: 2,726,912 bytes > win32 debug executable: 98,052,647 bytes !!!! This is just a result of the fact that the default debugging format for the gnu toolchain under Win32 is still stabs which is an old and somewhat clunky format. On linux they long ago moved to dwarf-2 as the default which is more efficient in representing the debug info with less duplication. Stabs just isn't all that sophisticated. You can try compiling your app under win32 using dwarf2 with -gdwarf-2 instead of just -g. (Note that the debugging format and the exception handling mode are two different things, and if you use -gdwarf-2 you still get SJLJ EH.) Brian |
From: Ed <ej...@id...> - 2006-07-19 14:38:57
|
Howdy all! I am trying to get mingw to build the freeware library I maintain, which is called "netcdf" and is used by climate scientists. It builds with autoconf/automake/libtool on any number of Unix platforms, but I am trying to build under mingw to get a DLL and free myself from Micro$oft development tools. (Not because we mind spending the money on the tools, but because maintaining two different sets of build files is a real pain). My library is building, and by adding the -shared option to AM_CFLAGS in the library's Makefile.am, it seems to cause mingw to build a dll. But instead of being called "netcdf.dll" as I expect, it is called "libnetcdf-1.dll" What is the deal with that? Am I doing something wrong, or is this expected? Of course I understand that I could use the -o option to cause gcc to name the output whatever I want, but why is the "-1" being added anyway? And why the "lib" on the front of a dll? Thanks! Ed /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -o libnetcdf.la -rpath /usr/local/lib -version-info 3:6:2 -no-undefined attr.lo ncx.lo putget.lo dim.lo error.lo libvers.lo nc.lo string.lo v1hpg.lo var.lo posixio.lo libnetcdf2.la libtool: link: gcc -shared .libs/attr.o .libs/ncx.o .libs/putget.o .libs/dim.o .libs/error.o .libs/libvers.o .libs/nc.o .libs/string.o .libs/v1hpg.o .libs/var.o .libs/posixio.o -Wl,--whole-archive ./.libs/libnetcdf2.a -Wl,--no-whole-archive -o .libs/libnetcdf-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libnetcdf-1.dll Creating library file: .libs/libnetcdf-1.dll libtool: link: (cd ".libs" && rm -f "libnetcdf.lib" && ln -s "libnetcdf-1.dll" "libnetcdf.lib") libtool: link: (cd .libs/libnetcdf.lax/libnetcdf2.a && ar x /c/cygwin/home/ed/netcdf-3/libsrc/./.libs/libnetcdf2.a) libtool: link: ar cru .libs/libnetcdf.a .libs/attr.o .libs/ncx.o .libs/putget.o .libs/dim.o .libs/error.o .libs/libvers.o .libs/nc.o .libs/string.o .libs/v1hpg.o .libs/var.o .libs/posixio.o .libs/libnetcdf.lax/libnetcdf2.a/v2i.o libtool: link: ranlib .libs/libnetcdf.a libtool: link: rm -fr .libs/libnetcdf.lax libtool: link: creating libnetcdf.la libtool: link: ( cd ".libs" && rm -f "libnetcdf.la" && ln -s "../libnetcdf.la" "libnetcdf.la" ) ed@IOLANTHE ~/netcdf-3/libsrc $ cd .libs/ ed@IOLANTHE ~/netcdf-3/libsrc/.libs $ ls attr.o libnetcdf-1.dll libnetcdf.lai libnetcdf2.la ncx.o string.o var.o dim.o libnetcdf.a libnetcdf.lib libvers.o posixio.o v1hpg.o error.o libnetcdf.la libnetcdf2.a nc.o putget.o v2i.o |
From: Keith M. <kei...@to...> - 2006-07-19 15:01:43
|
Ed wrote: > My library is building, and by adding the -shared option to AM_CFLAGS > in the library's Makefile.am, it seems to cause mingw to build a dll. > > But instead of being called "netcdf.dll" as I expect, it is called > "libnetcdf-1.dll" > > What is the deal with that? Am I doing something wrong, or is this > expected? IIRC, this was answered quite recently; please search the archives. > Of course I understand that I could use the -o option to cause gcc to > name the output whatever I want, but why is the "-1" being added > anyway? Don't you need to specify `-o' anyway? If you don't, your DLL ends up being called `a.exe', just as any other executable would be, without `-o'; (remember, on Windoze, a DLL is just a form of executable, but without a normal program entry point). > And why the "lib" on the front of a dll? There must be something in your build configuration, which causes it to be named that way. Regards, Keith. |
From: Paul <ele...@ya...> - 2006-07-20 01:12:23
|
Brian Dessent wrote: > Jason Wenger wrote: > > >>linux release executable: 1,766,572 bytes >>linux debug executable: 16,613,930 bytes >>win32 release executable: 2,726,912 bytes >>win32 debug executable: 98,052,647 bytes !!!! > > > This is just a result of the fact that the default debugging format for > the gnu toolchain under Win32 is still stabs which is an old and > somewhat clunky format. On linux they long ago moved to dwarf-2 as the > default which is more efficient in representing the debug info with less > duplication. Stabs just isn't all that sophisticated. > > You can try compiling your app under win32 using dwarf2 with -gdwarf-2 > instead of just -g. > > (Note that the debugging format and the exception handling mode are two > different things, and if you use -gdwarf-2 you still get SJLJ EH.) hi, sorry the mailing-list-search in sourceforge doesn't seem to be working? is there any reason to continue using stabs? can mingw's GDB (or cygwin's GDB) handle dwarf2 symbols? thanks Paul |
From: Keith M. <kei...@to...> - 2006-07-20 09:12:07
|
On Tuesday 18 July 2006 10:12 pm, Brian Dessent wrote: > Jason Wenger wrote: > > linux release executable: 1,766,572 bytes > > linux debug executable: 16,613,930 bytes > > win32 release executable: 2,726,912 bytes > > win32 debug executable: 98,052,647 bytes !!!! > > This is just a result of the fact that the default debugging format > for the gnu toolchain under Win32 is still stabs which is an old and > somewhat clunky format. On linux they long ago moved to dwarf-2 as > the default which is more efficient in representing the debug info > with less duplication. Stabs just isn't all that sophisticated. That may be so, but it hardly explains this anomaly: (first, on the Mandrake-8.2 box): $ uname -srm Linux 2.4.18-6mdk i686 $ cat hello.c #include <stdio.h> int main() { printf( "Hello, World.\n" ); return 0; } $ gcc --version 2.96 $ gcc -o hello-debug -g -march=i686 hello.c $ gcc -o hello-release -O3 -s -march=i686 hello.c $ i586-mingw32-gcc --version i586-mingw32-gcc (GCC) 3.4.4 (mingw special) $ i586-mingw32-gcc -o hello-debug.exe -g -march=i686 \ -mms-bitfields hello.c $ i586-mingw32-gcc -o hello-release.exe -O3 -s -march=i686 \ -mms-bitfields hello.c $ ls -l hello* -rw-r--r-- 1 keith users 78 Jul 19 22:03 hello.c -rwxr-xr-x 1 keith users 21092 Jul 19 22:18 hello-debug -rwxr-xr-x 1 keith users 962803 Jul 19 22:19 hello-debug.exe -rwxr-xr-x 1 keith users 3164 Jul 19 22:18 hello-release -rwxr-xr-x 1 keith users 5632 Jul 19 22:19 hello-release.exe (and now, a native MinGW on Win2K): $ uname -srm MINGW32_NT-5.0 1.0.9(0.46/3/2) i686 $ gcc --version gcc.exe (GCC) 3.2.3 (mingw special 20030504-1) $ gcc -o hello-release.exe -O3 -s -march=i686 -mms-bitfields hello.c $ gcc -o hello-debug.exe -g -march=i686 -mms-bitfields hello.c $ ls -l hello* -rw-r--r-- 1 keith 544 78 Jul 19 22:03 hello.c -rwxr-xr-x 1 keith 544 17223 Jul 20 09:14 hello-debug.exe -rwxr-xr-x 1 keith 544 5120 Jul 20 09:13 hello-release.exe Ok. The two compiler versions are different, which surely accounts for some variation in the *.exe sizes, but can it reasonably explain the whopping 5,490%, (yes, that *is* five thousand+), increase in size for the x-compiled debug executable, compared to its natively compiled counterpart, and to the more tolerable 10% increase for the release variant? I seriously doubt it. Just for the record, this i586-mingw32-gcc was built using the script published on our own MinGWiki. I've mentioned this anomaly before, on one or other of our mailing lists, but no one picked up on it. This x-compiler does seem to exhibit some weird behaviour, when it writes executables with debug symbols; it would be nice to understand why, and perhaps be able to do something about it. > You can try compiling your app under win32 using dwarf2 with -gdwarf-2 > instead of just -g. (once more, on the GNU/Linux box): $ i586-mingw32-gcc -o hello-debug.exe -gdwarf-2 -march=i686 \ -mms-bitfields hello.c $ ls -l hello-debug.exe -rwxr-xr-x 1 keith users 965195 Jul 19 22:32 hello-debug.exe Nope. That doesn't seem to help; now it's even *more* bloated. :-( (and again, on the Win2K box): $ gcc -o hello-debug.exe -gdwarf-2 -march=i686 -mms-bitfields hello.c cc1.exe: warning: `dwarf-2': unknown or unsupported -g option Which I guess is just an issue with this older version of GCC, but I have neither time nor sufficient incentive to upgrade just now. Regards, Keith. |
From: Luke D. <cod...@ho...> - 2006-07-20 13:57:57
|
----- Original Message ----- From: "Keith MARSHALL" <kei...@to...> To: "MinGW Users List" <min...@li...> Sent: Thursday, July 20, 2006 4:56 PM Subject: Re: [Mingw-users] Ridiculous debug executable sizes? > $ gcc --version > 2.96 > > $ gcc -o hello-debug -g -march=i686 hello.c > $ gcc -o hello-release -O3 -s -march=i686 hello.c > $ i586-mingw32-gcc --version > i586-mingw32-gcc (GCC) 3.4.4 (mingw special) > > $ i586-mingw32-gcc -o hello-debug.exe -g -march=i686 \ > -mms-bitfields hello.c > $ i586-mingw32-gcc -o hello-release.exe -O3 -s -march=i686 \ > -mms-bitfields hello.c > $ ls -l hello* > -rw-r--r-- 1 keith users 78 Jul 19 22:03 hello.c > -rwxr-xr-x 1 keith users 21092 Jul 19 22:18 hello-debug > -rwxr-xr-x 1 keith users 962803 Jul 19 22:19 hello-debug.exe > -rwxr-xr-x 1 keith users 3164 Jul 19 22:18 hello-release > -rwxr-xr-x 1 keith users 5632 Jul 19 22:19 hello-release.exe > > (and now, a native MinGW on Win2K): > > $ uname -srm > MINGW32_NT-5.0 1.0.9(0.46/3/2) i686 > > $ gcc --version > gcc.exe (GCC) 3.2.3 (mingw special 20030504-1) > > $ gcc -o hello-release.exe -O3 -s -march=i686 -mms-bitfields hello.c > $ gcc -o hello-debug.exe -g -march=i686 -mms-bitfields hello.c > $ ls -l hello* > -rw-r--r-- 1 keith 544 78 Jul 19 22:03 hello.c > -rwxr-xr-x 1 keith 544 17223 Jul 20 09:14 hello-debug.exe > -rwxr-xr-x 1 keith 544 5120 Jul 20 09:13 hello-release.exe > > Ok. The two compiler versions are different, which surely accounts > for some variation in the *.exe sizes, but can it reasonably explain > the whopping 5,490%, (yes, that *is* five thousand+), increase in size > for the x-compiled debug executable, compared to its natively compiled > counterpart, and to the more tolerable 10% increase for the release > variant? I seriously doubt it. It does seem excessive, but my guess is that the libraries you are linking to (libgcc.a, libmingwex.a, possibly more) contain debug symbols on your Linux cross-compiler, while the distributed binary versions of the same libraries do not contain debugging symbols. Comparing the size of these libraries and/or stripping them should tell you more. Luke |
From: Keith M. <kei...@to...> - 2006-07-20 14:57:44
|
Luke Dunstan wrote, quoting me: >> Ok. The two compiler versions are different, which surely accounts >> for some variation in the *.exe sizes, but can it reasonably explain >> the whopping 5,490%, (yes, that *is* five thousand+), increase in size >> for the x-compiled debug executable, compared to its natively compiled >> counterpart, and to the more tolerable 10% increase for the release >> variant? I seriously doubt it. > > It does seem excessive, but my guess is that the libraries you are > linking to (libgcc.a, libmingwex.a, possibly more) contain debug > symbols on your Linux cross-compiler, while the distributed binary > versions of the same libraries do not contain debugging symbols. > Comparing the size of these libraries and/or stripping them should > tell you more. Hmm. That makes sense. I'll explore that avenue, when I get a chance. If this should turn out to be the case, then I guess we should think about modifying the published build script, so those x-hosted libraries get built without debugging symbols. Thanks, Luke. Regards, Keith. |
From: Luke D. <cod...@ho...> - 2006-07-20 14:05:48
|
----- Original Message ----- From: "Ed" <ej...@id...> To: "MinGW Users List" <min...@li...> Sent: Wednesday, July 19, 2006 10:38 PM Subject: [Mingw-users] question about building dlls - why is a "-1" added tothe name? > Howdy all! > > I am trying to get mingw to build the freeware library I maintain, > which is called "netcdf" and is used by climate scientists. > > It builds with autoconf/automake/libtool on any number of Unix > platforms, but I am trying to build under mingw to get a DLL and free > myself from Micro$oft development tools. (Not because we mind spending > the money on the tools, but because maintaining two different sets of > build files is a real pain). > > My library is building, and by adding the -shared option to AM_CFLAGS > in the library's Makefile.am, it seems to cause mingw to build a dll. > > But instead of being called "netcdf.dll" as I expect, it is called > "libnetcdf-1.dll" > > What is the deal with that? Am I doing something wrong, or is this > expected? >From what I've seen of libtool this is normal. > Of course I understand that I could use the -o option to cause gcc to > name the output whatever I want, but why is the "-1" being added > anyway? And why the "lib" on the front of a dll? The -o option is always required when linking unless you want to use the default name (a.exe). As you can see in your build output, this option *is* being passed to gcc by libtool. For this reason, MinGW is not the issue and you should ask on a libtool mailing list. Luke > > Thanks! > > Ed > > /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -o > libnetcdf.la -rpath /usr/local/lib -version-info 3:6:2 -no-undefined > attr.lo ncx.lo putget.lo dim.lo error.lo libvers.lo nc.lo string.lo > v1hpg.lo var.lo posixio.lo libnetcdf2.la > libtool: link: gcc -shared .libs/attr.o .libs/ncx.o .libs/putget.o > .libs/dim.o .libs/error.o .libs/libvers.o .libs/nc.o .libs/string.o > .libs/v1hpg.o .libs/var.o .libs/posixio.o -Wl,--whole-archive > ./.libs/libnetcdf2.a -Wl,--no-whole-archive -o > .libs/libnetcdf-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker > .libs/libnetcdf-1.dll |