[Bug ld/31982] [2.43 Regression] mir 2.17 build failure during an LTO enabled build

2024-08-29 Thread jwakely.gcc at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=31982 Jonathan Wakely changed: What|Removed |Added CC||jwakely.gcc at gmail dot com

[Bug ld/31761] Linker deletes output file even if linking fails

2024-06-18 Thread jwakely.gcc at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=31761 Jonathan Wakely changed: What|Removed |Added CC||jwakely.gcc at gmail dot com

[Bug ld/31761] Linker deletes output file even if linking fails

2024-06-18 Thread jwakely.gcc at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=31761 --- Comment #10 from Jonathan Wakely --- (In reply to Alan Modra from comment #6) > I agree with Nick's comment. Consider too that if the link had succeeded, > your source file would have been overwritten (assuming of course that write > acce

[Bug ld/29973] x86_64-w64-mingw32-g++ ld: helloworld.exe:.rdata_r: section below image base for windows

2023-01-24 Thread jwakely.gcc at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=29973 Jonathan Wakely changed: What|Removed |Added CC|jwakely.gcc at gmail dot com | -- You are receiving this

[Bug ld/29973] x86_64-w64-mingw32-g++ ld: helloworld.exe:.rdata_r: section below image base for windows

2023-01-24 Thread jwakely.gcc at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=29973 --- Comment #7 from Jonathan Wakely --- (In reply to cqwrteur from comment #6) > Hi jwakely, I do not know whether it is an issue that relates to win32 > thread model of libstdc++ or it is the issue with gnu ld. Can you > investigate it for me

[Bug ld/29973] x86_64-w64-mingw32-g++ ld: helloworld.exe:.rdata_r: section below image base for windows

2023-01-14 Thread jwakely.gcc at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=29973 Jonathan Wakely changed: What|Removed |Added CC|jwakely.gcc at gmail dot com | -- You are receiving this

[Bug gold/28417] std::string no longer allows accepting nullptr_t since it is undefined behavior after yesterday's change on libstdc++.

2021-10-15 Thread jwakely.gcc at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=28417 --- Comment #10 from Jonathan Wakely --- Alan was replying to comment 6 where I said the default constructor could just be removed. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug gold/28417] std::string no longer allows accepting nullptr_t since it is undefined behavior after yesterday's change on libstdc++.

2021-10-14 Thread jwakely.gcc at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=28417 --- Comment #8 from Jonathan Wakely --- Then default constructing the string member is the right thing to do. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug gold/28417] std::string no longer allows accepting nullptr_t since it is undefined behavior after yesterday's change on libstdc++.

2021-10-14 Thread jwakely.gcc at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=28417 --- Comment #6 from Jonathan Wakely --- Search_directory() says: // We need a default constructor because we put this in a // std::vector That is not true since C++11. Since the constructor is broken (has undefined behaviour, which libstdc++

[Bug gold/28417] std::string no longer allows accepting nullptr_t since it is undefined behavior after yesterday's change on libstdc++.

2021-10-05 Thread jwakely.gcc at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=28417 --- Comment #4 from Jonathan Wakely --- Yes, the patch is correct. To construct an empty string either use "" as the initializer, or just use the default constructor. Creating a string from NULL or nullptr is completely bogus and has been und

[Bug ld/25747] Give more helpful diagnostic when users try to link to foo.a with -lfoo

2020-04-01 Thread jwakely.gcc at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25747 --- Comment #3 from Jonathan Wakely --- That was quick, thanks! N.B. the new diagnostic says "use use". -- You are receiving this mail because: You are on the CC list for the bug.

[Bug ld/25747] New: Give more helpful diagnostic when users try to link to foo.a with -lfoo

2020-03-30 Thread jwakely.gcc at gmail dot com
Severity: enhancement Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: jwakely.gcc at gmail dot com Target Milestone: --- It seems pretty common for beginners to name an archive foo.a and then expect -lfoo to find it. If a link

[Bug ld/18992] Linking a library implicitly using relative DT_RPATH does not work

2015-09-22 Thread jwakely.gcc at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=18992 Jonathan Wakely changed: What|Removed |Added CC||jwakely.gcc at gmail dot com