bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/16790] [cygwin|mingw] ld -v creates a.exe


From: yselkowitz at cygwin dot com
Subject: [Bug ld/16790] [cygwin|mingw] ld -v creates a.exe
Date: Wed, 02 Apr 2014 23:28:40 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=16790

Cygwin/X maintainer <yselkowitz at cygwin dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |corinna at vinschen dot de,
                   |                            |jon_y at users dot 
sourceforge.net

--- Comment #3 from Cygwin/X maintainer <yselkowitz at cygwin dot com> ---
(In reply to Nick Clifton from comment #2)
> I have uploaded a potential fix for the problem.  Please give it a try.

Thanks.  That works for the usual use cases, but doesn't fix the (admittedly
odd but seemingly allowed) possibility of ld -v --verbose.

> I am uncertain as to whether this is the right thing to do however.  Maybe
> it would be better to rethink the whole
> linker-is-responsible-for-adding-the-default-manifest idea.  IMHO it would
> be better if gcc/libgcc did this - after all it already has the multilib
> mechanism in place and it already builds files like crt0.o and crtend.o. 
> Why not add default-manifest.o to the list ?  The answer, as I understand
> it, is that the cygwin developers want the manifest added even if gcc is not
> used to link the application.  So maybe it is time to impose a requirement
> to use gcc to link all cygwin and mingw binaries ?

IIUC you are suggesting moving default-manifest.{rc,o} over to gcc, and adding
default-manifest.o to ENDFILE_SPEC in gcc/config/i386/cygwin.h and
gcc/config/i386/mingw32.h (mingw-w64 is covered by the latter wrt
ENDFILE_SPEC).  While most of the support work did have to go into ld, there
doesn't seem to be much precedent for this last step of ld adding object files
on its own.  Would anything have to be changed in pe{,p}.sc to continue to
avoid duplicate manifests if default-manifest.o is being passed with every link
(whether there is already a manifest or not)?

If that's not an issue, I think the main question would be one of deployment. 
As it's probably too late to get this into upstream GCC for 4.9.0; would 4.9.1
be a possibility, or would it end up sitting in trunk for a year or more until
4.10.0?  Until it's in a released and shipped version, it would be up to
vendors to maintain a patch.  For cygwin that's easy to assure, but there are a
lot of different vendors of mingw.org and/or mingw-w64 compilers.

The only other technical issue with that would be clang; last I checked (it's
been a while), it was still handing off to gcc for linking on PE platforms, but
if that has or will ever be changed to match the behaviour for (at least) linux
targets to link with ld, then it too would have to be patched.  This doesn't
mean that the burden of adding default-manifest.o must fall to binutils, but it
should be noted.

AFAIK nothing else links directly with ld for Cygwin; anything that tried would
likely be wrong anyway.  I imagine the same would be true for mingw*, but I
can't say for sure.

I'm CC'ing Corinna and JonY for their thoughts on this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]