RE: Re: Question on gcc install

RE: Re: Question on gcc install

[Arthur Schwarz]

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?

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?


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

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?

and fix your email client to reply to threads properly instead of starting a
new thread for every reply.
   I am trying. I am terribly sorry that this occurs.

   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?


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

   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.


   /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?

Thanks
art


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Question on gcc install

[Larry Hall (Cygwin)]

On 06/19/2014 07:58 PM, Arthur Schwarz wrote:

<snip>

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

This is how it works now.  Only if you install both environments
will there be 2 versions.  It's assumed that if you install both,
you know to keep them separate.  Mixing the two environments won't
work.

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

See:

<https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86%2Fgcc-core%2Fgcc-core-4.8.2-2&grep=i686-pc-cygwin-gcc-4.8.2.exe>

It's in there.  If you don't have it, install it.  If it's already
installed, re-install.

-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Question on gcc install

[JonY]

[-- Attachment #1: Type: text/plain, Size: 5578 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

RE: Question on gcc install

[Arthur Schwarz]

> At the present time /bin/gcc.exe, etc., works. /bin/*mingw*.exe either
> compiles but does not link, or does not compile - which seems to be a
header
> issue. gcc -m32 does not work which may be a gcc.gnu issue.
> 

Can you at least be specific about the errors? It is rather frustrating
reading your emails, being so vague about and all. Are you mixing Cygwin
and mingw code?

   Sorry. I was remiss.

   Execution fails on all of the mingw compilers with the same error
   message. All compilations use the same command line options.

   > i686-pc-mingw32-g++ -Wall -Wno-reorder -Wno-unused-value -DYYDEBUG=1 
     -DDEBUG_IO   -c -g -MMD -MP -MF

   > slip.exe

/E/home/skidmarks/Projects/SLIP/slip/dist/Debug/mingw-Windows/slip.exe:
error while loading shared libraries: libstdc++-6.dll: cannot open shared
object file: No such file or directory

RUN FAILED (exit value 127, total time: 15ms)

After execution I ran the following find on /usr.

> find /usr/i686-pc-cygwin 
       /usr/i686-pc-mingw32 
       /usr/i686-w64-mingw32 
       /usr/x86_64-w64-mingw32 -iname 'libstdc++-6.dll'

i686-pc-mingw32/sys-root/mingw/bin/libstdc++-6.dll
i686-w64-mingw32/sys-root/mingw/bin/libstdc++-6.dll
x86_64-w64-mingw32/sys-root/mingw/bin/libstdc++-6.dll

/usr/i686-pc-cygwin apparently does not use this dll and the generated mingw
executables can not find it. Can anything be done about this - I refrain
from 'guessing', 'inferring', or 'assuming (causality)'.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Question on gcc install

[JonY]

[-- Attachment #1: Type: text/plain, Size: 2004 bytes --]

On 6/20/2014 22:37, Arthur Schwarz wrote:
> 
>> At the present time /bin/gcc.exe, etc., works. /bin/*mingw*.exe either
>> compiles but does not link, or does not compile - which seems to be a
> header
>> issue. gcc -m32 does not work which may be a gcc.gnu issue.
>>
> 
> Can you at least be specific about the errors? It is rather frustrating
> reading your emails, being so vague about and all. Are you mixing Cygwin
> and mingw code?
> 
>    Sorry. I was remiss.
> 
>    Execution fails on all of the mingw compilers with the same error
>    message. All compilations use the same command line options.
> 
>    > i686-pc-mingw32-g++ -Wall -Wno-reorder -Wno-unused-value -DYYDEBUG=1 
>      -DDEBUG_IO   -c -g -MMD -MP -MF
> 
>    > slip.exe
> 
> /E/home/skidmarks/Projects/SLIP/slip/dist/Debug/mingw-Windows/slip.exe:
> error while loading shared libraries: libstdc++-6.dll: cannot open shared
> object file: No such file or directory
> 
> RUN FAILED (exit value 127, total time: 15ms)
> 

You are not supposed to run cross compiled executable files. This is not
even a linker error.

> After execution I ran the following find on /usr.
> 
>> find /usr/i686-pc-cygwin 
>        /usr/i686-pc-mingw32 
>        /usr/i686-w64-mingw32 
>        /usr/x86_64-w64-mingw32 -iname 'libstdc++-6.dll'
> 
> i686-pc-mingw32/sys-root/mingw/bin/libstdc++-6.dll
> i686-w64-mingw32/sys-root/mingw/bin/libstdc++-6.dll
> x86_64-w64-mingw32/sys-root/mingw/bin/libstdc++-6.dll
> 
> /usr/i686-pc-cygwin apparently does not use this dll and the generated mingw
> executables can not find it. Can anything be done about this - I refrain
> from 'guessing', 'inferring', or 'assuming (causality)'.
> 
> 

Do not guess, there is nothing to infer from it, it is done on purpose.
You will need to copy these to where your executable programs are
running. Additionally, you mustn't mix DLLs from different toolchains,
so in this case, take the dll from i686-pc-mingw32.





[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

RE: Question on gcc install

[Arthur Schwarz]

On 6/20/2014 22:37, Arthur Schwarz wrote:
> 
>> At the present time /bin/gcc.exe, etc., works. /bin/*mingw*.exe 
>> either compiles but does not link, or does not compile - which seems 
>> to be a
> header
>> issue. gcc -m32 does not work which may be a gcc.gnu issue.
>>
> 
> Can you at least be specific about the errors? It is rather 
> frustrating reading your emails, being so vague about and all. Are you 
> mixing Cygwin and mingw code?
> 
>    Sorry. I was remiss.
> 
>    Execution fails on all of the mingw compilers with the same error
>    message. All compilations use the same command line options.
> 
>    > i686-pc-mingw32-g++ -Wall -Wno-reorder -Wno-unused-value -DYYDEBUG=1 
>      -DDEBUG_IO   -c -g -MMD -MP -MF
> 
>    > slip.exe
> 
> /E/home/skidmarks/Projects/SLIP/slip/dist/Debug/mingw-Windows/slip.exe:
> error while loading shared libraries: libstdc++-6.dll: cannot open 
> shared object file: No such file or directory
> 
> RUN FAILED (exit value 127, total time: 15ms)
> 

You are not supposed to run cross compiled executable files. This is not
even a linker error.

    I compiled my program with each of the mingw32 compilers.
    After each compilation I copied the libstdc++-6.dll into
    the directory containing the compiled executable and then
    ran the compiled code. After each execution I received the
    same error. Are you saying that the mingw32 compiled code
    is cross-compiled to a non-intel, non-windows and/or
    non-cygwin architecture and that is why the code doesn't
    execute? What are you supposed to do with mingw32 compiled
    code instead of executing it?


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Question on gcc install

[JonY]

[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]

On 6/22/2014 00:43, Arthur Schwarz wrote:
>> /E/home/skidmarks/Projects/SLIP/slip/dist/Debug/mingw-Windows/slip.exe:
>> error while loading shared libraries: libstdc++-6.dll: cannot open 
>> shared object file: No such file or directory
>>
>> RUN FAILED (exit value 127, total time: 15ms)
>>
> 
> You are not supposed to run cross compiled executable files. This is not
> even a linker error.
> 
>     I compiled my program with each of the mingw32 compilers.
>     After each compilation I copied the libstdc++-6.dll into
>     the directory containing the compiled executable and then
>     ran the compiled code. After each execution I received the
>     same error. Are you saying that the mingw32 compiled code
>     is cross-compiled to a non-intel, non-windows and/or
>     non-cygwin architecture and that is why the code doesn't
>     execute? What are you supposed to do with mingw32 compiled
>     code instead of executing it?
> 
> 

There you go again with all the implications, mingw32 code is cross
compiled from Cygwin's point of view, so don't run it under Cygwin. Run
it under cmd or something.

Was that too hard to understand?



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Question on gcc install

[René Berber]

On 6/21/2014 9:13 PM, JonY wrote:

> There you go again with all the implications, mingw32 code is cross
> compiled from Cygwin's point of view, so don't run it under Cygwin. Run
> it under cmd or something.
>
> Was that too hard to understand?

Yes, because its not true, the code runs fine under Cygwin (as long as 
the executable and its dependencies are in the PATH, or on the current 
working directory, and all of them have the executable attribute set, 
i.e. it follows Windows' rules) the same as any other Windows program 
runs under Cygwin.
-- 
René Berber


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Question on gcc install

[JonY]

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]

On 6/22/2014 12:24, René Berber wrote:
> On 6/21/2014 9:13 PM, JonY wrote:
> 
>> There you go again with all the implications, mingw32 code is cross
>> compiled from Cygwin's point of view, so don't run it under Cygwin. Run
>> it under cmd or something.
>>
>> Was that too hard to understand?
> 
> Yes, because its not true, the code runs fine under Cygwin (as long as
> the executable and its dependencies are in the PATH, or on the current
> working directory, and all of them have the executable attribute set,
> i.e. it follows Windows' rules) the same as any other Windows program
> runs under Cygwin.

Sure you can make it work by messing with PATH, but you'd run into other
issues like PATH translation from the command line etc. Do to simplify
it for the user, just don't do it if you don't know what you're doing.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

RE: Re: Question on gcc install

[Arthur Schwarz]

Win7
gcc 4.8.3-?
Netbeans 7.4

Hi csaba;

I just downloaded the latest version of gcc (16 Jun version). Strangely
enough, the [ANNOUNCEMENT] says that it is gcc 4.8.3-1 and the setup
download says it is gcc 4.8.3-2. Sigh.

There are some changes. The 
    i686-pc-cygwin-gcc-4.8.2.exe
    x86_64-pc-cygwin-gcc-4.8.3.exe

executables are missing as well as all executables for gnu cygwin, that is:
    i686-pc-cygwin-*
    x86_64-pc-cygwin-*

instead we are left with our friends, gcc.exe, g++.exe, gfortran.exe, and
as.exe.

The /usr directories and the /usr/lib/gcc directories are unchanged. I can
understand (I think) the /usr directories, there is 1 directory supporting
gnu cygwin and 3 directories supporting mingw, but I don't understand
/usr/lib/gcc. There is, at best, only one gnu cygwin executable toolchain,
but there are 2 directories which support gnu cygwin,
    i686-pc-cygwin
    x86_64-pc-cygwin

Now if I can sort of make sense out of the previous collection of
executables and directories, this one seems to have too many directories for
the supported gnu cygwin compilers in /usr/lib/gcc or too few executables in
/bin.

There is but one other point. There has been a change to the compiler
version supported in /usr/lib/gcc/i686-pc-cygwin. It is now 4.8.3 instead of
4.8.2. The new list is:
    /usr/lib/gcc/
        i686-pc-cygwin        4.8.3
        i686-pc-mingw32       4.7.3
        i686-w64-mingw32      4.8.2
        x86_64-pc-cygwin      4.8.3
        x86_64-w64-mingw32    4.8.2

Bye the bye, being a quick and quite inaccurate typist, my last e-mail
should have said, "In any case, anything you can do to clarify would be
appreciated (including the statement, "read the book")." The sentiment is
still valid.

art 


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple