X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-1.0 required=5.0 tests=AWL,BAYES_50,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_LOW,TW_CG,TW_KG,TW_YG
X-Spam-Check-By:	sourceware.org
Message-ID:	<4C340111.4010308@cwilson.fastmail.fm>
Date:	Wed, 07 Jul 2010 00:22:41 -0400
From:	Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version:	1.0
To:	Cygwin Mailing List <cygwin AT cygwin DOT com>
Subject:	Re: gcc4: next release
References:	<4C33DCA8 DOT 2030708 AT users DOT sourceforge DOT net> <20100707020740 DOT GA4906 AT ednor DOT casa DOT cgf DOT cx> <1278470126 DOT 4032 DOT 57 DOT camel AT YAAKOV04>
In-Reply-To:	<1278470126.4032.57.camel@YAAKOV04>
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

On 7/6/2010 10:35 PM, Yaakov (Cygwin/X) wrote:
> On Tue, 2010-07-06 at 22:07 -0400, Christopher Faylor wrote:
>> I'd want to check with Corinna on this but I am mildly opposed to putting
>> this in /opt.  I don't think it makes sense there.  But I haven't been
>> following closely, though.  Where does Debian put these packages?

AFAICT, debian (like fedora) put them in /usr.  However, neither debian
nor fedora gcc-mingw32 packages include any documentation (like info
files or man pages) -- presumably because such docu might collide with
those provided by the system gcc.  (Well, fedora appears to include the
man pages, but they get renamed as $target-foo.1; debian doesn't provide
any)

Furthermore, neither debian nor fedora provide any i18n message
catalogs.  Whether that is because the cross compiler is compiled with
--disable-nls, or it is just assumed that the system compiler and the
mingw32 cross compiler will always and forever be kept in sync, it
doesn't matter: the i18n files just plain aren't present.  (BOTH
"solutions" appear to be the case for fedora).


As a side note, it seems that *fedora* is configuring with
--target=i686-pc-mingw32, which is (effectively) the mingw.org compiler
(minus some custom mingw.org patches, but plus some fedora-specific ones
to keep mingw32-gcc and system gcc coordinated).  It seems that this
implies that "fedora mingw32" is 32bit only; it doesn't support 64bit at
all (--disable-multilib).

OTOH, debian uses has two different target triples for their combo mingw
cross compiler package. It appears to NOT be multilib; simply two
separate cross compilers combined into the same installation package:
one for 'i586-mingw32msvc' and one for 'amd64-mingw32msvc' -- whatever
THAT means.  Obviously some sort of mapping is going on under the hood
-- but whether it maps to the "mingw.org-ish" i586-pc-mingw32 or to the
"mingw64-ish" x86_64-w64-mingw32 I don't know.  Maybe i586-mingw32msvc
maps to i586-pc-mingw32 for a mingw.org cross compiler, and
md64-mingw32msvc maps to x86_64-w64-mingw32 for a mingw64 cross
compiler, and both are simply mushed together...


So, to sum up: it seems that the linuxes avoid the issue in two ways:

1) don't ship documentation that would clash with the system compiler
     http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543393

