--- Additional Comments From schwab at linux-m68k dot org 2010-06-16 14:24
---
http://sourceware.org/git/?p=glibc-
ports.git;a=commit;h=08b1b36387286ed1ba48c56a32e52429b5ef6963
--
What|Removed |Added
Hi Anthony,
If you specify res as an include directory via the -I
or --include-dir= options, windres mistakenly assumes
this to be the output format (and issues a warning saying
to use -J instead). The workaround if you have such an
input directory named res is to specify it as ./res,
though
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2010-06-16
15:13 ---
Subject: Bug 11676
CVSROOT:/cvs/src
Module name:src
Changes by: ni...@sourceware.org2010-06-16 15:12:51
Modified files:
opcodes: ChangeLog m68k-dis.c
--- Additional Comments From nickc at redhat dot com 2010-06-16 16:18
---
Hi Vincent,
I am unable to reproduce this problem. Please could you provide a small test
case that demonstrates it ? (Note - I did run the ld-srec tests but although
the tests failed to link there were no
--
What|Removed |Added
Status|NEW |WAITING
http://sourceware.org/bugzilla/show_bug.cgi?id=11675
--- You are receiving this mail because:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2010-06-16
16:28 ---
Subject: Bug 11673
CVSROOT:/cvs/src
Module name:src
Changes by: ni...@sourceware.org2010-06-16 16:27:38
Modified files:
opcodes: ChangeLog m68k-opc.c
When specifying include directories for windres via the -I or --include-dir=
options that also happen to match input formats (i.e. a directory named res),
windres assumes they are the latter and outputs a warning. This obscure
backwards-compatibility reference causes confusion and is only briefly
Okay Nick, I've gone ahead and reported it here:
http://sourceware.org/bugzilla/show_bug.cgi?id=11711
(added you to the CC list - I hope you don't mind.)
I note there that if backwards-compatibility is necessary, then at least
--include-dir=res can behave as expected. I agree, it's barely