X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-0.6 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,SPF_HELO_PASS,TW_CX,TW_JL,TW_RW,TW_WX,TW_YM,T_RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By:	sourceware.org
To:	cygwin AT cygwin DOT com
From:	Paul Bibbings <paul DOT bibbings AT gmail DOT com>
Subject:	gcc: building gcc-4.5.0 for Cygwin
Date:	Thu, 15 Apr 2010 19:26:04 +0100
Lines:	104
Message-ID:	<87y6go3743.fsf@gmail.com>
Mime-Version:	1.0
User-Agent:	Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (windows-nt)
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

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?

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

- Raw text -