https://sourceware.org/bugzilla/show_bug.cgi?id=31250
--- Comment #6 from Nick Clifton <nickc at redhat dot com> --- (In reply to Amyspark from comment #4) > Applied the patch on top of mingw-w64-binutils (commit > c2aee7d89488d9402315d59d25852dff258c9eba), and can confirm it works as > expected. OK, that is good news. > Only nit I could propose is to keep track of those files that have been > basename'd and deduplicate (perhaps by replacing '/' with '_') in case > there's a collision between rogue objects. I thought about doing that, but it makes the patch a lot more complicated and in the end I think that we are already giving the users a bit too much leeway. Still if you find a real world situation where this decision becomes a problem then I am prepared to revisit the code and make the necessary changes. (In reply to Amyspark from comment #5) > > Is the library really valid if it contains absolute pathnames ? > > Yes, all that MSVC cares about is a) the symbol b) the path inside the .lib > pointing to an existing object. Actually that is a very interesting point. Does MSVC require that the path inside the lib point to an object that already exists or one that could exist, should the element be extract from the library ? For example suppose that a library contains an element with the path "E:/foo.obj". Is it required that E:/foo.obj also exists outside the library ? Is the library invalid if the external version of E:/foo.obj is different from the internal version ? Is the library invalid if the host does not have an E: drive ? What if the library contained an element with the path "C:/windows/system32/<something>" - surely such a library would be a huge security risk ? See PR 17533 where this problem is also discussed: https://sourceware.org/bugzilla/show_bug.cgi?id=17533#c4 Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
