Message-id: <4BC904E3.60500@verizon.net>
Date: Fri, 16 Apr 2010 17:46:27 -0700
From: Jerry DeLisle <jvdelisle AT verizon DOT net>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: gcc: building gcc-4.5.0 for Cygwin
References: <87y6go3743 DOT fsf AT gmail DOT com>
In-reply-to: <87y6go3743.fsf@gmail.com>
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

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