[Bug binutils/26298] New: windres: cannot compile BITMAP or OWNERDRAW menu items
https://sourceware.org/bugzilla/show_bug.cgi?id=26298 Bug ID: 26298 Summary: windres: cannot compile BITMAP or OWNERDRAW menu items Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: katayama.hirofumi.mz at gmail dot com Target Milestone: --- Created attachment 12723 --> https://sourceware.org/bugzilla/attachment.cgi?id=12723&action=edit The patch by Nick Clifton https://lists.gnu.org/archive/html/bug-binutils/2020-07/msg00054.html Hi katahiromz, > I'm using your resource compiler "windres". > I found that windres cannot compile BITMAP or OWNERDRAW menu items. Thank you for reporting this. In the future, please could you report any binutils bugs via the bugzilla system here: https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils In the meantime I have checked in the attached patch to fix the problem. Cheers Nick binutils/ChangeLog 2020-07-09 Nick Clifton * rclex.c: Add OWNERDRAW keyword. * rcparse.y: Add OWNERDRAW token. (menuitem_flag) Add BITMAP and OWNERDRAW entries. * rcparse.c: Regenerate. * resrc.c (write_rc_menuitems): Add support for OWNERDRAW and BITMAP flags. * windres.c (extended_menuitems): Likewise. * testsuite/binutils-all/windres/menuitem_flags.rc: New test. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25136] mips64: set abi as N64 when the ABI section triple is gnuabi64
https://sourceware.org/bugzilla/show_bug.cgi?id=25136 Maciej W. Rozycki changed: What|Removed |Added CC||ma...@linux-mips.org --- Comment #4 from Maciej W. Rozycki --- As to making the default ABI/ISA configurable I would recommend reusing the approach we have taken with GCC, that is to provide `--with-abi=', `--with-arch=', `--with-arch-32=' and `--with-arch-64=' configuration options. This way the toolchain will remain consistent and will not depend on the target triplet in a different way across packages, and also we won't have to invent more and more complicated target triplets to handle new cases as they arise. As I recall this design decision has been discussed a few times over the years. Please note that GAS/LD are low-level tools however and in ordinary use cases they are supposed to be driven by GCC, which will set correct flags according to its configuration and any additional options requested. I'm not therefore sure we need to change the semantics in the first place. What is your use case that requires GAS/LD to be invoked directly rather than via GCC? Cf. PR ld/25494. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25494] [MIPS] default output as r6 when default target as r6
https://sourceware.org/bugzilla/show_bug.cgi?id=25494 Maciej W. Rozycki changed: What|Removed |Added CC||ma...@linux-mips.org --- Comment #2 from Maciej W. Rozycki --- For linking in raw binary chunks of data the best approach is to use GAS and its .incbin pseudo-op, e.g.: $ cat xx.s .incbin xx.dat $ mipsisa32r6el-linux-gnu-as -o xx.o xx.s because even if we decide to make the default ABI configurable `ld -r -b binary' won't be able to set all the various ABI flags a given build may require. As to making the default ABI/ISA configurable I would recommend reusing the approach we have taken with GCC, that is to provide `--with-abi=', `--with-arch=', `--with-arch-32=' and `--with-arch-64=' configuration options. This way the toolchain will remain consistent and will not depend on the target triplet in a different way across packages, and also we won't have to invent more and more complicated target triplets to handle new cases as they arise. As I recall this design decision has been discussed a few times over the years. Please note that GAS/LD are low-level tools however and in ordinary use cases they are supposed to be driven by GCC, which will set correct flags according to its configuration and any additional options requested. I'm not therefore sure we need to change the semantics in the first place. What is your use case that requires GAS/LD to be invoked directly rather than via GCC? Cf. PR 25136. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26298] windres: cannot compile BITMAP or OWNERDRAW menu items
https://sourceware.org/bugzilla/show_bug.cgi?id=26298 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Patch applied -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/23499] Incorrect code in bfd_elf_record_link_assignment
https://sourceware.org/bugzilla/show_bug.cgi?id=23499
Samuel Thibault changed:
What|Removed |Added
CC||samuel.thiba...@ens-lyon.or
||g
--- Comment #12 from Samuel Thibault ---
Hello,
It seems we are getting the same kind of issue with the gold linker. For
various reasons llvm-toolchain is linked with gold in Debian, and I stumbled on
this:
/usr/bin/ld: /usr/lib/llvm-9/lib/../lib/libLLVM-9.so.1:(*IND*+0x0): multiple
definition of `_end'
(full log in
https://buildd.debian.org/status/fetch.php?pkg=qttools-opensource-src&arch=hurd-i386&ver=5.14.2-2&stamp=1595261986&raw=0
)
and indeed
$ nm -D /usr/lib/llvm-9/lib/libLLVM-9.so.1 | grep ' _end'
03d0ef69 B _end@@LLVM_9
03d0ef69 B _end@LLVM_9
where _end@LLVM_9 is unwanted.
I reduced the test case to a mere
$ cat test.cpp
int i;
$ cat test.map
LLVM_9 { global: *; };
$ clang++-9 -fuse-ld=gold -shared test.cpp -o libtest.so
-Wl,--version-script,test.map -lz3
Note the -lz3:
$ nm -D /usr/lib/i386-gnu/libz3.so | grep ' _end'
018bb074 B _end
It's the combination of -fuse-ld=gold, the version script, and the fact that we
link against a library that also has its (unversioned) _end symbol, that leads
to this:
$ nm -D libtest.so | grep _end
2010 D _end@@LLVM_9
2010 D _end@LLVM_9
where _end@LLVM_9 is unwanted, and would typically produce the multiple
definition mentioned above.
Samuel
--
You are receiving this mail because:
You are on the CC list for the bug.
Issue 23671 in oss-fuzz: binutils:fuzz_bfd: Undefined-shift in _bfd_vms_slurp_etir
Updates: Labels: -restrict-view-commit Comment #2 on issue 23671 by sheriffbot: binutils:fuzz_bfd: Undefined-shift in _bfd_vms_slurp_etir https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23671#c2 This bug has been fixed for 30 days. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
