From: Dan <dan...@bt...> - 2010-12-07 13:35:23
|
Hi, I need to rebuild mingw32-make.exe configured with the --enable-case-insensitive-file-system (it's a requirement for some work I'm doing). While I can do work with no problem, the resulting .exe I get seems rather large varying between ~270KB and 1.7MB depending on other flags (e.g. --disable-nls, --disable-rpath) I gave to to configure and the environment variables I set (e.g. CFLAGS, LIBS, LDFLAGS). I've noticed that the mingw32-make.exe that mingw-get installs for you is only 190KB. So my question is, what command line options were used to the configure script that resulted in such a small .exe as installed by mingw-get? I'm guess the 190KB from mingw-get is dynamically linked, whereas the 1.7MB "monster" I built earlier was statically linked. Even when I didn't use --enable-case-insensitive-file-system I got comparatively large .exe's in the various attempts I made. I'm using MinGW's GCC 4.5.0 for the build and the MSYS Bash with MSYSTEM=MINGW32 running on Windows XP. Many thanks, Dan |
From: Earnie <ea...@us...> - 2010-12-07 13:40:32
|
Dan wrote: > > I've noticed that the mingw32-make.exe that mingw-get installs for you is > only 190KB. So my question is, what command line options were used to the > configure script that resulted in such a small .exe as installed by mingw-get? > Probably the packager used the strip command on the executable before packaging it. > I'm guess the 190KB from mingw-get is dynamically linked, whereas the 1.7MB > "monster" I built earlier was statically linked. Even when I didn't use > --enable-case-insensitive-file-system I got comparatively large .exe's > in the various attempts I made. > You would guess wrong try ``strip mingw32-make.exe'' and watch your executable file disk size shrink. -- Earnie -- http://www.for-my-kids.com |
From: Dan <dan...@bt...> - 2010-12-07 14:20:34
|
Earnie <earnie@...> writes: > Probably the packager used the strip command on the executable before > packaging it. Yes, I did wonder, but it would be useful to know for sure. I'm wondering if the packagers has used --disable-nls and/or --disable-rpath to the configure script. > You would guess wrong try ``strip mingw32-make.exe'' and watch your > executable file disk size shrink. I still can't get under 207KB, so I must be doing something else "wrong". For reference, stripping my 1.7MB "monster" reduces it to 1.2MB. I'm using all the options "-g -S -d --strip-debug -s -x" to strip. And minimal 207KB version remains at that size. |
From: Keith M. <kei...@us...> - 2010-12-07 15:22:47
|
On 7 December 2010 13:28, Dan <danny.jacobs@...> wrote: > I need to rebuild mingw32-make.exe configured with the > --enable-case-insensitive-file-system (it's a requirement for some > work I'm doing). Chris always used to tell us what flags he specified, within the text of his release notices: http://search.gmane.org/?query=mingw32-make&author=chris+sutcliffe&group=gmane.comp.gnu.mingw.user For some unexplained reason, he seems to have omitted it for the most recent release. AFAIK, past releases have always specified: --enable-case-insensitive-filesystem (amongst other options); I can't guarantee it, without confirmation from Chris, but there seems little reason to have changed this for 3.82. -- Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2010-12-07 15:37:52
|
On 7 December 2010 10:22, Keith Marshall wrote: > On 7 December 2010 13:28, Dan <danny.jacobs@...> wrote: >> I need to rebuild mingw32-make.exe configured with the >> --enable-case-insensitive-file-system (it's a requirement for some >> work I'm doing). > > Chris always used to tell us what flags he specified, within the text of > his release notices: > http://search.gmane.org/?query=mingw32-make&author=chris+sutcliffe&group=gmane.comp.gnu.mingw.user > > For some unexplained reason, he seems to have omitted it for the most > recent release. > > AFAIK, past releases have always specified: > > --enable-case-insensitive-filesystem > > (amongst other options); I can't guarantee it, without confirmation from > Chris, but there seems little reason to have changed this for 3.82. Agreed, I will rebuild and test a new release. All going well, a 3.82-2 should be out shortly. Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Chris S. <ir0...@gm...> - 2010-12-07 16:10:13
|
On 7 December 2010 10:37, Chris Sutcliffe wrote: > On 7 December 2010 10:22, Keith Marshall wrote: >> AFAIK, past releases have always specified: >> >> --enable-case-insensitive-filesystem >> >> (amongst other options); I can't guarantee it, without confirmation from >> Chris, but there seems little reason to have changed this for 3.82. > > Agreed, I will rebuild and test a new release. All going well, a > 3.82-2 should be out shortly. It turns out I missed these configuration options when building the previous 3.82: --disable-dependency-tracking --disable-nls --enable-case-insensitive-file-system --disable-job-server --disable-rpath For historical reasons I had kept using these options prior to 3.82, but looking at them now, I don't know if they are all still relevant. Given that we are starting to support natural language, I propose dropping "--disable-nls". The job server is not implemented for Win32, so the "--disable-job-server" is fine, if not irrelevant. The "--disable-rpath" option by definition "Disables passing additional runtime library search paths", do we in fact want to do that? I'm also trying to determine if "--disable-dependency-tracking" is still valid, given that as near as I can tell it's only benefit is to speed up one-time builds. I'm open to suggestions on this one. Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Charles W. <cwi...@us...> - 2010-12-07 16:50:23
|
On 12/7/2010 11:10 AM, Chris Sutcliffe wrote: > It turns out I missed these configuration options when building the > previous 3.82: > > --disable-dependency-tracking > --disable-nls > --enable-case-insensitive-file-system > --disable-job-server > --disable-rpath > > For historical reasons I had kept using these options prior to 3.82, > but looking at them now, I don't know if they are all still relevant. > Given that we are starting to support natural language, I propose > dropping "--disable-nls". Up to you, but be warned it will either (a) bloat your make.exe up by about 1MB if you don't patch its local copy of config.rpath, or (b) pull in a dependency on (mingw) libintl-8.dll and libiconv-2.dll, if you do patch it. Do we want this, for mingw-make? > The job server is not implemented for > Win32, so the "--disable-job-server" is fine, if not irrelevant. The > "--disable-rpath" option by definition "Disables passing additional > runtime library search paths", do we in fact want to do that? Doesn't matter. PE/COFF executables have no way to encode runtime library search paths, unlike ELF ones, so this flag has no DIRECT effect on mingw. However, as a side effect, I think it causes the config.rpath script to be invoked, which...plays a role in how gettext.m4 locates pre-installed libintl. Or something. > I'm > also trying to determine if "--disable-dependency-tracking" is still > valid, given that as near as I can tell it's only benefit is to speed > up one-time builds. I'm open to suggestions on this one. It has no effect on the eventual code that is produced. In the Bad Old Days, it was necessary because dep tracking + win32 paths didn't play nicely together, but that's long been fixed. -- Chuck |
From: Chris S. <ir0...@gm...> - 2010-12-07 18:50:05
|
On 7 December 2010 11:50, Charles Wilson wrote: > On 12/7/2010 11:10 AM, Chris Sutcliffe wrote: >> For historical reasons I had kept using these options prior to 3.82, >> but looking at them now, I don't know if they are all still relevant. >> Given that we are starting to support natural language, I propose >> dropping "--disable-nls". > > Up to you, but be warned it will either (a) bloat your make.exe up by > about 1MB if you don't patch its local copy of config.rpath, or (b) pull > in a dependency on (mingw) libintl-8.dll and libiconv-2.dll, if you do > patch it. > > Do we want this, for mingw-make? Sure enough, built with nls enabled: -rwxr-xr-x 1 Chris Administrators 1243136 Dec 7 13:32 mingw32-make.exe and without: -rwxr-xr-x 1 Chris Administrators 195584 Dec 7 13:41 mingw32-make.exe I guess the question is ultimately, do we go with functionality or size. It looks like gcc and company were compiled with nls enabled, so do we remain consistent with it? Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Charles W. <cwi...@us...> - 2010-12-07 20:23:35
|
On 12/7/2010 1:49 PM, Chris Sutcliffe wrote: > On 7 December 2010 11:50, Charles Wilson wrote: >> Up to you, but be warned it will either (a) bloat your make.exe up by >> about 1MB if you don't patch its local copy of config.rpath, or (b) pull >> in a dependency on (mingw) libintl-8.dll and libiconv-2.dll, if you do >> patch it. >> >> Do we want this, for mingw-make? > > Sure enough, built with nls enabled: > > -rwxr-xr-x 1 Chris Administrators 1243136 Dec 7 13:32 mingw32-make.exe > > and without: > > -rwxr-xr-x 1 Chris Administrators 195584 Dec 7 13:41 mingw32-make.exe > > I guess the question is ultimately, do we go with functionality or > size. It looks like gcc and company were compiled with nls enabled, > so do we remain consistent with it? I guess so. Maybe you could package the .mo files in an (optional) -lang package, so the only price paid by those who don't care about NLS is the 1MB bigger exe? (Also, it looks like gcc and company used their internal (static) copy of libintl, so you should probably stick with that pattern too). -- Chuck |
From: Chris S. <ir0...@gm...> - 2010-12-07 20:54:38
|
On 7 December 2010 15:23, Charles Wilson wrote: > On 12/7/2010 1:49 PM, Chris Sutcliffe wrote: >> On 7 December 2010 11:50, Charles Wilson wrote: >>> Up to you, but be warned it will either (a) bloat your make.exe up by >>> about 1MB if you don't patch its local copy of config.rpath, or (b) pull >>> in a dependency on (mingw) libintl-8.dll and libiconv-2.dll, if you do >>> patch it. >>> >>> Do we want this, for mingw-make? >> >> Sure enough, built with nls enabled: >> >> -rwxr-xr-x 1 Chris Administrators 1243136 Dec 7 13:32 mingw32-make.exe >> >> and without: >> >> -rwxr-xr-x 1 Chris Administrators 195584 Dec 7 13:41 mingw32-make.exe >> >> I guess the question is ultimately, do we go with functionality or >> size. It looks like gcc and company were compiled with nls enabled, >> so do we remain consistent with it? > > I guess so. Maybe you could package the .mo files in an (optional) -lang > package, so the only price paid by those who don't care about NLS is the > 1MB bigger exe? Sounds like a reasonable approach. > (Also, it looks like gcc and company used their internal (static) copy > of libintl, so you should probably stick with that pattern too). That is the way I current have mingw32-make compiled (for nls). Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |