[Bug ld/16790] [cygwin|mingw] ld -v creates a.exe
https://sourceware.org/bugzilla/show_bug.cgi?id=16790 --- Comment #7 from Nick Clifton nickc at redhat dot com --- Hi Corinna, After some discussion with Jon_Y and Yaakov on IRC, I'm pretty much ok with moving the default-manifest handling to GCC. Excellent! :-) I'm just wondering if the default-manifest shouldn't then be made into its own package, independent of binutils and GCC, so that we can update the default manifest if a new Windows comes out, without having to update binutils or GCC packages as well. I guess that this could happen, Although maybe it could become part of the Cygwin and MinGW projects instead ? I assume that they are the only ones that need the default manifest. Hmm, that does mean keeping two copies of the manifest in sync in different projects, which is not ideal. So maybe a separate project would be better. How does one go about creating a new project anyway ? If we do that, GCC would have to handle three situations: - The default-manifest.o file doesn't exist in the search path. Don't even try to add it to the command line. Should GCC issue a warning in this case. (Assuming that it would want to add the default manifest to the linker command line if it could be found). - The manifest file exists, the -shared option is given. Don't add default-manifest.o to the command line. - The manifest file exists, the -shared option is not given. Append default-manifest.o to the command line. Will that work? Yes. Should be quite straightforward. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/16790] [cygwin|mingw] ld -v creates a.exe
https://sourceware.org/bugzilla/show_bug.cgi?id=16790 --- Comment #8 from Corinna Vinschen corinna at vinschen dot de --- (In reply to Nick Clifton from comment #7) Hi Nick, Hi Corinna, After some discussion with Jon_Y and Yaakov on IRC, I'm pretty much ok with moving the default-manifest handling to GCC. Excellent! :-) I'm just wondering if the default-manifest shouldn't then be made into its own package, independent of binutils and GCC, so that we can update the default manifest if a new Windows comes out, without having to update binutils or GCC packages as well. I guess that this could happen, Although maybe it could become part of the Cygwin and MinGW projects instead ? I assume that they are the only ones that need the default manifest. Hmm, that does mean keeping two copies of the manifest in sync in different projects, which is not ideal. So maybe a separate project would be better. How does one go about creating a new project anyway ? Easy: I'll create a new cygwin-apps project in the cygwin-apps CVS repo on sourceware called windows-default-manifest od some such, and I will create a Cygwin package from there. I put it under a freeware license so everybody who wants to pick it up is free to do so. I'll keep it up-to-date as far as new Windows version come along. If we do that, GCC would have to handle three situations: - The default-manifest.o file doesn't exist in the search path. Don't even try to add it to the command line. Should GCC issue a warning in this case. (Assuming that it would want to add the default manifest to the linker command line if it could be found). From my point of view, no warning should be issued. It's not a crucial problem at all. If it's missing, the executable still works, usually. - The manifest file exists, the -shared option is given. Don't add default-manifest.o to the command line. - The manifest file exists, the -shared option is not given. Append default-manifest.o to the command line. Will that work? Yes. Should be quite straightforward. Sounds good! Thanks, Corinna -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12696] BFD linker fails GCC LTO tests
https://sourceware.org/bugzilla/show_bug.cgi?id=12696 --- Comment #6 from cvs-commit at gcc dot gnu.org cvs-commit at gcc dot gnu.org --- This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project gdb and binutils. The branch, master has been updated via 17c34b8f3d79369cfb3a3f9d37109a7051bd8ea4 (commit) from 86ad98c392e804eae299eb6226e16732a521a9b4 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=17c34b8f3d79369cfb3a3f9d37109a7051bd8ea4 commit 17c34b8f3d79369cfb3a3f9d37109a7051bd8ea4 Author: Andreas Schwab sch...@linux-m68k.org Date: Sat Apr 5 22:03:44 2014 +0200 Fix spurious failures in ld-plugin/lto.exp * ld-plugin/lto.exp: Make -Wp, prefix optional when filtering out _FORTIFY_SOURCE. (Build libdummy.a 9, PR ld/12696): Mark as c++. --- Summary of changes: ld/testsuite/ChangeLog |6 ++ ld/testsuite/ld-plugin/lto.exp |8 2 files changed, 10 insertions(+), 4 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/16790] [cygwin|mingw] ld -v creates a.exe
https://sourceware.org/bugzilla/show_bug.cgi?id=16790 --- Comment #9 from Corinna Vinschen corinna at vinschen dot de --- (In reply to Corinna Vinschen from comment #8) (In reply to Nick Clifton from comment #7) I'm just wondering if the default-manifest shouldn't then be made into its own package, independent of binutils and GCC, so that we can update the default manifest if a new Windows comes out, without having to update binutils or GCC packages as well. I guess that this could happen, Although maybe it could become part of the Cygwin and MinGW projects instead ? I assume that they are the only ones that need the default manifest. Hmm, that does mean keeping two copies of the manifest in sync in different projects, which is not ideal. So maybe a separate project would be better. How does one go about creating a new project anyway ? Easy: I'll create a new cygwin-apps project in the cygwin-apps CVS repo on sourceware called windows-default-manifest od some such, and I will create a Cygwin package from there. I put it under a freeware license so everybody who wants to pick it up is free to do so. I'll keep it up-to-date as far as new Windows version come along. I created the project, so we can take the next steps: cvs -d :pserver:anon...@cygwin.com:/cvs/cygwin-apps co windows-default-manifest Corinna -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/16807] Bad behavior with resources of Windows applications with recent binutils upgrade on Cygwin64
https://sourceware.org/bugzilla/show_bug.cgi?id=16807 --- Comment #2 from Angelo Graziosi angelo.graziosi at alice dot it --- (In reply to Nick Clifton from comment #1) Hi Corinna, I have started looking into this bug, but I am a bit stumped. :-( I guess that the problem is connected with the default manifest being added in to the executable's resources. But looking at the decompiled resources in the dlg_one.out executable everything looks fine. Then I started to wonder. Maybe it is the fact that there are now *3* top level entries in the resource Type table instead of 2. Maybe the dlg_one.c application only expects there to be 2 entries and somehow it is getting confused. Unfortunately I am not enough of a Window resource expert to tell. But you are... So - is this a possibility ? Just for completeness, the workaround described here http://cygwin.com/ml/cygwin/2014-04/msg00134.html works for me. It seems to confirm that the origin of these issues is this defaul manifest in new binutils releases. Ciao, Angelo. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
