[Bug binutils/30969] ar cannot be safely invoked in parallel on windows
https://sourceware.org/bugzilla/show_bug.cgi?id=30969 Sam James changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=30958 CC||sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30969] ar cannot be safely invoked in parallel on windows
https://sourceware.org/bugzilla/show_bug.cgi?id=30969 Sam James changed: What|Removed |Added CC||bruno at clisp dot org, ||eggert at gnu dot org --- Comment #1 from Sam James --- Given the discussion in PR30958, wouldn't it be better to sync with newer gnulib? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30969] ar cannot be safely invoked in parallel on windows
https://sourceware.org/bugzilla/show_bug.cgi?id=30969 --- Comment #2 from Sterpu Mihai --- Hi Sam, The issue is that, from what I see, we now have 2 different implementations. This isn't an easy out of sync case. One might even argue that glibc's implementation is the "outdated" one as it leaks ASLR information via the temporary file names. The gnulib commit in cause, 9ce573cde017182a69881241e8565ec04e5bc728, done by Paul Eggert, states that: "While looking into this, I noticed that tempname can leak info derived from ASLR into publicly-visible file names, which is a no-no. Fix that too." Maybe it would be a good idea to involve Paul as well? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30969] ar cannot be safely invoked in parallel on windows
https://sourceware.org/bugzilla/show_bug.cgi?id=30969 Sterpu Mihai changed: What|Removed |Added CC||eggert at cs dot ucla.edu -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30969] ar cannot be safely invoked in parallel on windows
https://sourceware.org/bugzilla/show_bug.cgi?id=30969 --- Comment #3 from Bruno Haible --- > Given the discussion in PR30958, wouldn't it be better to sync with newer > gnulib? Yes. As indicated in my reply https://lists.gnu.org/archive/html/bug-gnulib/2023-10/msg00058.html , this problem on mingw would not have happened if GNU binutils were using the Gnulib 'mkstemp' module. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30969] ar cannot be safely invoked in parallel on windows
https://sourceware.org/bugzilla/show_bug.cgi?id=30969 --- Comment #4 from Bruno Haible --- (In reply to Sterpu Mihai from comment #2) > The issue is that, from what I see, we now have 2 different implementations. No, there are 3 different implementations: The mingw one, the gnulib one, and the glibc one. The binaries that you are running use the mingw implementation. All your argumentation about the gnulib code vs. the glibc code is therefore pointless. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30969] ar cannot be safely invoked in parallel on windows
https://sourceware.org/bugzilla/show_bug.cgi?id=30969 --- Comment #5 from Bruno Haible --- I wrote: > No, there are 3 different implementations: The mingw one, the gnulib one, > and the glibc one. Correction: There are 4 different implementations: The binutils one (bucomm.c), the mingw one, the gnulib one, and the glibc one. The 'ar' program is most likely using the binutils one, which - according to what you tested - is a low-quality implementation, like the mingw one. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30969] ar cannot be safely invoked in parallel on windows
https://sourceware.org/bugzilla/show_bug.cgi?id=30969 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #6 from Nick Clifton --- (In reply to Bruno Haible from comment #5) > I wrote: > > No, there are 3 different implementations: The mingw one, the gnulib one, > > and the glibc one. > > Correction: There are 4 different implementations: The binutils one > (bucomm.c), If we are talking about implementations of mkstemp() then bucomm.c does not do that. Instead bucomm.c contains a function called make_tempname() which uses whichever version of mkstemp is provided by the C library at the time of program execution. > the mingw one, the gnulib one, and the glibc one. There is however a sort-of fourth candidate in the form of the mkstemps() function provided by the libiberty library (in the libiberty/mkstemps.c file in the binutils sources). This version is not used by bucomm.c however as it has issues with paths that contain directory names. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/30867] merge.cc:668:27: error: ‘char16_t’ was not declared in this scope
https://sourceware.org/bugzilla/show_bug.cgi?id=30867 --- Comment #3 from vvinayag at arm dot com --- (In reply to Szabolcs Nagy from comment #2) > on a second thought gold likely requires > > AX_CXX_COMPILE_STDCXX(11, , mandatory) > > in its configure.ac Adding -std=gnu++11 to the binutils CXX flags (in our build script) does fix the issue. Should this be fixed in the build scripts, or in the configure.ac? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30970] [rfe] please include HPA segelf work
https://sourceware.org/bugzilla/show_bug.cgi?id=30970 Stas Sergeev changed: What|Removed |Added CC||hjl.tools at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30970] [rfe] please include HPA segelf work
https://sourceware.org/bugzilla/show_bug.cgi?id=30970 Stas Sergeev changed: What|Removed |Added CC||hpa at zytor dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30970] [rfe] please include HPA segelf work
https://sourceware.org/bugzilla/show_bug.cgi?id=30970 Stas Sergeev changed: What|Removed |Added CC||amodra at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30970] [rfe] please include HPA segelf work
https://sourceware.org/bugzilla/show_bug.cgi?id=30970 Stas Sergeev changed: What|Removed |Added CC||nickc at redhat dot com -- You are receiving this mail because: You are on the CC list for the bug.
