On Jul 30 06:37, JonY wrote:
> Hi,
>
> After removing 4.8-cmodel-medium.patch and 4.8-duplicate-symbols.patch
> for 32bit cygwin, 2nd stage libgcc fails with spawn error, "C compiler
> cannot create executables".
I thought the 4.8-cmodel-medium.patch only affects the x86_64 target.
> Running the
Hi,
After removing 4.8-cmodel-medium.patch and 4.8-duplicate-symbols.patch
for 32bit cygwin, 2nd stage libgcc fails with spawn error, "C compiler
cannot create executables".
Running the compile command manually does show it running cc1, but hangs
indefinitely, adding -v causes it to emit xgcc: er
On 7/26/2013 17:45, JonY wrote:
> On 7/26/2013 13:02, Yaakov (Cygwin/X) wrote:
>> On 2013-07-12 05:33, JonY wrote:
>>> For gcc-4.7.x, struct alignment behavior has changed, -mms-bitfields is
>>> now default, for better MSVC compatibility. This may cause ABI changes
>>> in libraries that expose data
On 7/26/2013 13:02, Yaakov (Cygwin/X) wrote:
> On 2013-07-12 05:33, JonY wrote:
>> For gcc-4.7.x, struct alignment behavior has changed, -mms-bitfields is
>> now default, for better MSVC compatibility. This may cause ABI changes
>> in libraries that expose data structures directly to clients. Worka
On 2013-07-12 05:33, JonY wrote:
For gcc-4.7.x, struct alignment behavior has changed, -mms-bitfields is
now default, for better MSVC compatibility. This may cause ABI changes
in libraries that expose data structures directly to clients. Workaround
include marking the struct with the gcc_struct a
This update includes:
Update:
mingw64-*-headers-3.0b_svn5935-1
mingw64-*-runtime-3.0b_svn5935-1
mingw64-*-gcc-4.7.3-1
mingw64-*-pthreads-20100619-5
New:
mingw64-*-winpthreads-3.0b_svn5935-1
*** NOTES ***
For gcc-4.7.x, struct alignment behavior has changed, -mms-bitfields is
now default, for be
Robert Collins wrote:
but there isn't and , though the "stl_*" version is
there to be used.
Is this normal/expected?
Yes, have a look at www.sgi.com/tech/stl
Ohh, they're still-not-standard extensions... so either I use them with
bits/stl_multimap.h header or I don't use them at all,
On Sat, 2002-11-16 at 07:49, Lapo Luchini wrote:
> I don't understand completely the logic behind STL headers...
> e.g. there is that uses
> and there is too
> but there isn't and , though the "stl_*" version is
> there to be used.
>
> Is this normal/expected?
Yes, have a look at www.sgi.com
I don't understand completely the logic behind STL headers...
e.g. there is that uses
and there is too
but there isn't and , though the "stl_*" version is
there to be used.
Is this normal/expected?
--
Lapo 'Raist' Luchini
[EMAIL PROTECTED] (PGP & X.509 keys available)
http://www.lapo.it (ICQ
9 matches
Mail list logo
