Aaron W. LaFramboise wrote:
> I would like the project administrators to be involved in this
> discussion. We need to reach a consensus on a philosophical and policy
> The most important issue here is about what MinGW should be, going forward:
> a) remain minimal, with only a small set of packages for the toolchain
> and make
> b) expand to include many general-purpose packages and a system of
> prerequisites, in a similar manner to what Cygwin does.
> Note that I am not talking about MSYS here. MSYS is separate and its
> use is optional, and I think we would like it to remain that way.
Agreed. But we also should not deliberately create conflicts between
the "MinGW" parts and the "MSys" parts (e.g. the libiconv-* packages:
"you get the DLL from the MinGW side of the fence, but you need to
replace it with the one from the MSys side if you're going to use the
autotool chain, because the MSYS-host/mingw-target-libiconv maintainer
and the gcc-libiconv maintainer use slightly different compilation
settings when building the DLL...blah blah blah..." That way lies madness.
[separate DLL packages]
> OK, but I will also need some broad consensus from others on mingw-dvlpr
> that this is the right thing to do. That is, that is, that getting an
> installation with all of the languages should require downloading 17
> packages, not including binutils or libraries.
Agreed. I'm not in charge. I'm just expressing my opinion.
>> But...if we provide ONE separate -- and necessarily required -- dll
>> package, what is the rationale for shortcutting the others?
> The only reason I have is reduction in the number of packages and
> overall confusion of the manual installation process. Look at
> with relatively simple manual install instructions. With all of these
> prerequisites, the procedure will become harder to explain and harder to
I know. We *really* need a flexible automated installer. Sigh.
> Please understand I'm not trying to avoid work. I'm only trying to keep
> this package from being difficult to install, and follow MinGW precedent
> and policy as I understand it.
There's nothing wrong with avoiding (extra, unnecessary) work. And, if
you become overloaded by explicit maintainance needs for a half-dozen
supporting packages, that reduces the time you can spend supporting gcc.
So there's nothing wrong with "Aaron does bare minimum now; someone else
can elaborate as needed/desired later". We just need to plan ahead.
>> Better to get all of the
>> surprises out of the way up front.
> I agree. Whatever arrangement we're going to come up with, I think it
> is best we decide on it now, at least as a matter of philosophy and policy.
>> Note #1: if we want to have gcc-core be a monolithic download with no
>> other requirements, then we should have all gcc executables link
>> statically against their dependencies. The advantage of linking
>> dynamically to those dependencies is it allows independent updates
>> without relinking
> It will be a very rare case that a bug in a GCC prerequisite will also
> cause a bug in the bundled version of GCC.
Yeah, but it also allows to offload maintainance needs from the gcc
maintainer to some other volunteer. (e.g. David Billinghurst maintains
gmp, mpfr. mpc, and PPL for cygwin, I maintain libiconv and gettext, cgf
maintains binutils, leaving Dave Korn free to focus (mostly) on gcc
itself. I think gcc alone is plenty for one human.)
E.g. do you really want to be "the guy" that answers questions about why
iconv.exe "doesn't work right in mingw", just because you (may) supply
it as a "side effect" of libiconv?
Static (especially static build-in-src/-tree) doesn't give that kind of
flexibility to offload.
>> Note #2: Why did you need to roll your own libiconv DLL? Was there
>> something wrong with the existing
> As you mentioned elsewhere in your email, these are part of MSYS, which
> requires that MSYS is installed and being used to run GCC for GCC to work.
Uhm, no. These are the one that depend on MSYS:
The ones I mentioned before are plain, native, mingw ports (well, not
"MinGWPorts" exactly). They were *built* from within an MSYS environment
-- but that's no different than building from a cygwin- or linux- hosted
cross environment, as you did when building your version.
> One of these very few opinions that I have on any of this packaging
> stuff is that the MinGW tool chain should not depend on MSYS.
>> HOWEVER: I still have a question about the appropriate path for
>> pre-compiled "native" (e.g. not MSYS) packages.
> Exactly. We've always had all native MinGW packages (non-MSYS) based in
> /mingw, with no dependencies outside of /mingw, and I think we should
> have a very good reason to change this.
Right. That's not at issue.
I'm only talking about mingw ports (not "MinGWPorts" necessarily) -- but
native, win32, no-MSYS-required builds of various libraries. Naturally,
just the barest minimum (in keeping with the minimal nature of the whole
beast) of libraries needed for runtime support of gcc itself. Now,
libiconv and gettext are a little odd: on the one hand, they (their
DLLs, that is) are needed *at runtime* by the gcc executables themselves
[*]. That means these mingw-native DLLs are on the "MinGW" distribution
side of the fence. On the other hand, they (their utilities, import
libs, static libs, header files, data files, and m4/ stuff) are also
part of an MSYS-hosted, mingw-native-target autotool development
environment. That makes them (the native, win32 versions) also part of
the "MSYS" distribution.
[*] well, not gettext/libintl.dll exactly. You're building gcc with no
i18n support, so you don't actually need libintl.dll. But in the
future, theoretically we could do so.
(I'm ignoring the versions of libiconv/gettext compiled explicitly to
link against MSYS itself; those are part of the "MSYS-dvlpr"
environment. Their tarballs will include "MSYS-1.0.11" in the name, and
are not under discussion here).
So, the native, win32, mingw-only, no-msys-in-sight version of the
libiconv DLL...is needed by both "regular" msys-less gcc by itself, but
also by an msys-hosted mingw-target development environment elaborated
with the associated utilities, import libraries, static libs, headers,
etc. Those two uses should be complementary, not conflicting.
>> So, I lean towards repackaging
>> to install into /mingw (and use the new naming scheme, and updating to
>> latest in each case, including libtool-2.2.x).
> My understanding is that you're proposing moving the autotools from MSYS
> to MinGW.
No, that's not my proposal. The existing autotools are already present
in two flavors: an MSYS-dvlpr flavor:
Those are installed into (msys-path) /usr/[bin|lib|include], and are
linked with msys dll, and are needed only by people working on
msys-linked tools themselves.
We also already have mingw-target versions of the autotools. These are
the ones listed in my previous email. They are part of the MSYS (-host,
mingw-target) environment and I am not proposing to change that.
However, none of those binaries (EXEs or DLLs) link against or need in
any way the msys.dll. All I'm proposing is that these (mingw-native,
win32-only, no-msys-dll-in-sight) tools be *installed* into /mingw by
default -- even if (with exactly one exception) they are not "part of"
the default "MinGW" distribution. They are part of the MSYS supplement.
The exception is the (currently not present) package:
which would show up -- with exactly the same name and build ID -- in the
sourceforge download area under BOTH "MSYS Supplementary Tools" and
"MinGW". Because that DLL -- alone -- is truly a member of both
categories: it's part of the msys-hosted mingw-target autotool chain,
but is also a prerequisite of the MinGW gcc binaries.
The same *might* be true also of gettext (that is, libintl.dll), IF you
choose at some point to build gcc with i18n turned on.
I *ALSO* think it's possible that the libiconv and gettext packages
targeted for mingw should be built with Bruno Haible's "relocation"
support turned on, but that's another issue, and one that will require
more thought than I've yet put into it.
> A problem here is that these packages are dependent on MSYS,
> since they require a Bourne shell.
Yes, the *utilities* do. But you wouldn't install *those* as part of
"MinGW" anyway. You'd only install *the utilities* as part of an MSYS
supplemental installation. It's just that those scripts (and exe's,
which are after all native, non-msys-dependent binaries) would go in
/mingw/bin. However, the DLLs and EXEs (like gettext.exe or iconv.exe)
are just plain old win32 ports; nothing about them requires msys dll.
So, suppose somebody is USING mingw + msys to build -- oh, I dunno, say
i18n-enabled ogg encoder tools -- that links against libintl and
libiconv. Now, since these are already provided (with implibs) as part
of the msys-supplement as a side effect of the msys-host/mingw-target
autotool chain, AND since the DLL "lives" in /mingw/bin because gcc.exe
needs it -- it sure would be nice if the rest of those import libs and
headers "lived" under /mingw/[lib|include] so that the user doesn't need
to use -L/-I for MinGW "system" [**] libraries like that. It'd also be
weird to have the DLL in /mingw/bin, but the related files NOT in
/mingw/bin/../[lib|include] because then the .la files would need
futzing. It's be even weirder to provide TWO official versions of
libiconv.dll -- one in /mingw/bin/ and another in /somewhere/bin with
associated files in /somewhere/[lib|include].
[**] They are MinGW "system" libraries because the *MinGW* system (that
is, gcc.exe) needs and provides them.
I guess I'm thinking of "MSYS Supplement" and "MinGW" as two different
metapackages of an overarching set of "stuff we provide" -- so *where*
individual components get installed on the user's hard drive is not
necessarily a discriminator between the "MinGW" metapackage and the
"MSYS Supplement" metapacakge. Some "MSYS Supplement" stuff goes in
C:/msys/1.0/*, and some goes into C:/MinGW. Yes, that means that the
*msys* installer needs to allow the end-user to select (or autodetect)
two different installation paths. One for the "MinGW" stuff (and the
"MSYS Supplement" stuff that is not directly msys-related), and one for
the real MSYS-required stuff like perl.exe, sh.exe, etc.