DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type; q=dns; s=default; b=aFkzEO
	q6c0rmopIjbRTbEr1rlCJXFrUH3GJEWZtJOJOZgyycxySRA0O/VeVnePNtQVKb2/
	Bm3PpE7EcOAsxIrV/EdZMPFpRiocLOuwSeO+VpHs+sWGlOyY+fSxXedqDuyLq4HJ
	/k8z/RPzu0LlyXvr20c4cuOFN33vYkZmgxLAo=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <51F8FDBC.3050704@gmail.com>
Date: Wed, 31 Jul 2013 20:06:20 +0800
From: JonY <10walls AT gmail DOT com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: [BUG ?] Failed to rebuild Cygwin
References: <003401ce8dcb$a630b310$f2921930$%fedin AT samsung DOT com> <20130731095949 DOT GV4166 AT calimero DOT vinschen DOT de> <51F8E342 DOT 5020509 AT gmail DOT com> <20130731102826 DOT GX4166 AT calimero DOT vinschen DOT de> <20130731104701 DOT GY4166 AT calimero DOT vinschen DOT de> <51F8F597 DOT 7040109 AT gmail DOT com> <20130731114954 DOT GZ4166 AT calimero DOT vinschen DOT de>
In-Reply-To: <20130731114954.GZ4166@calimero.vinschen.de>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2FDKAOKESGJOJOHGDPWDL"

------enig2FDKAOKESGJOJOHGDPWDL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 7/31/2013 19:49, Corinna Vinschen wrote:
> On Jul 31 19:31, JonY wrote:
>> On 7/31/2013 18:47, Corinna Vinschen wrote:
>>> Erm... hang on.  On second thought, I'm not sure that this is a bug.
>>> The actual bug here was clearly in the Cygwin utils Makefile.
>>>
>>> In fact, since w32api should only be used by Cygwin executables, why
>>> should w32api provide libmingwex.a at all?  Linking a Cygwin executable
>>> against libmingwex doesn't sound like the right thing to do.  Shouldn't
>>> rather libmingwex.a just go from w32api?
>>>
>=20
> I just realize that libmingw*.a is not packed with w32api-runtime
> anyway, so my question doesn't make sense.
>=20
>> Can you see what happens if libmingwex.a was replaced by the empty libm.=
a?
>=20
> I don't understand what you mean.  Can you rephrase the question?
>=20

Sorry, I was confused, I now see user was using the cross compiler, not
native gcc.

>> It is only _get_output_format require stuff from msvcrt,
>> _set_invalid_parameter_handler just uses some typedef declaration.
>>
>> I'm starting to wonder if this require a deeper fix.
>=20
> Not sure, but the problem here was clearly that the crt2.o from
> mingw-crt didn't match with what is provided by w32api-runtime.
> However, there's no point linking against mingw-crt crt2.o but then use
> the libs from w32api, so this isn't really a problem in w32api-runtime.
>=20
> So, bottom line is, I'm not sure there's anything to fix in
> w32api-runtime at all.
>=20

Nope, not related after all. I'm still trying to figure out the error.


------enig2FDKAOKESGJOJOHGDPWDL
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (MingW32)

iQIcBAEBAgAGBQJR+P3EAAoJEHE7X+KcFF1FzW4QAJIotLCZ0B7a9R/b6hYG3qZl
R2+7Nke5o6Hr1zlO6kwr8nIZ5zcGk9w3BW6dbfln1qx04xCJNZhXIp7Lzvvd3HiW
d64vzpcQb8BSPLHuVaNOmZyFJa7t+b3Mbj7J0qMIC8UbOfDZfbGdWUNPSQA2ZIiS
qU9GTJ/DaRXraBUO3PuwIhxE8y57wuUSWf2mnXCe4Cpbf0swyXrrVJObZV+bNT0h
2CWjTDNeYEwv8ZA4K4PBA+a6fdxf55dLZ+y6DDVGVPxbIHehNV94J0CP5BAITtFP
ePvLPgkorwU7aUigZvNUUd/bX4QPkMEL6h2I+4hsaCLGgg2Os63Vx2VZMQh/XPm/
EYkKVuoPNDoM1NOwl10lmu/R45d541RIDgzelhCSTBN3RWQN4O1BqFTBAWTBkzcm
apnLk6m0wj5O3w3OBov9YbIEyOoyty9YpOQ2EVKUND2AKP87tYNNl2e+UOV9CKap
EvNSvS7QC5pXEwCDCGFLHbjt1V0zGA1y8jtheQCHWrrenhmqHkSsIZTxXF/WZWaF
wvM8qZvLALHA1w3TuUUbUbwqcW8f/yXFBjFz0gwRWevvvLNPs+f1Iju+3reYcZx7
+UGorLsHV0IlQtHC7UBCplm1DV3Qj4/TsERdIJYKws5PHsAv5c3qFGnj3l9pzSJ5
d/yNJv+JTQ4XTZh9g3Qn
=YUsA
-----END PGP SIGNATURE-----

------enig2FDKAOKESGJOJOHGDPWDL--