This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question on gcc install


On 6/18/2014 23:11, Arthur Schwarz wrote:
> I am including cygcheck.out as an attachment. 
> 
> Andrey Repin pointed out to me that my various e-mail responses are
> scattered all over the mailing list. I am very sorry for this and hope that
> at least this e-mail is put in the appropriate place so that proper tracking
> can be done. If you have not seen my prior posts then some of the history
> and flavor of comments in this post may be lost.
> 

Please don't add "--" to separate your text from others too, it is
treated as a signature in some clients.

> I don't think that there is an error in cygwin. I think that the number of
> executables, directories, etc. is by intent. What I am trying to do is to
> discover the intent and then, if necessary, report errors.
> 
> Here are a list of guesses:
>    /bin
>       i686-pc-cygwin.*      Related toolchain for a compiler
>       i686-pc-mingw32.*     i686/x86 indicates the compiler instruction set
>       i686-w64-mingw32.*    pc/w64 = 32/64-bits the input architecture (?)
>       x86_64-pc-cygwin.*    cygwin/mingw32 the compiler producer
>       x86_64-w64-mingw32.*
> 
> It is also possible (again I'm guessing) the prefix represents the output
> architecture rather than the compiler architecture. This would (perhaps)
> explain why the gcc -m32 option has been disabled. If the -m32 option is not
> disabled by intent then there is a compiler bug, and if it is disabled by
> intent then this indicates a departure from behavior for a direct port.
> 

None of the toolchains are multilib capable, so -m32/-m64 is not going
to work. See also http://wiki.osdev.org/Target_Triplet

> Each prefix has two related directories:
>    /usr   used by the compiler
>       i686-pc-cygwin/
>       i686-pc-mingw32/
>       i686-w64-mingw32
>       x86_64-pc-cygwin
>       x86_64-w64-mingw32
> 
>    /usr/lib/gcc  contains version specific data for user (& compiler?)
>       i686-pc-cygwin/vrs/
>       i686-pc-mingw32/vrs/
>       i686-w64-mingw32/vrs/
>       x86_64-pc-cygwin/vrs/
>       x86_64-w64-mingw32/vrs/
> 
> Prefixes with an appended version number in /bin are given as a visual
> indication of the version of the software associated with the prefix. For
> example, i686-pc-cygwin-gcc-4.8.2.exe indicates that the toolchain for
> i686-pc-cygwin is specific to gcc 4.8.2. I think that
> i686-pc-cygwin-gcc-4.8.2.exe is the same file as i686-pc-cygwin-gcc.exe.
> 

Yes.

> Supposing the following seems to have occurred with this release.
> 1: The use of appended version numbers in /bin has been abandoned.
> 2: The latest distribution (16 Jun) has an error in that x86_64-w64-mingw32
> does not have an associated file in /usr/. There is an associated file in
> /usr/lib/gcc however.
> 

What?

> What I would (ultimately) like to discover is resource material containing
> the exact expected configurations and the meanings for all the prefixes.

http://wiki.osdev.org/Target_Triplet

> What is what and what goes where. And I would like to have a resource rather
> than wasting bandwidth on the mailing list. To this I would add that the
> information in /usr/share/doc/gcc is not specific to the installation on
> cygwin, and also that /usr/share/gcc-vrs/ has a nested python script. What
> on Earth is the python script for?
> 

It is for gdb pretty-printing. Your questions are more appropriate on
gcc-help.


Attachment: signature.asc
Description: OpenPGP digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]