2) (fedora) compile using --disable-nls, so that locale/* clashing is
   a non-issue, or (debian) or simply remove the clashing files from
   the installation tree, and assume cross compiler will use the i18n
   files from the system gcc:

+	# remove some non-cross stuff that will clash with other packages
+	# and shuffle things about as required.
+	rm -rf debian/$(package)/usr/include
+	rm -rf debian/$(package)/usr/info
+	rm -rf debian/$(package)/usr/share/locale
+	rm debian/$(package)/usr/lib/*a
+	rm -rf debian/$(package)/usr/share/man/man7

Both appear to make some assumptions (explicit, wrt to i18n files in the
case of debian; implicit, with respect to user documentation, for both
fedora and debian) that the system gcc and the mingw cross compiler will
be of exactly the same version. (Otherwise, the poor user will be
horribly confused, if 'info gcc' talks about the system gcc 4.4.1 which
doesn't actually match the mingw-gcc 4.6.0 or whatever.

> I'm working with JonY on this as well.  If DaveK splits out the info and
> l10n into a separate gcc4-common package when he updates to 4.5.x (or
> 4.6 trunk), then JonY can package a similar version for mingw64 and
> depend on that to provide those files.  That, together with one other
> fix, should allow mingw64 to go into /usr.
> 
> The only requirement will be coordinating releases (at least the same
> major.minor) so that l10n will work for mingw64 as well without worrying
> about these collisions.  The alternative is to simply --disable-nls but
> IMO that is less than optimal.

There are two problems with regards to conflicting files, if everything
goes into the same $prefix: i18n data and documentation.  This applies
to gcc.

There are additional problems with regards to cross-binutils
(libiberty.a, libbfd.a, libopcodes.a; are any of the installed bfd
headers "customized" per-target? I dunno.); other than renaming the
cross versions 'mingw64-libiberty.a' or perhaps moving these files to an
official sysroot "tree for cross-compiled stuff", I don't see a clean
way of dealing with this -- although, as I look at JonY's
mingw64-binutils package, I don't see these libraries at all!).

There are three solutions (for gcc, if not binutils):

1) Keep the mingw64, mingw.org, and cygwin compilers always at the same
version. Split the conflicting files into a separate subpackage,
provided by (e.g) the cygwin 'version', so that they can be installed
independently of any of the actual compilers themselves.  This is
Yaakov's suggestion.

Advantages: more 'cygwinish': all apps in /usr/bin. Simpler. cygport
happier.

Disadvantages: we still need a nice place to keep 64bit and 32bit DLLs
that may have the same name separate, OTHER than buried deep inside the
/usr/lib/gcc/$target/ hierarchy (setting $PATH to something that ugly?
ick! As an possible amelioration, maybe we could come up with an
official sysroot for any built-with-mingw64 like Fedora does (see HERE!):


/usr
  |
<snip>
  +- sys-root  - root for cross compiled binaries
      |
      +- mingw  <<<<< HERE!!!
          |
          +- bin     - cross-compiled binaries & runtime DLL parts
          +- doc     - documentation
          +- include - include files for cross compiled libs
          +- lib     - cross-compiled static libraries & linktime DLL parts
          |   |
          |   +- pkgconfig  - pkg-config definitions for libraries
          |
          +- share
              |
              +- man

where instead of "mingw" at HERE, we have:

   mingw64    -- 64bit (obviously built using mingw64-gcc -m64)
   mingw64-32 -- 64bit (built using mingw64-gcc -m32; thus, uses the
                        mingw64-supplied runtime and w32api stuff)
   mingw32    -- 32bit (built using mingw.org gcc)

The current mingw-zlib, etc etc stuff, could be rebuilt/repackaged to
live in the new sysroot.

And, to prime the pump, the compiler runtime DLLs could be moved into
sysroot/mingw*/bin -- this is the approach that the Fedora rpm spec
files take for mingw32-gcc.

Other disadvantages: shackling cygwin-gcc and mingw64 (and mingw.org)
compiler versions together increases the required coordination between
maintainers, and at worst could result in deadlock for one platform, if
the other, for whatever reason, *can't* upgrade to the desired version.

Also, the whole "mingw-ish gcc's appear to hardcode /mingw into their
search paths" problem: /mingw/lib for -L and /mingw/include for -I.
This means that mingw64 will "find" our current mingw.org-derived mingw
runtime headers and libs, possibly causing conficts with mingw64's
versions, unless the former are moved elsewhere, or additional patches
to mingw64 (and, most likely, mingw.org) gcc would be required.



2) Don't install any documentation files associated with the cross
compiler, or explicitly rename all possibly conflicting files and/or
install docu someplace "special" -- e.g. custom --datarootdir?  Compile
with --disable-nls so that i18n conflicts between different versions are
no longer relevant (or use custom --datarootdir to solve the i18n
conflict issue -- but cygport doesn't like this very much).

Advantages: mingw64 and cygwin (and mingw.org) versions need not be
related to each other.  More 'cygwin-ish': all apps in /usr/bin.

Disadvantages: no i18n for cross compilers. no documentation (or,
documentation is hard to find) specific to whatever version of cross
compiler is installed. And the whole "mingw-ish gcc's hardcode /mingw
into their search paths" problem, described above.



3) Install cross compilers into custom tree, over in /opt/

Advantages: most flexible, allows i18n and docu without conflict with
other cross compilers or system (cygwin) gcc.  Versions of the various
compilers are not tied together, so minimum coordination needed between
maintainers of the various compilers.

Disadvantages: Can't execute the tools in /opt/mingw64/bin unless
/usr/bin is in $PATH.  Not a problem for running within cygwin shells,
but launching from w32 IDEs may require setting system $PATH first.
More complicated -- and possibly confusing -- installation.  Difficult
to fit into the cygport pkgbuild system.  cgf doesn't like it.


Note that the "official sysroot" idea can be used with any of these
three options -- and might be a good thing to establish, on its own merits:

   /usr/sysroot/mingw32/*
   /usr/sysroot/mingw64/*
   /usr/sysroot/mingw64-32/*

I hope I have summed up the various competing proposals fairly, and that
this edition of my patented War and Peace emails helps move the
discussion along to a conclusion.

--
Chuck

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -