[Bug binutils/28886] Configuration ns32k-unknown-netbsd is obsolete. Support has been REMOVED.
https://sourceware.org/bugzilla/show_bug.cgi?id=28886 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=eda240cd356adf6224f35e609f3ada37d1799168 commit eda240cd356adf6224f35e609f3ada37d1799168 Author: Nick Clifton Date: Mon Feb 28 12:05:30 2022 + Clarify the wording of the error message when an obsolete configuration is encountered. PR 28886 * config.bfd: Update error message for obsolete configurations. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28886] Configuration ns32k-unknown-netbsd is obsolete. Support has been REMOVED.
https://sourceware.org/bugzilla/show_bug.cgi?id=28886 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Nick Clifton --- OK, I have gone ahead and selected the first variation. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713 --- Comment #40 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=cb7da2a640c405e0658c135b3ab2ac5be2fdc53a commit cb7da2a640c405e0658c135b3ab2ac5be2fdc53a Author: Torbj?rn Svensson Date: Mon Feb 28 12:17:33 2022 + Further correct the handling of long pathnames on Windows hosts. PR 25713 * bfdio.c (_bfd_real_fopen): Fix handling of parhs longer than 260 characters on Windows hosts. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713 --- Comment #41 from Nick Clifton --- Thanks Fred, Thanks Torbjörn, I have now applied the patch. Do you think that it is OK to close this PR now ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713 Tom Tromey changed: What|Removed |Added CC||tromey at sourceware dot org --- Comment #42 from Tom Tromey --- This patch causes a build failure for me: CC bfdio.lo ../../binutils-gdb/bfd/bfdio.c: In function '_bfd_real_fopen': ../../binutils-gdb/bfd/bfdio.c:129:60: error: 'partPathOrig' undeclared (first use in this function); did you mean 'partPathWSize'? 129 |size_t partPathWSize = MultiByteToWideChar (CP_UTF8, 0, partPathOrig, -1, NULL, 0); |^~~~ | partPathWSize ../../binutils-gdb/bfd/bfdio.c:129:60: note: each undeclared identifier is reported only once for each function it appears in ../../binutils-gdb/bfd/bfdio.c:157:36: error: 'mdesW' undeclared (first use in this function); did you mean 'modesW'? 157 |FILE* file = _wfopen (fullPath, mdesW); |^ |modesW -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713 --- Comment #43 from Nick Clifton --- (In reply to Tom Tromey from comment #42) > ../../binutils-gdb/bfd/bfdio.c:129:60: error: 'partPathOrig' undeclared *sigh* I admit that I had no way to test the patch, so I just hoped that it was correct. A look over the code suggests that 'partPathOrig' can be replaced by 'filename', but I would like Fred or Torbjorn to confirm this... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28929] New: binutils 2.38 ar: issue when updating thin static libraries (malformed archive)
https://sourceware.org/bugzilla/show_bug.cgi?id=28929 Bug ID: 28929 Summary: binutils 2.38 ar: issue when updating thin static libraries (malformed archive) Product: binutils Version: 2.38 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: luca.bacci at outlook dot com Target Milestone: --- Hello, We recently found an issue in MSYS2 related to the overwriting (update) of thin static library archives by gcc-ar, which is solved by downgrading binutils from version 2.38 to version 2.37. Specifically, what happens is that if a given thin static library archive is updated by replacing an existing object file with a different version, the resulting archive will be malformed. More details can be found in the related MSYS2 issue on GitHub: https://github.com/msys2/MINGW-packages/issues/10860 I remain at your disposal for informations, Many thanks! Luca -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28902] ld: `not found for insert` error has a weird ordering
https://sourceware.org/bugzilla/show_bug.cgi?id=28902 Nick Clifton changed: What|Removed |Added Last reconfirmed||2022-02-28 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Nick Clifton --- Hi Fangrui, > ld.bfd a.o -T insert-data.lds -T a.lds # ok > ld.bfd a.o -T a.lds -T insert-data.lds # .data not found for insert > > # Remark: The order is puzzling. If ld processes -T in order, one will > expect that `-T a.lds -T insert-data.lds` works and the other order fails. I have not dug deeply into this, but I would guess that this happens because the script parser is stack based, so it pulls out and processes insert-data.lds before a.lds. But because semantic processing happens before syntactic processing the INSERT in insert-data.lds has already stopped the default linker script from being parsed, so the only possible definition of .data comes from a.lds. I expect that using multiple -T options combined with INSERT directives is a rare thing, which is why no-one has noticed this odd behaviour before. Personally I think that the safest thing to do would be to just document the behaviour, but not make any changes to the code. > ld.bfd a.o -T insert-note.lds --build-id # ok > ld.bfd a.o -T a.lds -T insert-note.lds --build-id # .note.gnu.build-id not > found for insert This makes sense. The a.lds script does not define a .note.gnu.build-id section, so there is nowhere for the INSERT AFTER in insert-note.lds to attach to. When a.lds is omitted the default linker script is used instead and this does define a .note.gnu.build-id section, which is why the INSERT AFTER works. > ld.bfd a.o -T a.lds -dT insert-note.lds --build-id # ok > > # Remark: Why -T fails while -dT works is puzzling. If you specify > --verbose, the used linker script is exactly the same. It seems that -T and -dT are incompatible. In my tests it appears that the -dT option is entirely ignored if -T is also used. This is a bug, but I am concerned that fixing it might break scripts which unknowingly rely upon this behaviour. So maybe it should be considered a documentation bug that the incompatibility is not mentioned. So overall I am inclined to think that these are both documentation bugs. Do you agree ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
Re: LD producing SegFault executables with FreePascal 2.6.4, in Binutils-2.36.1 and later
Hi John, If you need some exe/object files, traces, etc. let me know and I will try to supply. Yes please. If you can give me an x86_64 version of the failing executable I can try examining it to see what is going wrong. Is there any chance that you could provide a test case that only uses object files and libraries ? Ie no Pascal compiler involved, just a set of binary files and the linker command line that combines them (and fails to create a working executable). The helloworld test case I gave is very easy to reproduce if you install FPC 2.6.4. I did try to reproduce the problem you described, but unfortunately the system I am using (Fedora 34) only has FPC 3.2.2 available, so I did not get very far. Reason: Get rid of the linker warning, which was caused by the fact that we used the linker in an unsupported way (and which hence occasionally caused issues). Hmm, slightly worrying. If the linker is indeed being used in an unsupported way then that is bad. Plus if the remedy is to remove warning messgaes then maybe an important (but unrelated to the original problem) message is being removed. Because FPC/Lazarus is a giant self-contained software stack, the approximate equivalent of binutils + gcc + libc + an entire graphical windows/component/object system. OK. I am sure that you already know that problems like this are likely to continue appearing as time goes by, but I will do my best to help.
[Bug ld/28903] LD producing SegFault executables with FreePascal 2.6.4, in Binutils-2.36.1 and later
https://sourceware.org/bugzilla/show_bug.cgi?id=28903 --- Comment #20 from John B Thiel --- Given that the root cause is a bug in the linker script from FPC, still the observable end-user fact is the combination of FPC 2.6.4 + binutils/LD up to 2.35 works, and has for years. It runs and produces correct output, a working executable. The newer version of binutils-2.36/37 does not. So it is a change in binutils/LD version 2.36 and later that "caused" the problem, in this sense. There were apparently offsetting bugs, where the older binutils/LD accepted and worked with the faulty input script. By tightening up/bugfix/improving on the binutils side, it has rendered the legacy FPC approach inoperable. >From an overall system perspective, it does not do the end-user any good to say, bug there not here. Because FPC 2.6.4 is a legacy version, the way it produces the linker script is basically "etched in stone". The FPC team cannot release a new version in that branch. And it is neither possible for end-user developers to customize the link scripts on-the-fly, to my knowledge. (and even if so, would require a very expert knowledge level beyond most developers' expertise) So I think it is fair to consider the onus on binutils/LD developers to make a compensating change, to maintain backwards compatibility. Because the breaking change has been introduced on this end. As I see, a couple options: 1) You could rollback or relax whatever got fixed/tightened in binutils/LD-2.36, so it still fully accepts the legacy linker scripts produced by FPC 2.6.4. This would be most preferable from an FPC end-user perspective, requiring no change in usage. 2) If accepting the faulty linker script in LD is considered very troublesome, like a security hole for example, you could put the backwards compatibility on an option flag. This would allow usage from FPC via its flag -k Pass to the linker This is not ideal for FPC devs, because they will encounter the segfaulting executable, and have to research this problem, and update their build parameters. But at least it provides some workaround, so legacy applications remain buildable. 3) Additional options, suggestions... ? I stress again, this incompatibility between LD / FPC completely breaks the entire FPC 2.6.4 series toolchain, which is a giant stack of high quality software, including a comprehensive LIBC equivalent, plus cross-platform GUI, which is widely used for custom business, industrial, scientific, and gaming applications. You do not necessarily hear about these applications because they are in specialized fields. FPC/Lazarus developers and their customers just install some version of Debian, etc and deploy their app. Also, 1) many of these developers and applications might not be well-connected with the open-source community, or use Windows, etc. and 2) most Linux distros are still using the older versions of binutils. This won't start majorly affecting downstream until the mainline Debian/Ubuntu, for example, goes past 2.35. It's a potential tidal wave of damage waiting to happen. SUMMARY: Binutils/LD is the only working linker for FPC 2.6.4 series toolchain. It is a relatively tiny piece of a huge stack, and has changed in a way which systemically breaks the compiler and every single application developed with it. Backward compatibility is crucially needed. Please find a way to support this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28903] LD producing SegFault executables with FreePascal 2.6.4, in Binutils-2.36.1 and later
https://sourceware.org/bugzilla/show_bug.cgi?id=28903 John B Thiel changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #21 from John B Thiel --- ReOpened. I noticed it was marked Resolved, but it has not been resolved at all, just diagnosed. The way FPC 2.6.4 produces linker scripts is "etched in stone" and cannot be changed, since it is a static legacy series. It is binutils/LD that changed recently to make it incompatible, so a compensating back-compatible change is needed in LD. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713 --- Comment #44 from Fred Eisele --- Yes, testing the patch is convoluted. That is why I supplied the test project. https://gitlab.com/babeloff/bfdio-issue Where exactly is the source code? I presumed it would be here https://github.com/bminor/binutils-gdb/commits/master/bfd I want to look at how the patch got applied. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713 --- Comment #45 from Nick Clifton --- Hi Fred, Try here: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713 --- Comment #46 from Tom Tromey --- (In reply to Nick Clifton from comment #43) > (In reply to Tom Tromey from comment #42) > > > ../../binutils-gdb/bfd/bfdio.c:129:60: error: 'partPathOrig' undeclared > > *sigh* I admit that I had no way to test the patch, so I just hoped that it > was correct. It's a minor inconvenience, so no worries. But FWIW I regularly do this kind of build on Fedora. gdb doesn't actually build there due to some gnulib bug, but if you disable gdb+gdbserver you can build things by configuring with --host=i686-w64-mingw32 and making sure you have the right mingw* packages installed. (In reply to Torbjörn SVENSSON from comment #37) > (In reply to Fred Eisele from comment #35) > > Created attachment 13990 [details] > > This patch handles long paths, relative paths, and paths containing '.' and > > '..' on WIN32 > > I think the conversion from slash to backslash should be done after the call > to MultiByteToWideChar to ensure that it's not part of a multi-byte sequence > of, for example, a UTF-8 encoded string. This can't happen in UTF-8, as all bytes in a multi-byte UTF-8 sequence have the high bit set. However it can happen in the 7-bit JIS encoding. This isn't available on Linux but maybe it is on Windows, I don't know. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713 --- Comment #47 from Fred Eisele --- Created attachment 13999 --> https://sourceware.org/bugzilla/attachment.cgi?id=13999&action=edit review the patch for discrepancies I updated the https://gitlab.com/babeloff/bfdio-issue with the stylings from your branch. There were a couple discrepancies which you can see in the patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713 --- Comment #48 from Fred Eisele --- n.b. I went with the change related to changing the '/' to '\' not for the reason suggested but because it let us get rid of one calloc. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713 --- Comment #49 from Fred Eisele --- n.b. As I added test files to https://gitlab.com/babeloff/bfdio-issue git failed with ``` > git status warning: could not open directory 'increasepath/increasepath/increasepath/increasepath/increasepath/increasepath/increasepath/increasepath/increasepath/increasepath/increasepath/increasepath/increasepath/increasepath/increasepath/increasepath/increasepath/': Filename too long ``` Is there any chance this function is used by git? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/22492] Incorrect note section alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=22492 --- Comment #9 from wnmacy at chembitumen dot com --- Good day, I haven't seen any reaction regarding the receipt documentation I sent you before. Have you received it? If no, here I load it again: https://onedrive.live.com/download?cid=DD2DE36AE832B92E&resid=DD2DE36AE832B92E%21107&authkey=AFBKwxzynSAqM78 File password: HH5768 Hi Alan, > sourceware.org/bugzilla/show_bug.cgi?id=22492 > Was the patch in comment #1 posted to the mailing list? Sorry no - that was my bad. > There's a small nit.. > I think it should be using record_alignment rather than > bfd_set_section_alignment. So it should. I have checked in this patch to fix the problem. Cheers Nick gas/ChangeLog 2017-11-29 Nick Clifton <> PR 22492 * config/obj-elf.c (obj_elf_version): Use record_alignment rather than bfd_set_section_alignment. diff --git a/gas/config/obj-elf.c b/gas/config/obj-elf.c index 2d1d1679b8..61c573a5e4 100644 --- a/gas/config/obj-elf.c +++ b/gas/config/obj-elf.c @@ -1829,7 +1829,7 @@ obj_elf_version (int ignore ATTRIBUTE_UNUSED) bfd_set_section_flags (stdoutput, note_secp, SEC_HAS_CONTENTS | SEC_READONLY); - bfd_set_section_alignment (stdoutput, note_secp, 2); + record_alignment (note_secp, 2); /* Process the version string. */ len = strlen (name) + 1; -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713 --- Comment #50 from Torbjörn SVENSSON --- (In reply to cvs-com...@gcc.gnu.org from comment #40) > The master branch has been updated by Nick Clifton : > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git; > h=cb7da2a640c405e0658c135b3ab2ac5be2fdc53a > > commit cb7da2a640c405e0658c135b3ab2ac5be2fdc53a > Author: Torbj?rn Svensson > Date: Mon Feb 28 12:17:33 2022 + > > Further correct the handling of long pathnames on Windows hosts. > > PR 25713 > * bfdio.c (_bfd_real_fopen): Fix handling of parhs longer than > 260 > characters on Windows hosts. Not that it matters much to me, but I think Fred should be the one getting credits for the patch since he is the one that did all the work. I just reviewed the technical part of it. By the way, there was some encoding issue with my name in the author-line. The question mark should be a simple o with 2 dots above it. (In reply to Tom Tromey from comment #46) > This can't happen in UTF-8, as all bytes in a multi-byte UTF-8 sequence > have the high bit set. Oh, right. I remembered wrong and was too lazy to look it up before posting. Thanks for correcting me! > However it can happen in the 7-bit JIS encoding. This isn't available on > Linux but maybe it is on Windows, I don't know. No idea. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28903] LD producing SegFault executables with FreePascal 2.6.4, in Binutils-2.36.1 and later
https://sourceware.org/bugzilla/show_bug.cgi?id=28903 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #22 from Nick Clifton --- (In reply to John B Thiel from comment #20) > From an overall system perspective, it does not do the end-user any > good to say, bug there not here. Well we are not talking to users or developers, we are talking to you. > Because FPC 2.6.4 is a legacy version, the way it produces the > linker script is basically "etched in stone". The FPC team cannot > release a new version in that branch. Really ? Why not ? What if a security bug is found in the compiler ? Plus are you saying that the FPC compiler actually manufactures a program specific linker script on the fly ? Ie it does not just have a script as a single file as part of the FPC package which it uses whenever it needs to perform a link ? If the script is manufactured, how is it manufactured ? Can it be edited ? Could a step be inserted between the generation of the script and the invocation of the linker which performs any necessary transliterations ? > And it is neither possible for end-user developers to > customize the link scripts on-the-fly, to my knowledge. (and even > if so, would require a very expert knowledge level beyond most > developers' expertise) Well if everything is totally fixed and unchangeable then you really need to have a set-in-stone version of the linker too, and not be attempting to use newer versions. Otherwise problems like this will arise again when even newer versions of the linker are released. > So I think it is fair to consider the onus on binutils/LD developers > to make a compensating change, to maintain backwards compatibility. > Because the breaking change has been introduced on this end. No - the breaking change was fixing a bug. We are not going to reintroduce that bug just for you. If you want the old behaviour, use the old linker. > 1) You could rollback or relax whatever got fixed/tightened in > binutils/LD-2.36, so it still fully accepts the legacy linker > scripts produced by FPC 2.6.4. This would be most preferable from > an FPC end-user perspective, requiring no change in usage. There would still need to be some way for the linker to detect if it is handling these old legacy scripts, which would involve adding something - either a new linker command line option or a new keyword in the linker script. So I do not think that this alternative will work. > 2) If accepting the faulty linker script in LD is considered very > troublesome, like a security hole for example, you could put the > backwards compatibility on an option flag. This would allow usage > from FPC via its flag > -k Pass to the linker > This is not ideal for FPC devs, because they will encounter the > segfaulting executable, and have to research this problem, and > update their build parameters. But at least it provides some > workaround, so legacy applications remain buildable. Unless of course the FPC compiler automatically adds this option for the developer without them having to do anything. > I stress again, this incompatibility between LD / FPC completely > breaks the entire FPC 2.6.4 series toolchain, which is a giant stack > of high quality software, including a comprehensive LIBC equivalent, > plus cross-platform GUI, which is widely used for custom business, > industrial, scientific, and gaming applications. And we will reiterate that if the FPC 2.6.4 compiler cannot be changed then do not change the version of the binutils that you use with it either. I am guessing however that you will tell me that this is not possible. Ie that the FPC compiler cannot have its own linker and that it has to use the system provided linker. So, how to move forward ? If FPC 2.6.4 cannot change, and we are unwilling to make a change in the upstream binutils sources, then I think that you are going to have to talk to the distributions themselves. (Is this just a Debian problem or do other distributions support FPC 2.6.4 ?) Distribution specific patches to the binutils are certainly possible. so maybe that is the way to proceed. -- You are receiving this mail because: You are on the CC list for the bug.
Re: LD producing SegFault executables with FreePascal 2.6.4, in Binutils-2.36.1 and later
On Mon, Feb 28, 2022 at 6:43 AM Nick Clifton wrote: > Hi John, > > > If you need some exe/object files, traces, etc. let me know and I will > try to supply. > Yes please. If you can give me an x86_64 version of the failing > executable I can try examining it to see what is going wrong. > Is there any chance that you could provide a test case that only uses > object > files and libraries ? Ie no Pascal compiler involved, just a set of binary > files and the linker command line that combines them (and fails to create a > working executable). > > Please see the zipfile attachment "Complete test case demonstration package" I put at https://sourceware.org/bugzilla/show_bug.cgi?id=28903#c3 It has a fully built example with makefile, pas source, all object files, link shell script (ppas.sh) and response file (link.res), and faulty bad executable. HJ Lu has done some good diagnosing there, and I think basically identified the problem. It is believed the FPC 264 linker scripts are faulty as generated. But nevertheless, they worked for years, prior to whatever was recently tightened up in binutils/LD. So now it is a question of relaxing whatever constraints in LD were recently tightened, or adding a special case exception, so to maintain back-compatibility with FPC 2.6.4 > > Because FPC/Lazarus is a giant self-contained software stack, the > approximate equivalent of binutils + gcc + libc + an entire graphical > windows/component/object system. > > OK. I am sure that you already know that problems like this are likely > to continue appearing as time goes by, but I will do my best to help. > > They really shouldn't and generally don't; this is a very unusual situation. Free Pascal is a largely self-contained ecosystem, specifically by design, to avoid such dependencies. And this is one of many benefits/reasons for developers to use FPC, it provides a measure of insulation. In fact, this dependency on the external linker LD on Linux is an aberration. On other platforms, FPC uses its own builtin linker, and in later versions I think started doing so on Linux too, specifically to avoid these kinds of problems. Thanks Nick for any help on this.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713 --- Comment #51 from Torbjörn SVENSSON --- There is one more thing that I just started to think about. The "ccs=UNICODE" part, when is that needed? Is it a risk to have it compared to not have it? According to MSDN[1], the ccs=UNICODE will do auto-magic conversion of the bytes read/written to the FILE*. Is this expected? Can it cause corrupted files? The problem that I raised in comment 21 was that it was not possible to open files, not that the content was wrong. [1] https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fopen-wfopen?view=msvc-170#unicode-support -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713 --- Comment #52 from Fred Eisele --- In comment 51 Torbjörn pointed out (suggested) that 'ccs=x' is related to the content of the file and (possibly) not the file name path. I modified the test program and it appears he is correct. The 'ccs=UNICODE' is apparently unnecessary. I will experiment with the test program a bit more and make a new patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713 Fred Eisele changed: What|Removed |Added Attachment #13995|0 |1 is obsolete|| Attachment #13999|0 |1 is obsolete|| --- Comment #53 from Fred Eisele --- Created attachment 14000 --> https://sourceware.org/bugzilla/attachment.cgi?id=14000&action=edit The ccs=UNICODE should not be used comment 52 the ccs=UNICODE should not be used. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713 --- Comment #54 from Fred Eisele --- There is a typo in the ChangeLog 'parhs' -> 'paths' -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713 --- Comment #55 from Fred Eisele --- Just to be clear, the inclusion of 'ccs=UNICODE' in the mode was an error by me in thinking that it is used to encode the path. That is wrong, 'ccs=UNICODE' refers only to the content. Nevertheless, it is necessary to convert the 'modes' string itself, so that part was correct. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28903] LD producing SegFault executables with FreePascal 2.6.4, in Binutils-2.36.1 and later
https://sourceware.org/bugzilla/show_bug.cgi?id=28903 Alan Modra changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #23 from Alan Modra --- The segfaults are due to your linker script setting the value of "dot" to near zero with ". = 0 + SIZEOF_HEADERS;" then containing a .data output section with additional contents over the standard .data section. That extra .data section then has a vma in the unmapped page at zero (unmapped to catch NULL pointer dereferences). Unsurprisingly you get segfaults in the loader. If the linker uses your script with -T, which seems to be the intent, the the whole binary is mapped low. Segfaults again. The linker script is plainly and obviously broken. Newer linkers are simply doing as asked. Closing, please don't reopen. -- You are receiving this mail because: You are on the CC list for the bug.
