Cesar Strauss wrote:
> I released a new toolchain for MSYS based on GCC 3.4.4.
Great! Thank you very much for pursuing this. I hope we can soon have a
DLL versions of libiconv and libintl, and then coreutils (and everything
else) will have a much smaller on-disk footprint!
This won't help the download size much, as I've mentioned before,
because the repeated inclusion of static libintl code in every .exe
actually compresses quite well; hence eliminating it won't shrink the
.tar.lzma by very much. But we won't need /bin/true.exe to be 1MB
> It is formed by the combination of the following packages:
Q: what source code did you 'start' with? Stock gcc-3.4.4 from fsf, or
the cygwin-special source code? (I really hope it was the latter).
I guess you're trying to indicate that the existing w32api-3.14 package
for mingw should be unpacked under the C:\msys\1.0 directory, so that
the msys-gcc compiler can find it?
In that case, I really think you should just re-package it as
w32api-3.14-msys-1.0.12-dev.tar.lzma, even if the contents are the same
[*]. Our installation "procedure" is already convoluted enough; about
the only rule we have is that -msys- packages get unpacked under
C:\msys\1.0 and -mingw32- packages get unpacked under C:\MinGW. I
really don't want to see a list of exceptions -- "except w32api which
gets unpacked twice, once in each location".
OTOH, if you're saying that the new msys-gcc compiler will actually look
in /mingw/include for headers by default...oh please no. That's just
ASKING for trouble.
[*] Actually, I don't think the contents SHOULD be the same. I think
that msys should instead follow the cygwin lead, and put the w32api
headers into [/usr]/include/w32api and the libs in [/usr]/lib/w32api.
The specs file already includes those paths by default [**], and the
separation helps msys remain more similar to cygwin (which I believe is
a good thing).
[**] on cygwin, and I assume you didn't change this for msys
> These form a self-contained toolchain, so there is no need to install
> msysDVLPR-1.0.0-alpha-1.tar.gz first.
> As a test-drive, I updated the MSYS xz package. I used the same source
> and patch from the latest MinGW xz package, plus the MSYS-specific patch
> of the previous MSYS version. But, with the new toolchain, all the
> changes relating to C89 compatibility were no longer needed and thus
> removed from the patch. There were no regressions in the test suite (all
> passed) and, in fact, I used the updated lzma tool to compress all the
> new packages.
That's very good news.
However...I wish you had /not/ uploaded the new xz package. I'm
concerned about ABI breakage between (msys)gcc-2.95.3 and
(msys)gcc-3.4.4. Does msys-bsdtar still work on your system, as it is
dynamically linked to msys-lzma-1.dll by way of msys-archive-2.dll?
I *know* there were ABI breakages in C++ between 2.95.3 and 3.x (one at
3.0, and at 3.1, then another at 3.2, and then another at 3.4). I'm not
sure whether there was an ABI breakage in C during that time frame [*].
[*] I don't think there were any "all-platform" ABI breaks in C during
this time frame, but there were a number of platform-specific ones
(sparc, mips). For instance, 3.4.0 broke -mms-bitfields on i386-cygming
but it was fixed in 3.4.1. Also, AFAIK the cygwin gcc-3.4.x source code
was *heavily* modified from the stock version, and if you used that --
and I suspect you did; the stock gcc-3.4.x code was almost
non-functional on cygwin -- then THOSE changes have a potential of
breaking the ABI with respect to 2.95.3. (Esp: the
exceptions-across-dll-boundaries cygming-specific patch, which made its
debut sometime in the gcc-3.2.x timeframe, actually changed the *C* ABI
IIRC, by expanding a structure defined in libgcc.a)
In short, my plan once "someone" released an updated msys-gcc compiler,
was to rebuild using that compiler *ALL* of the (non-core) msys packages
which provide libraries. I would do this in a specific order to avoid
dependency on DLLs compiled using gcc-2.95.3, and then upload them ALL
Now, that's a lot of work, so I don't want to do it twice. Hence, my
concern that this new gcc won't build a working msys:
> At this time, one still need msysDVLPR to build the MSYS DLL. Even so, a
> gcc-2.95 toolchain can still be updated with the new binutils and
> msysCORE-dev packages.
Hmm. I wonder why that is -- and if it's worth pursuing. We can either
a) do a bunch of archeology from the cygwin kernel source code circa
2002 to determine what THEY needed to change in order to build with
gcc-3.x, and re-implement them, or
b) determine whether the problem is actually in the compiler, and fix it
c) begin work on msys-2.0 by starting over with cygwin-1.7.x as a
baseline. This is a lot of work. A LOT of work.
If you're pretty confident that the problem is NOT (b), then I'll get
started on my massive rebuild project...
> In related news, I split the msysCORE package into -bin, -dev and -dbg.
Glad to see this. Did you do this manually, or did you update your
msysdvlpr script to do it automatically?
> Since I had made some fixes for the MSYS DLL already, I choose to
> release the reorganized package as 1.0.12, instead of simply
> incrementing the build number.