[Bug target/40722] [4.5 Regression] ia32intrin.h defines of _rotl, _rotr conflict with target stdlib.h decls

[jon_y at users dot sourceforge dot net]

--- Comment #10 from jon_y at users dot sourceforge dot net  2010-03-28 
10:14 ---
Created an attachment (id=20228)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20228action=view)
Broken stdlib.h

Hi,

This patched caused problems for mingw-w64 stdlib.h, see attachment.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40722

[Bug target/40722] [4.5 Regression] ia32intrin.h defines of _rotl, _rotr conflict with target stdlib.h decls

[jon_y at users dot sourceforge dot net]

--- Comment #11 from jon_y at users dot sourceforge dot net  2010-03-28 
10:17 ---
Created an attachment (id=20229)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20229action=view)
log from buildbot

Here is the error output from one of the buildbot slaves.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40722

[Bug target/39947] Shared libgcc getting clobbered for multilib builds

[jon_y at users dot sourceforge dot net]

--- Comment #5 from jon_y at users dot sourceforge dot net  2010-01-24 
07:59 ---
Ping,

We need to get this fixed ASAP. Probably involving the libtool devs as well. I
propose the following naming scheme.

libw64stdc++-6.dll (64bit mingw-w64)
libw32stdc++-6.dll (32bit mingw-w64)
libstdc++-6.dll (mingw.org)

libtool can check -dumpmachine for the vendor key.

Comments?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39947

[Bug ada/40926] Ada errors in trunk

[jon_y at users dot sourceforge dot net]

--- Comment #1 from jon_y at users dot sourceforge dot net  2009-08-01 
00:03 ---
For the Ignore_Output procedure, we can use Pragma Unreferenced (S); to fix
the problem, I'm not too sure about the others.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40926

[Bug target/39947] Shared libgcc getting clobbered for multilib builds

[jon_y at users dot sourceforge dot net]

--- Comment #4 from jon_y at users dot sourceforge dot net  2009-04-29 
08:37 ---
(In reply to comment #3)
 (In reply to comment #2)
  The same problem will occur for all dll's (libstdc++-x,dll, 
  libgfortran-x.dll,
  libssp-x.dll, etc) that are built as part of gcc 
  Danny
 
 That's correct. We have to find a way to install those binaries for multilib
 builds into different locations, or we have to extend the DLL names by a 
 target
 key.
 I would prefer here to use a different location, why not using in /bin target
 specific directories? Something like bin/dll32 and bin/dll64?
 
 Cheers,
 Kai
 

I would prefer a new naming scheme, that way, we don't need to change PATH (by
much) for the system to pick up the dlls.

btw, my libssp seems oddly placed.
prefix/lib/gcc/x86_64-w64-mingw32/bin/libssp-0.dll (64bit)
prefix/lib/gcc/x86_64-w64-mingw32/4.5.0/bin/libssp-0.dll (32bit)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39947