https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59974
jon_y <10walls at gmail dot com> changed:
What|Removed |Added
CC| |10walls at gma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
jon_y <10walls at gmail dot com> changed:
What|Removed |Added
CC| |10walls at gma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108675
--- Comment #3 from jon_y <10walls at gmail dot com> ---
I'm fine with something like __HIDE_PRINTF_PROTOTYPES to prevent them from
being exposed, though there may be places that needs to be fixed up from
assuming the prototypes exist.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #20 from jon_y <10walls at gmail dot com> ---
No, Cygwin does not use fat objects/archives. As far as I know, Cygwin never
shipped multilib capable gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108192
jon_y <10walls at gmail dot com> changed:
What|Removed |Added
CC| |10walls at gma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108150
--- Comment #3 from jon_y <10walls at gmail dot com> ---
Created attachment 54211
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54211=edit
Fix attempt 1
Makes errors emitted same as on Linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100383
jon_y <10walls at gmail dot com> changed:
What|Removed |Added
CC| |10walls at gma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82028
--- Comment #4 from jon_y <10walls at gmail dot com> ---
I can't seem to change the bug status to confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94570
jon_y <10walls at gmail dot com> changed:
What|Removed |Added
Attachment #48281|0 |1
is ob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94570
--- Comment #9 from jon_y <10walls at gmail dot com> ---
if defined(__MSDOS__) || (defined(_WIN32) && ! defined(__CYGWIN__) ||
defined(__OS2__)
I've tested the above and confirmed that coverage.ii does have the correct
separator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94570
--- Comment #8 from jon_y <10walls at gmail dot com> ---
I forgot to mention that while Cygwin runs on Windows, applications should
always use UNIX style paths.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94570
--- Comment #7 from jon_y <10walls at gmail dot com> ---
Created attachment 48281
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48281=edit
Alternate patch
I'm not sure if ltmain.sh is shared in the cygnus tree, but this patch sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568
--- Comment #27 from jon_y <10walls at gmail dot com> ---
Thanks Jakub.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568
--- Comment #22 from jon_y <10walls at gmail dot com> ---
Bootstrapped sucessfully on x86_64-pc-cygwin, test compiles and has the data
member dllimported. Patch looks good.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568
--- Comment #16 from jon_y <10walls at gmail dot com> ---
I'll try testing over the weekends.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89534
--- Comment #3 from jon_y <10walls at gmail dot com> ---
My experience with weak symbols on mingw is that it will lead to an undefined
symbol error if it was the only symbol definition.
It only works if the weak symbol was encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89534
--- Comment #1 from jon_y <10walls at gmail dot com> ---
Weak symbols aren't quite supported with PE, I'm not sure if making the symbol
weak is the right approach.
Do you have a test case to show this will lead to the correct be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568
--- Comment #8 from jon_y <10walls at gmail dot com> ---
I've used a linux hosted mingw toolchain to build a mingw toolchain from the
same sources, it seems to be working fine.
I've only enabled C and C++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568
jon_y <10walls at gmail dot com> changed:
What|Removed |Added
CC| |10walls at gma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86856
--- Comment #13 from jon_y <10walls at gmail dot com> ---
Looks good from my end, thanks for the fixes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86856
--- Comment #12 from jon_y <10walls at gmail dot com> ---
I've just tested the trunk version as a Linux native build, I don't see the
warnings.
I will proceed to do a mingw cross compiler soon with the trunk version.
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: 10walls at gmail dot com
GCC target triplet: *-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39947
--- Comment #1 from 10walls at gmail dot com 2009-04-28 15:39 ---
Hi,
some more info on the configured gcc:
built with:
../gcc-trunk/configure --host=i686-pc-mingw32 --build=i686-pc-mingw32
--target=x86_64-w64-mingw32 --enable-multilib --enable-64bit
--prefix=/mingw/w64_64
23 matches
Mail list logo
