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

-----Original Message-----
From: Csaba Raduly [] 
Sent: Wednesday, June 18, 2014 12:43 AM
To: Arthur Schwarz
Cc: cygwin list
Subject: Re: Question on gcc install

Hi Arthur,

On Tue, Jun 17, 2014 at 6:31 PM, Arthur Schwarz  wrote:
> Win7
> gcc 4.8.3
> Netbeans 7.4
> Hi Csaba;
> I used setup.exe.

In that case, the behavior is entirely up to what setup.exe can do and
what the GCC packages tell it to do.

setup.exe _can_ delete files (as opposed to GCC's own build system,
which can install, but not uninstall). I don't understand how you
managed to get all those versions on your system; if you just kept
upgrading GCC, I would have expected the previous versions to be

Perhaps it's time for you to run   cygcheck -s -v -r   and attach its
output, as described in
> Problem reports:


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.

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:
      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

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.

Each prefix has two related directories:
   /usr   used by the compiler

   /usr/lib/gcc  contains version specific data for user (& compiler?)

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.

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 I would (ultimately) like to discover is resource material containing
the exact expected configurations and the meanings for all the prefixes.
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?

And in apologia, gcc maintenance is a huge undertaking. I would sincerely
like to thank everyone involved.


Attachment: cygcheck.out
Description: Binary data

Problem reports:
Unsubscribe info:

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