Question on gcc install

[JonY]

On 6/20/2014 07:58, Arthur Schwarz wrote:
> Hi JonY;
> 
> I hope that this clarifies some of the thing yous mentioned (as well as
> others unmentioned).
> 
> None of the toolchains are multilib capable, so -m32/-m64 is not going
> to work. See also http://wiki.osdev.org/Target_Triplet
>    "> info gcc -> Option Index" shows -m32 and -m64 as valid 
>    Options Are there plans to change the info files so that 
>    they better represent the distributed versions of the 
>    compiler?
> 

Yes, they are valid options to gcc, but that does not mean gcc is able
to honor them. None of the builds are specifically set up for multilib.

> No, gdb happens to be invariant because you don't have cross gdb
> installed. You cannot debug 32bit code with 64bit gdb on Windows.
>    Would it be possible to clarify that 64-bit compiler target
>    Will only work on a compatible 64-bit gdb (same for 32-bit)
>    and that in order to get gcc to generate code for 32-bit
>    targets the setup-x86.exe must be used ant that in order to
>    get 64-bit target code setup-x86_64.exe must be used?
> 
> 

No, use the cross compilers, host and target triplets are not tied to
each other. You can easily run a 32bit compiler that targets 64bt etc,
eg x86_64-w64-mingw32-gcc on 32bit Cygwin.

>> If there is a resource document that I can look at to find the meaning of
>> life, could you tell me where to find it? I have downloaded the 
>> gcc.gnu.org document set for vrs. 4.8.3, Is this sufficient?
> 
> My advice is, stop jumping to conclusions, 
>    Could you please clarify what in the above sentence draws a 
>    conclusion? Are you saying that if I have concluded that
>    documentation exists that it does not?
> 

You jump to conclusion about "version" strings and "triplets", assume
differences where there are none.

> and stop assuming facts about how things are related, 
>    Could you please clarify what in the above sentence supports your 
>    statement? Are you saying that the gcc documentation for vrs. 4.8.3
>    Is not related to the gcc port?
> 

Just start using ${prefix}-gcc for cross compiles, and "gcc" for native
compiles, likewise for other frontend drivers.

> 
>    What on Earth is the python script for?
>       It is for gdb pretty-printing. Your questions are more 
>       appropriate on gcc-help.
>          Is there some reason a gdb script is located under
>          A gcc directory and not a gdb directory?
> 

Because libstdc++ internal structures are tied to gcc, not gdb.

> 
>    Supposing the following seems to have occurred with this release.
>       1: The use of appended version numbers in /bin has been 
>          abandoned.

That is up to upstream gcc to decide, I don't control how the executable
end up as.

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

It doesn't really matter where it goes, there is no meaning in it.

>       What?
>          In trying to understand your comment I assume that you
>          Are questioning items 1: and 2: above. 
>          1: the latest download, unlike previous downloads, is
>              Missing compiler files such as 
>              i686-pc-cygwin-gcc-4.8.2.exe.

Use "i686-pc-cygwin-gcc", so you don't have to mess around each and
every update.

>          2: In all cases except x86_64-w64-mingw32, there is
>             a directory in /usr and /usr/lib/gcc with the
>             same toolchain prefix as in /bin. Without being
>             tendentious I assume that you understand the
>             toolchain prefix as defined in 
>             http://wiki.osdev.org/Target_Triplet. You have 
>             requested that I make no assumptions, so I now
>             assume that the omission is deliberate and 
>             need no further investigation or action.
> 

That is right, because there is no hidden conspiracy theory behind it.

>    From http://wiki.osdev.org/Target_Triplet the compiler names
>    are:
>       machine-vendor-operatingsystem
> 
>    For the cygwin distribution this translates to:
>         i686-pc-cygwin
>         |    |  o- operating system
>         |    o- vendor
>         o- target platform
> 
>         x86_64-pc-cygwin
>         |      |  o- operating system
>         |      o- vendor
>         o- target platform
> 
>         i686-pc-mingw32/
>         |    |  o- operating system
>         |    o- vendor
>         o- target platform
> 
>         i686-w64-mingw32
>         |    |   o- operating system
>         |    o- vendor
>         o- target platform
> 
>         x86_64-w64-mingw32
>         |      |   o- operating system
>         |      o- vendor
>         o- target platform
> 
>        What is the w64 vendor and mingw32 operatingsystem?
>        I am relieved that the '32' in 'mingw32' has
>        no meaning.
> 

mingw32 is a shorthand for "stuff that runs on Windows and uses msvcrt".
The "w64" signifies the "mingw32" implementation came from mingw-w64, as
opposed to the default "pc", where it came from mingw.org. Different
implementations of the same target.

> 
>    /usr/share/doc/gcc/README and /usr/share/doc/gcc/INSTALL/README 
>    Reference the directory gcc/doc. Would it be possible to show 
>    the complete path to this directory?

It means <https://gcc.gnu.org/install/>.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://cygwin.com/pipermail/cygwin/attachments/20140620/c2c297e5/attachment.sig>