gcc: building gcc-4.5.0 for Cygwin

gcc: building gcc-4.5.0 for Cygwin

[Paul Bibbings]

Whilst I do use the versions of gcc available as Cygwin packages, I have
also successfully built from source and used other versions.  Most
recently I have added gcc-4.4.1, 4.4.3 and a 4.5.0 snapshot (end of Feb
2010).  I configure them to build and install in /opt/gcc-{version}. I
then incorporate these into the `alternatives' system and switch using
$alternatives --config gcc/g++ etc.

This has worked fine in the past, but with the recent release of
gcc-4.5.0 I have encountered a problem:

   17:59:37 Paul Bibbings@JIJOU
   /cygdrive/d/CPPProjects/Emacs/CPP0x $gcc -v
   Using built-in specs.
   COLLECT_GCC=gcc
   COLLECT_LTO_WRAPPER
      =/opt/gcc-4.5.0/libexec/gcc/i686-pc-cygwin/4.5.0/lto-wrapper.exe 
   Target: i686-pc-cygwin
   Configured with: ./configure --prefix=/opt/gcc-4.5.0
   --enable-bootstrap --enable-version-specific-runtime-libs
   --enable-static --enable-shared --enable-shared-libgcc
   --disable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2
   --disable-sjlj-exceptions --enable-languages=c,c++ --disable-symvers
   --enable-libgomp --enable-libssp --enable-threads=posix
   --with-arch=i686 --with-tune=generic 
   Thread model: posix
   gcc version 4.5.0 (GCC)

Unlike with my builds for gcc-4.4.1 and 4.4.3, say, this build has
dropped a string of .dlls into /opt/gcc-4.5.0/bin:

  17:59:41 Paul Bibbings@JIJOU
  /cygdrive/d/CPPProjects/Emacs/CPP0x $ls -l /opt/gcc-4.5.0/bin
  total 11320
  -rwxr-xr-x 4 ...  604046 Apr 15 09:04 c++.exe
  -rwxr-xr-x 1 ...  602030 Apr 15 09:04 cpp.exe
  -rwxr-xr-x 1 ...  437743 Apr 15 09:08 cyggcc_s-1.dll
  -rwxr-xr-x 1 ...  271146 Apr 15 09:08 cyggomp-1.dll
  -rwxr-xr-x 1 ...   55679 Apr 15 09:08 cygssp-0.dll
  -rwxr-xr-x 1 ... 5829289 Apr 15 09:07 cygstdc++-6.dll
  -rwxr-xr-x 4 ...  604046 Apr 15 09:04 g++.exe
  -rwxr-xr-x 3 ...  599400 Apr 15 09:05 gcc.exe
  -rwxr-xr-x 1 ...   16117 Apr 15 09:04 gccbug
  -rwxr-xr-x 1 ...  136186 Apr 15 09:04 gcov.exe
  -rwxr-xr-x 4 ...  604046 Apr 15 09:04 i686-pc-cygwin-c++.exe
  -rwxr-xr-x 4 ...  604046 Apr 15 09:04 i686-pc-cygwin-g++.exe
  -rwxr-xr-x 3 ...  599400 Apr 15 09:05 i686-pc-cygwin-gcc.exe
  -rwxr-xr-x 3 ...  599400 Apr 15 09:05 i686-pc-cygwin-gcc-4.5.0.exe

This now means that there are path issues for running applications built
with gcc-4.5.0 and there are certainly entry point failures:

   19:19:14 Paul Bibbings@JIJOU
   /cygdrive/d/CPPProjects/Emacs/CPP0x $cygcheck bin/CPP0x
   D:\CPPProjects\Emacs\CPP0x\bin\CPP0x.exe // built: gcc-4.5.0
     C:\cygwin\bin\cyggcc_s-1.dll           // wrong dll
       C:\cygwin\bin\cygwin1.dll
         C:\Windows\system32\ADVAPI32.DLL
           C:\Windows\system32\ntdll.dll
           C:\Windows\system32\KERNEL32.dll
           C:\Windows\system32\RPCRT4.dll
   C:\cygwin\bin\cygstdc++-6.dll            // wrong dll

   gdb: unknown target exception 0xc0000139 at 0x77d69eed
   During startup program exited with code 0xc0000139.

if the runtime sees the corresponding .dlls in /usr/bin first.
Prepending /opt/gcc-4.5.0/bin to the PATH get's round this, of course.
But now it's not as simple for my alternatives configuration: it works
for the build, but now it looks like I might need to control the runtime
too. 

My thought is to investigate incorporating the relevant .dlls into the
alternatives system, but before doing that I'd like to check out if
this sounds feasible.  Currently I have symlinks in /usr/bin for things
like gcc and g++, with:

   /usr/bin/gcc -> /etc/alternatives/gcc
   /usr/bin/g++ -> /etc/alternatives/g++

and then:

   /etc/alternatives/gcc -> /opt/gcc-4.5.0/bin/gcc.exe
   /etc/alternatives/g++ -> /opt/gcc-4.5.0/bin/g++.exe

Can I, then, do the same with the .dlls in question?  Is it possible,
for instance, for .dlls to be loadable via symlinks under Cygwin? E.g:

   /usr/bin/cygstdc++-6.dll -> /etc/alternatives/cygstdc++-6.dll

   /etc/alternatives/cygstdc++-6.dll ->
       /opt/gcc-4.5.0/bin/cygstdc++-6.dll
   [after $alternatives --config gcc, selecting gcc-4.5.0]

Or are there other options to consider?  My aim is to be able to
continue to switch between implementations using `alternatives' alone,
if that is at all possible, and to not have to think about changing and
reverting paths.

Have I perhaps configured/built this incorrectly?

Regards

Paul Bibbings



--
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: gcc: building gcc-4.5.0 for Cygwin

[Larry Hall (Cygwin)]

On 4/15/2010 2:26 PM, Paul Bibbings wrote:
> Can I, then, do the same with the .dlls in question?  Is it possible,
> for instance, for .dlls to be loadable via symlinks under Cygwin?

No.  The Windows loader does not recognize Cygwin symlinks.  Actually,
nothing in Windows does. ;-)

-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

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: gcc: building gcc-4.5.0 for Cygwin

[Paul Bibbings]

"Larry Hall (Cygwin)" <reply...@cygwin.com> writes:

> On 4/15/2010 2:26 PM, Paul Bibbings wrote:
>> Can I, then, do the same with the .dlls in question?  Is it possible,
>> for instance, for .dlls to be loadable via symlinks under Cygwin?
>
> No.  The Windows loader does not recognize Cygwin symlinks.  Actually,
> nothing in Windows does. ;-)

Indeed.  Thinking it through, as I am specifically wanting gcc-4.5.0 in
order to experiment with its implemented C++0x features, I am hardcoding
CC=i686-pc-cygwin-gcc-4.5.0 into the makefile anyway, so it's probably a 
reasonable workaround for the moment to add a `run' target along the
lines of: 

   run: $(OUT)
	@export PATH=/opt/gcc-4.5.0/bin:`printenv PATH` && $<

Regards

Paul Bibbings


--
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: gcc: building gcc-4.5.0 for Cygwin

[Jerry DeLisle]

Paul Bibbings wrote:
> Whilst I do use the versions of gcc available as Cygwin packages, I have
> also successfully built from source and used other versions.  Most
> recently I have added gcc-4.4.1, 4.4.3 and a 4.5.0 snapshot (end of Feb
> 2010).  I configure them to build and install in /opt/gcc-{version}. I
> then incorporate these into the `alternatives' system and switch using
> $alternatives --config gcc/g++ etc.
> 
> This has worked fine in the past, but with the recent release of
> gcc-4.5.0 I have encountered a problem:
> 
>    17:59:37 Paul Bibbings@JIJOU
>    /cygdrive/d/CPPProjects/Emacs/CPP0x $gcc -v
>    Using built-in specs.
>    COLLECT_GCC=gcc
>    COLLECT_LTO_WRAPPER
>       =/opt/gcc-4.5.0/libexec/gcc/i686-pc-cygwin/4.5.0/lto-wrapper.exe 
>    Target: i686-pc-cygwin
>    Configured with: ./configure --prefix=/opt/gcc-4.5.0
>    --enable-bootstrap --enable-version-specific-runtime-libs
>    --enable-static --enable-shared --enable-shared-libgcc
>    --disable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2
>    --disable-sjlj-exceptions --enable-languages=c,c++ --disable-symvers
>    --enable-libgomp --enable-libssp --enable-threads=posix
>    --with-arch=i686 --with-tune=generic 
>    Thread model: posix
>    gcc version 4.5.0 (GCC)
> 
> Unlike with my builds for gcc-4.4.1 and 4.4.3, say, this build has
> dropped a string of .dlls into /opt/gcc-4.5.0/bin:
> 
>   17:59:41 Paul Bibbings@JIJOU
>   /cygdrive/d/CPPProjects/Emacs/CPP0x $ls -l /opt/gcc-4.5.0/bin
>   total 11320
>   -rwxr-xr-x 4 ...  604046 Apr 15 09:04 c++.exe
>   -rwxr-xr-x 1 ...  602030 Apr 15 09:04 cpp.exe
>   -rwxr-xr-x 1 ...  437743 Apr 15 09:08 cyggcc_s-1.dll
>   -rwxr-xr-x 1 ...  271146 Apr 15 09:08 cyggomp-1.dll
>   -rwxr-xr-x 1 ...   55679 Apr 15 09:08 cygssp-0.dll
>   -rwxr-xr-x 1 ... 5829289 Apr 15 09:07 cygstdc++-6.dll
>   -rwxr-xr-x 4 ...  604046 Apr 15 09:04 g++.exe
>   -rwxr-xr-x 3 ...  599400 Apr 15 09:05 gcc.exe
>   -rwxr-xr-x 1 ...   16117 Apr 15 09:04 gccbug
>   -rwxr-xr-x 1 ...  136186 Apr 15 09:04 gcov.exe
>   -rwxr-xr-x 4 ...  604046 Apr 15 09:04 i686-pc-cygwin-c++.exe
>   -rwxr-xr-x 4 ...  604046 Apr 15 09:04 i686-pc-cygwin-g++.exe
>   -rwxr-xr-x 3 ...  599400 Apr 15 09:05 i686-pc-cygwin-gcc.exe
>   -rwxr-xr-x 3 ...  599400 Apr 15 09:05 i686-pc-cygwin-gcc-4.5.0.exe
> 
> This now means that there are path issues for running applications built
> with gcc-4.5.0 and there are certainly entry point failures:
> 
>    19:19:14 Paul Bibbings@JIJOU
>    /cygdrive/d/CPPProjects/Emacs/CPP0x $cygcheck bin/CPP0x
>    D:\CPPProjects\Emacs\CPP0x\bin\CPP0x.exe // built: gcc-4.5.0
>      C:\cygwin\bin\cyggcc_s-1.dll           // wrong dll
>        C:\cygwin\bin\cygwin1.dll
>          C:\Windows\system32\ADVAPI32.DLL
>            C:\Windows\system32\ntdll.dll
>            C:\Windows\system32\KERNEL32.dll
>            C:\Windows\system32\RPCRT4.dll
>    C:\cygwin\bin\cygstdc++-6.dll            // wrong dll
> 
>    gdb: unknown target exception 0xc0000139 at 0x77d69eed
>    During startup program exited with code 0xc0000139.
> 
> if the runtime sees the corresponding .dlls in /usr/bin first.
> Prepending /opt/gcc-4.5.0/bin to the PATH get's round this, of course.
> But now it's not as simple for my alternatives configuration: it works
> for the build, but now it looks like I might need to control the runtime
> too. 
> 
> My thought is to investigate incorporating the relevant .dlls into the
> alternatives system, but before doing that I'd like to check out if
> this sounds feasible.  Currently I have symlinks in /usr/bin for things
> like gcc and g++, with:
> 
>    /usr/bin/gcc -> /etc/alternatives/gcc
>    /usr/bin/g++ -> /etc/alternatives/g++
> 
> and then:
> 
>    /etc/alternatives/gcc -> /opt/gcc-4.5.0/bin/gcc.exe
>    /etc/alternatives/g++ -> /opt/gcc-4.5.0/bin/g++.exe
> 
> Can I, then, do the same with the .dlls in question?  Is it possible,
> for instance, for .dlls to be loadable via symlinks under Cygwin? E.g:
> 
>    /usr/bin/cygstdc++-6.dll -> /etc/alternatives/cygstdc++-6.dll
> 
>    /etc/alternatives/cygstdc++-6.dll ->
>        /opt/gcc-4.5.0/bin/cygstdc++-6.dll
>    [after $alternatives --config gcc, selecting gcc-4.5.0]
> 
> Or are there other options to consider?  My aim is to be able to
> continue to switch between implementations using `alternatives' alone,
> if that is at all possible, and to not have to think about changing and
> reverting paths.
> 
> Have I perhaps configured/built this incorrectly?
> 

I have not had any problems building with Cygwin 1.7 on WinNT or Win7.  You do 
have to make sure you have the mpc complex math library installed.  Other than 
that I have had no problems.

Jerry

--
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: gcc: building gcc-4.5.0 for Cygwin

[Paul Bibbings]

Jerry DeLisle <jvdelisle@verizon.net> writes:
> I have not had any problems building with Cygwin 1.7 on WinNT or Win7.
> You do have to make sure you have the mpc complex math library
> installed.  Other than that I have had no problems.
>
> Jerry

I've had no problems with the build itself, as far as I can tell.  The
issue I faced was over paths to the cyg<...>.dlls that it put in
/opt/gcc-4.5.0/bin, having configured it to install in
/opt/gcc-4.5.0. Obviously the runtime for programs built with gcc-4.5.0
requires these over the counterparts installed in /usr/bin by the Cygwin
versions with the same name.  As I reported in a previous post, I get
around this presently by adding a run target to my makefiles which
prepends /opt/gcc-4.5.0 to the path before running.  As I regularly
switch between several versions, including the Cygwin-installed gcc-3
and gcc-4, using the `alternatives' system, I had wanted to avoid
hard-setting the path only to face the same issues when switching away
from 4.5, which I am really only using to get a head start on C++0x.

The .dlls in question are:

    21:10:29 Paul Bibbings@JIJOU
    ~ $ls -l /opt/gcc-4.5.0/bin | grep dll
    -rwxr-xr-x 1 ...  437743 Apr 15 09:08 cyggcc_s-1.dll
    -rwxr-xr-x 1 ...  271146 Apr 15 09:08 cyggomp-1.dll
    -rwxr-xr-x 1 ...   55679 Apr 15 09:08 cygssp-0.dll
    -rwxr-xr-x 1 ... 5829289 Apr 15 09:07 cygstdc++-6.dll

Maybe I am missing something in having these in the first place.  I
didn't get any new .dlls for gcc-4.4.1, for instance:

    21:20:52 Paul Bibbings@JIJOU
    ~ $ls -l /opt/gcc-4.4.1/bin | grep dll

    21:22:23 Paul Bibbings@JIJOU

Can I ask, how did you configure your build?  Do you have these .dlls?
Also, do you have gcc-3 and/or -4 installed, with the .dlls these
require in /usr/bin?

Regards

Paul Bibbings


--
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: gcc: building gcc-4.5.0 for Cygwin

[Dave Korn]

On 17/04/2010 21:32, Paul Bibbings wrote:

> The .dlls in question are:
> 
>     21:10:29 Paul Bibbings@JIJOU
>     ~ $ls -l /opt/gcc-4.5.0/bin | grep dll
>     -rwxr-xr-x 1 ...  437743 Apr 15 09:08 cyggcc_s-1.dll
>     -rwxr-xr-x 1 ...  271146 Apr 15 09:08 cyggomp-1.dll
>     -rwxr-xr-x 1 ...   55679 Apr 15 09:08 cygssp-0.dll
>     -rwxr-xr-x 1 ... 5829289 Apr 15 09:07 cygstdc++-6.dll
> 
> Maybe I am missing something in having these in the first place.  I
> didn't get any new .dlls for gcc-4.4.1, for instance:

  That'd be my fault.  GCC never used to build DLLs for anything, except
libgcc, prior to 4.5.  Now it does, for all languages.  (At last, the simplest
possible "hello world" in java isn't 45 megabytes any more.)  They install
into $bindir, because that's where they need to be to be found easily;
alongside the executables that require them.

  Like a lot of libraries, they occasionally sprout new interfaces, but they
should always remain backwardly-compatible.  Applications compiled with older
GCC against older versions of the DLL ought to run just fine with the newer
ones (it's a bug if they don't), but of course applications compiled with the
newer compilers that actually make use of the new features in the newer
versions of the DLLs won't be able to work with older ones.

  From the end-user's point of view, the simple solution would be to not worry
about switching them round or alternatives or any of that, but just make sure
the newest ones are at the front of your $PATH at all times, you could even
feel free to install them straight into /usr/bin and just overwrite the
existing versions; everything should still work.

    cheers,
      DaveK



--
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: gcc: building gcc-4.5.0 for Cygwin

[Paul Bibbings]

Dave Korn <dave.korn.cygwin@googlemail.com> writes:

> On 17/04/2010 21:32, Paul Bibbings wrote:
>
>> The .dlls in question are:
>> 
>>     21:10:29 Paul Bibbings@JIJOU
>>     ~ $ls -l /opt/gcc-4.5.0/bin | grep dll
>>     -rwxr-xr-x 1 ...  437743 Apr 15 09:08 cyggcc_s-1.dll
>>     -rwxr-xr-x 1 ...  271146 Apr 15 09:08 cyggomp-1.dll
>>     -rwxr-xr-x 1 ...   55679 Apr 15 09:08 cygssp-0.dll
>>     -rwxr-xr-x 1 ... 5829289 Apr 15 09:07 cygstdc++-6.dll
>> 
>> Maybe I am missing something in having these in the first place.  I
>> didn't get any new .dlls for gcc-4.4.1, for instance:
>
>   That'd be my fault.  GCC never used to build DLLs for anything, except
> libgcc, prior to 4.5.  Now it does, for all languages.  (At last, the simplest
> possible "hello world" in java isn't 45 megabytes any more.)  They install
> into $bindir, because that's where they need to be to be found easily;
> alongside the executables that require them.
>
>   Like a lot of libraries, they occasionally sprout new interfaces, but they
> should always remain backwardly-compatible.  Applications compiled with older
> GCC against older versions of the DLL ought to run just fine with the newer
> ones (it's a bug if they don't), but of course applications compiled with the
> newer compilers that actually make use of the new features in the newer
> versions of the DLLs won't be able to work with older ones.
>
>   From the end-user's point of view, the simple solution would be to not worry
> about switching them round or alternatives or any of that, but just make sure
> the newest ones are at the front of your $PATH at all times, you could even
> feel free to install them straight into /usr/bin and just overwrite the
> existing versions; everything should still work.

This last is good to know, and would essentially solve the issue for
me.  I shall give it a try and report back only if I encounter problems.

Thanks for the clarification.

(BTW.  I'm guessing by "That'd be my fault" that you're working on gcc
upstream?)

Regards

Paul Bibbings



--
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: gcc: building gcc-4.5.0 for Cygwin

[Dave Korn]

On 20/04/2010 20:28, Paul Bibbings wrote:

> (BTW.  I'm guessing by "That'd be my fault" that you're working on gcc
> upstream?)

  I certainly am; my long-term goal is a) to synchronize upstream and
downstream so that in the end there are no cygwin-specific patches needed and
anyone can just build the plain sources from upstream and get a fully
compatible compiler that generates fully compatible executables, and b) to add
any missing support so that we can get features like LTO and graphite working.

  I think we're fairly close to there already, but there might be some minor
incompatibilities in odd corners of C++ related to typeinfos and dynamic
typecasts.

    cheers,
      DaveK


--
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: gcc: building gcc-4.5.0 for Cygwin

[Paul Bibbings]

Dave Korn <dave.korn.cygwin@googlemail.com> writes:

> On 20/04/2010 20:28, Paul Bibbings wrote:
>
>> (BTW.  I'm guessing by "That'd be my fault" that you're working on gcc
>> upstream?)
>
>   I certainly am; my long-term goal is a) to synchronize upstream and
> downstream so that in the end there are no cygwin-specific patches needed and
> anyone can just build the plain sources from upstream and get a fully
> compatible compiler that generates fully compatible executables, and b) to add
> any missing support so that we can get features like LTO and graphite working.
>
>   I think we're fairly close to there already, but there might be some minor
> incompatibilities in odd corners of C++ related to typeinfos and dynamic
> typecasts.

Well, then, I very much look forward to the fruits of all that hard
work and am grateful that it appears to be in `safe hands'.  And, well,
... thank you! :-)

Good luck with that.

Regards

Paul Bibbings


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