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 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 Content-Type: text/plain; charset=us-ascii 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: List-Subscribe: List-Archive: List-Post: List-Help: , 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