Size of coreutils binaries

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Size of coreutils binaries

leledumbo
I added coreutils to my msys installation because I need some tools not available in the installer. However, the size of each binary is at least 1 MB. Why is it so? I don't think a program as simple as pwd could have such size.
Reply | Threaded
Open this post in threaded view
|

Re: Size of coreutils binaries

Charles Wilson-8
leledumbo wrote:
> I added coreutils to my msys installation because I need some tools not
> available in the installer. However, the size of each binary is at least 1
> MB. Why is it so? I don't think a program as simple as pwd could have such
> size.

It's because coreutils are now built with i18n support, to support our
non-english-speaking users. Normally, i18n support would be provided by
the libintl DLL -- but on MSYS, because we're still stuck using
gcc-2.95.3, libintl can only be built as a static library (the reason
for this limitation is long and involved).

Now, this means that each and every coreutils app must link in the
libintl code statically -- and that's why they are all much bigger than
before.

Eventually, when the MSYS compiler is updated to be 3.x or 4.x, we will
be able to compile libintl as a DLL, and then the coreutils apps will
drop back down to a more reasonable size.

For now, tho, I figure (a) disk space is cheap, (b) supporting
non-english-speaking users is important, and (c) the download tarball is
actually not much bigger than before, because the repeated libintl
static code compresses very well.

BTW, the MSYS Phoenix project is already using a version of gcc-3.4.x to
build msys apps, and they also have an experimental gcc-4.x version (but
it has no C++ support).  AFTER mingw-get is rolled out, and the "new"
modularized MSYS/MinGW distribution has some time to stabilize, I'll
look into grabbing the MSYS Phoenix compiler -- but doing so would
require recompiling and updating ALL of the MSYS packages (not to
mention some significant changes wrt gettext/libintl and libiconv). I'm
definitely not ready to tackle that just yet.

--
Chuck


------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: Size of coreutils binaries

Teemu Nätkinniemi
> BTW, the MSYS Phoenix project is already using a version of
> gcc-3.4.x to
> build msys apps, and they also have an experimental gcc-4.x
> version (but
> it has no C++ support).  AFTER mingw-get is rolled
> out, and the "new"
> modularized MSYS/MinGW distribution has some time to
> stabilize, I'll
> look into grabbing the MSYS Phoenix compiler -- but doing
> so would
> require recompiling and updating ALL of the MSYS packages
> (not to
> mention some significant changes wrt gettext/libintl and
> libiconv). I'm
> definitely not ready to tackle that just yet.

Here's the GCC 3.4.4 for MSYS, with g++ compiled in. No
patch included as I basically replaced all __CYGWIN__ with
__MSYS__ and copied necessary files to gcc/config/i386 from
the original MSYS GCC 2.95.3.

http://www.mediafire.com/?ngnrewkzz2i

GCC 3.2.3 on Phoenix' website works quite nicely as I've managed
to build a working MSYS dll with it.

http://www.cadforte.com/msys.html


     

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: Size of coreutils binaries

Charles Wilson-8
Teemu Nätkinniemi wrote:
>> BTW, the MSYS Phoenix project is already using a version of
>> gcc-3.4.x to

Oops. I meant gcc-3.2.3 here.

>> build msys apps, and they also have an experimental gcc-4.x
>> version

And I meant gcc-3.4.4 here.

>> (but
>> it has no C++ support).  AFTER mingw-get is rolled
>> out, and the "new"
>> modularized MSYS/MinGW distribution has some time to
>> stabilize, I'll
>> look into grabbing the MSYS Phoenix compiler -- but doing
>> so would
>> require recompiling and updating ALL of the MSYS packages
>> (not to
>> mention some significant changes wrt gettext/libintl and
>> libiconv). I'm
>> definitely not ready to tackle that just yet.
>
> Here's the GCC 3.4.4 for MSYS, with g++ compiled in. No
> patch included as I basically replaced all __CYGWIN__ with
> __MSYS__ and copied necessary files to gcc/config/i386 from
> the original MSYS GCC 2.95.3.
>
> http://www.mediafire.com/?ngnrewkzz2i
>
> GCC 3.2.3 on Phoenix' website works quite nicely as I've managed
> to build a working MSYS dll with it.
>
> http://www.cadforte.com/msys.html

I'm a little confused. The MSYS Phoenix website credits you, Teemu, for
the updated gcc "C" builds (presumably both 3.2.3 and 3.4.4), but Jon_y
takes credit for the libstdc++ support -- which, on that page, means
only g++-3.2.3.

