[Bug admin/27299] New: git hooks should not require ISO-8859-15 encoding in git logs
https://sourceware.org/bugzilla/show_bug.cgi?id=27299 Bug ID: 27299 Summary: git hooks should not require ISO-8859-15 encoding in git logs Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: admin Assignee: unassigned at sourceware dot org Reporter: vapier at gentoo dot org Target Milestone: --- i just tried to push a commit with UTF-8 characters but it was rejected: remote: *** Invalid revision history for commit 6829d0d96d505e70b582e653c923294c7fed206b: remote: *** It contains characters not in the ISO-8859-15 charset. remote: *** remote: *** Below is the first line where this was detected (line 5): remote: *** | common/cgen-accfp.c: In function ‘fixsfsi’: remote: *** ^ remote: *** | remote: *** remote: *** Please amend the commit's revision history to remove it remote: *** and try again. i'd somewhat understand if we wanted to force the git log to only contain ASCII characters, but ISO-8859-15 is pretty weird. imo the only non-ASCII charset we should ever use/require is UTF-8. it's 2021, not 2001! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/22755] gold test suite failures (gentoo, 2.31)
https://sourceware.org/bugzilla/show_bug.cgi?id=22755 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at inbox dot ru, ||toolchain at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/27299] git hooks should not require ISO-8859-15 encoding in git logs
https://sourceware.org/bugzilla/show_bug.cgi?id=27299 --- Comment #1 from joseph at codesourcery dot com --- If you don't want that check then set no-rh-character-range-check = true in the hooks configuration (the file project.config on ref refs/meta/config), a feature added at my request when updating the version of the hooks used by GCC as I didn't think that character set check would be appropriate for GCC. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27297] libctf.a malformed, build fails on x86_64-apple-darwin18.7.0
https://sourceware.org/bugzilla/show_bug.cgi?id=27297 Stephen Casner changed: What|Removed |Added Attachment #13183|tarball of possibly |tarball of possibly description|relevant configs, |relevant configs, Makefiles |MakefilesAdded tarball of | |these files. Let me know | |if any others would be | |helpful. auge12> tar czf | |relevant.tgz intl/Makefile | |intl/config.* | |libctf/Makefile libc| -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27297] libctf.a malformed, build fails on x86_64-apple-darwin18.7.0
https://sourceware.org/bugzilla/show_bug.cgi?id=27297 --- Comment #2 from Stephen Casner --- git bisect finds this is the commit where the problem began: commit 1038406a8f6609ad0a449746da70393b0835f699 Author: Nick Alcock Date: Tue Jan 5 13:25:56 2021 + libctf: rip out BFD_DEPENDENCIES / BFD_LIBADD This complex morass inherited from libopcodes, which endeavours to implement the effect of specifying ../bfd/libbfd.la in _LIBADD without actually doing so, appears to be working around a libtool bug which as far as I can see is no longer present (i.e., the install directory no longer appears in -L arguments in libtool link-mode invocations, so there is no danger of picking up old libbfds or other dependent libraries). Replaced with a simple reference to libbfd.la in the appropriate place. Also adjusted things a little more so that libctf.la and libctf-nobfd.la are self-contained, even when linking statically. This opens up the possibility of running libtool to link against libctf from inside the (upcoming) testsuite. libctf/ChangeLog 2021-01-05 Nick Alcock * configure.ac (BFD_LIBADD): Remove. (BFD_DEPENDENCIES): Likewise. Remove associated cases. (SHARED_LIBADD): Rename to... (CTF_LIBADD): ... this. Stick in a suitable libiberty even when linking statically. * Makefile.am (libctf_nobfd_la_LIBADD): Adjust accordingly. libctf uses libintl. (libctf_la_LIBADD): Reference libbfd.la directly, not via BFD_LIBADD. (libctf_la_DEPENDENCIES): Remove. * Makefile.in: Regenerate. * configure: Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27302] New: windres: -I of preprocessor command line should be quoted
https://sourceware.org/bugzilla/show_bug.cgi?id=27302 Bug ID: 27302 Summary: windres: -I of preprocessor command line should be quoted Product: binutils Version: 2.36 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 13184 --> https://sourceware.org/bugzilla/attachment.cgi?id=13184&action=edit The patch Hello. I'm using your windres program. I have a trouble in preprocessor command line. In the command line of preprocessor, the generated option "-I" is not quoted the include path containing space. I want you to quote the -I option as follows: -Ipath ---> "-Ipath" Thanks, -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27302] windres: -I of preprocessor command line should be quoted
https://sourceware.org/bugzilla/show_bug.cgi?id=27302 --- Comment #1 from katayama.hirofumi.mz at gmail dot com --- Created attachment 13185 --> https://sourceware.org/bugzilla/attachment.cgi?id=13185&action=edit The helper C program -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/27303] New: gold/testsuite/initpri3. test fails on gold and lld, passes on bfd. Which one is correct?
https://sourceware.org/bugzilla/show_bug.cgi?id=27303
Bug ID: 27303
Summary: gold/testsuite/initpri3. test fails on gold and lld,
passes on bfd. Which one is correct?
Product: binutils
Version: 2.36
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: admin
Assignee: unassigned at sourceware dot org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
The test fails as is on gold:
$ gcc-11.0.0 initpri3.c -o bug -fuse-ld=lld && ./bug
bug: initpri3.c:78: main: Assertion `i == 3' failed.
Aborted (core dumped)
$ gcc-11.0.0 initpri3.c -o bug -fuse-ld=gold && ./bug
bug: initpri3.c:40: ctor2: Assertion `i == 2' failed.
Aborted (core dumped)
$ gcc-11.0.0 initpri3.c -o bug -fuse-ld=bfd && ./bug
It looks like the difference here is how the array of `.ctors` is handled:
```
/* The .ctors section is run in reverse order, the .dtors section in
run in forward order. We give these arrays the "aligned" attribute
because the x86_64 ABI would otherwise give them a 16-byte
alignment, which may leave a hole in the section. */
void (*ctors[]) (void)
__attribute__ ((aligned (4), section (".ctors"))) = {
ctor2,
ctor1
};
```
The array is stored as one section:
```
.section.ctors,"aw"
.align 8
.type ctors, @object
.size ctors, 16
ctors:
.quad ctor2
.quad ctor1
```
In both cases linker reordered the elements within the array:
$ gcc-11.0.0 initpri3.c -fuse-ld=gold -o ig -ggdb3
$ gcc-11.0.0 initpri3.c -fuse-ld=bfd -o ib -ggdb3
$ gdb --quiet ./ib
Reading symbols from ./ib...
(gdb) print ctors
$1 = {0x1139 , 0x117d }
$ gdb --quiet ./ig
Reading symbols from ./ig...
(gdb) print ctors
$1 = {0x689 , 0x6cd }
But not within __init_array_start:
$ gdb --quiet ./ib
Reading symbols from ./ib...
(gdb) start
Temporary breakpoint 1 at 0x124d: file initpri3.c, line 78.
Starting program: /tmp/z/ib
Temporary breakpoint 1, main () at initpri3.c:78
78assert (i == 3);
(gdb) x/4a __init_array_start
0x7dc8: 0x5130 0x5139
0x7dd8 : 0x517d 0x50f0
gdb --quiet ./ig
Reading symbols from ./ig...
(gdb) start
Temporary breakpoint 1 at 0x79d: file initpri3.c, line 78.
Starting program: /tmp/z/ig
ig: initpri3.c:40: ctor2: Assertion `i == 2' failed.
Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
49return ret;
(gdb) x/4a __init_array_start
0x5db8: 0x4680 0x46cd
0x5dc8 : 0x4689 0x3
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug admin/27303] gold/testsuite/initpri3. test fails on gold and lld, passes on bfd. Which one is correct?
https://sourceware.org/bugzilla/show_bug.cgi?id=27303 Sergei Trofimovich changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=22755 -- You are receiving this mail because: You are on the CC list for the bug.
