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:
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. Workaround
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 structures
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
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
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
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 map that uses bits/stl_map.h
and there is list too
but there isn't slist and multimap, though the stl_* version is
there to be used.
Is this normal/expected?
Yes,
Robert Collins wrote:
but there isn't slist and multimap, 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
I don't understand completely the logic behind STL headers...
e.g. there is map that uses bits/stl_map.h
and there is list too
but there isn't slist and multimap, though the stl_* version is
there to be used.
Is this normal/expected?
--
Lapo 'Raist' Luchini
[EMAIL PROTECTED] (PGP X.509 keys
10 matches
Mail list logo