But if it was as easy as you say -- just s/__CYGWIN__/__MSYS__/ -- then
(a) why didn't you do that for both of your contributions, originally;
that is, why did Jon_y have to do it for you, for 3.2.3? (b) and while
he was doing that, why didn't he go ahead do the same for g++-3.4.4?

I suspect the answer to these questions is, "There was more to the port
than that".  But -- I can't tell without a lot more investigation
(basically, redo-ing your/Jon_y's porting effort myself).  I don't have
time for that right now (and besides, the MSYS distro is not yet ready
for that wholesale change, either)...

--
Chuck

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: Size of coreutils binaries

JonY-6
On 12/3/2009 15:48, Charles Wilson wrote:

> Teemu Nätkinniemi wrote:
>>> BTW, the MSYS Phoenix project is already using a version of
>>> gcc-3.4.x to
>
> Oops. I meant gcc-3.2.3 here.
>
>>> build msys apps, and they also have an experimental gcc-4.x
>>> version
>
> And I meant gcc-3.4.4 here.
>
>>> (but
>>> it has no C++ support).  AFTER mingw-get is rolled
>>> out, and the "new"
>>> modularized MSYS/MinGW distribution has some time to
>>> stabilize, I'll
>>> look into grabbing the MSYS Phoenix compiler -- but doing
>>> so would
>>> require recompiling and updating ALL of the MSYS packages
>>> (not to
>>> mention some significant changes wrt gettext/libintl and
>>> libiconv). I'm
>>> definitely not ready to tackle that just yet.
>>
>> Here's the GCC 3.4.4 for MSYS, with g++ compiled in. No
>> patch included as I basically replaced all __CYGWIN__ with
>> __MSYS__ and copied necessary files to gcc/config/i386 from
>> the original MSYS GCC 2.95.3.
>>
>> http://www.mediafire.com/?ngnrewkzz2i
>>
>> GCC 3.2.3 on Phoenix' website works quite nicely as I've managed
>> to build a working MSYS dll with it.
>>
>> http://www.cadforte.com/msys.html
>
> I'm a little confused. The MSYS Phoenix website credits you, Teemu, for
> the updated gcc "C" builds (presumably both 3.2.3 and 3.4.4), but Jon_y
> takes credit for the libstdc++ support -- which, on that page, means
> only g++-3.2.3.
>
> But if it was as easy as you say -- just s/__CYGWIN__/__MSYS__/ -- then
> (a) why didn't you do that for both of your contributions, originally;
> that is, why did Jon_y have to do it for you, for 3.2.3? (b) and while
> he was doing that, why didn't he go ahead do the same for g++-3.4.4?
>
> I suspect the answer to these questions is, "There was more to the port
> than that".  But -- I can't tell without a lot more investigation
> (basically, redo-ing your/Jon_y's porting effort myself).  I don't have
> time for that right now (and besides, the MSYS distro is not yet ready
> for that wholesale change, either)...
>

Hi,

I can't remember clearly, but I think I just built the C and C++
frontend ootb from Teemu's tarball, so it was Teemu who did most of the
poking work. I'm not sure why xeno credited me, maybe I forgot why...

Anyway, long story short, I did not have time to maintain an updated
MSYS toolchain, so I've gradually forgotten about it. Sorry, I did not
take any notes while rebuilding the toolchain.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: GCC 3.4.4 for MSYS (was: Size of coreutils binaries)

Cesar Strauss-2
In reply to this post by Teemu Nätkinniemi
Teemu Nätkinniemi wrote:
> Here's the GCC 3.4.4 for MSYS, with g++ compiled in. No
> patch included as I basically replaced all __CYGWIN__ with
> __MSYS__

Yes, I also succeeded to build GCC 3.4.4 for MSYS (C and C++), by using
the Cygwin patches found on the Cygwin source package for GCC 3.4.4. I
also took the chance to update binutils as well.

Lately, I am focusing on creating suitable source packages (original
sources + cygwin patches + msys patches + build script). I plan to offer
them as an optional add-ons to the msysDVLPR environment.

The compiler is able to bootstrap itself, so there is a good chance it
is really fully functional.

> and copied necessary files to gcc/config/i386 from
> the original MSYS GCC 2.95.3.

I didn't do it this way. I just renamed some existing cygwin-named files
on the same directory on GCC 3.4.4.

> GCC 3.2.3 on Phoenix' website works quite nicely as I've managed
> to build a working MSYS dll with it.
>

This, I wasn't able to do. With my self-built GCC 3.4.4, the dll is
built, but existing MSYS applications just exit immediately when run. I
will try your suggestion of using the GCC 3.2.3 on Phoenix site.

Regards,
Cesar


------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: GCC 3.4.4 for MSYS (was: Size of coreutils binaries)

Teemu Nätkinniemi
> > patch included as I basically replaced all __CYGWIN__
> with
> > __MSYS__
>
> Yes, I also succeeded to build GCC 3.4.4 for MSYS (C and
> C++), by using
> the Cygwin patches found on the Cygwin source package for
> GCC 3.4.4. I
> also took the chance to update binutils as well.

I have used the binutils package that's shared on MSYS Phoenix website.
 
> Lately, I am focusing on creating suitable source packages
> (original
> sources + cygwin patches + msys patches + build script). I
> plan to offer
> them as an optional add-ons to the msysDVLPR environment.

That would be nice as on compiler side MSYS has been lacking for a long time. And my builds are at best very experimental.
 
> The compiler is able to bootstrap itself, so there is a
> good chance it
> is really fully functional.

With my builds bootstrapping should work as well.

> > GCC 3.2.3 on Phoenix' website works quite nicely as
> I've managed
> > to build a working MSYS dll with it.
> This, I wasn't able to do. With my self-built GCC 3.4.4,
> the dll is
> built, but existing MSYS applications just exit immediately
> when run. I

I think Cygwin was updated at some point to get it working with GCC 3.4. I haven't been following Cygwin progress closely so I might be wrong.

Teemu


     

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: GCC 3.4.4 for MSYS

Charles Wilson-8
In reply to this post by Cesar Strauss-2
Cesar Strauss wrote:

> Yes, I also succeeded to build GCC 3.4.4 for MSYS (C and C++), by using
> the Cygwin patches found on the Cygwin source package for GCC 3.4.4. I
> also took the chance to update binutils as well.
>
> Lately, I am focusing on creating suitable source packages (original
> sources + cygwin patches + msys patches + build script). I plan to offer
> them as an optional add-ons to the msysDVLPR environment.
>
> The compiler is able to bootstrap itself, so there is a good chance it
> is really fully functional.

Good news!

>> GCC 3.2.3 on Phoenix' website works quite nicely as I've managed
>> to build a working MSYS dll with it.
>
> This, I wasn't able to do. With my self-built GCC 3.4.4, the dll is
> built, but existing MSYS applications just exit immediately when run. I
> will try your suggestion of using the GCC 3.2.3 on Phoenix site.

Actually, this doesn't surprise me.  There was a large ABI change
between gcc 2.95.3 and gcc-3.0, and another between at least one of the
gcc-3.x / gcc-3.x+1 transitions.  Although cygwin/msys has a strictly
C-style ABI, it IS written in C++, and is linked against libgcc.a (EH is
disabled, so none of the EH personality stuff is ever pulled in, when
built with modern g++ -- but I'm not sure that old obsolete gcc was that
smart).

I'm more surprised that Teemu's gcc-3.2-built msys WAS usuable by
gcc-2.95-built client apps, than I am that your gcc-3.4-built msys was
NOT usable.

This is part of what I meant when I said that I believed the whole msys
schmeil would need to be bootstrapped using the new compiler -- a
non-trivial undertaking.  Basically, you build
  msys-gcc (against CURR-MSYS)
  msys-binutils (ditto)
then, build MSYS. Install into /tmp/staging, but go ahead and copy all
the /tmp/staging/include/ and /tmp/staging/lib/ files into /[include|lib]/.

Then, start compiling all your client packages (coreutils, bash, etc) --
always installing into /tmp/staging/, but copying any headers/libs back
to /[include|lib]/

Eventually, /tmp/staging/* will have a complete-enough installation that
 you might be able to test THOSE apps in /tmp/staging/bin/, and the
"new" msys-1.0.dll in /tmp/staging/bin/, by running them directly from a
CMD box (without CURR-MSYS-BASH running!!)

Then, I'd three-card monty my installation directories:

  C:\msys\1.0\tmp\staging C:\msys-new
  C:\msys -> C:\msys-old
  C:\msys-new C:\msys

And THEN, rebuild gcc AGAIN (so this time, it links against MSYS-NEW),
and repeat the whole exercise (but this time, no need to futz with
/tmp/staging/).

Yep, a WHOLE lotta work...

--
Chuck





------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys