X-Spam-Check-By: sourceware.org Message-ID: <466E2B5D.C565B230@dessent.net> Date: Mon, 11 Jun 2007 22:13:01 -0700 From: Brian Dessent X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Using a secondary install of gcc/g++ binutils References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com 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 Brian Dantes wrote: > I am trying to deploy a secondary install of gcc/g++ under Cygwin. For a > package I am developing I need to keep the compiler and binutils stable even > if the Cygwin environment itself changes. I am using the the compiler in > -mno-cygwin mode to generates Win32 binaries -- I am not using the MinGW > compiler directly because it does not understand Cygwin paths, and I really > need the Cygwin environment to smoothly integrate other third party packages > that rely on an autoconf/automake/configure setup as closely matching Unix > as possible. An alternative tack then would be to just use the MinGW toolchain with a bash wrapper script that cygpaths POSIX paths into win32 paths. In essence, this is exactly what MSYS does -- although it does it natively in the runtime instead of using a wrapper script. Its whole design goal and reason for existance is using native tools that only understand win32 paths with POSIX build environments, i.e. autoconf/automake/libtool with m4/bourne/perl scripting. So if that is your primary goal, I would use MSYS and not Cygwin. But that's quite off-topic for this list, which is definitely not for MSYS support. > I have been trying use the --sysroot (I am talking about the compile option > *not* the build otpion --with-sysroot) or at at least -isysroot options with > Cygwin gcc/g++ 3.4.4, but it either seems to ignore the flags altogether or > cause cc1 to consume 100% CPU and somehow wedge. The --sysroot option was added in gcc 4.1, so this will never work. You can find this for yourself by looking at the Options Index in the manual. The website conveniently has the manual for each release branch as well as HEAD online: . > The only thing I've found > that works is to use a combination of PATH, -B, -nostdinc and a whole long > list of -I options to make sure my secondary install doesn't use any of the > default system headers and binutils installed in the master Cygwin > environment. That sounds horrendously ugly and fragile. The way that I would try to relocate a compiler is by rebuilding it with a different --prefix as Dave already suggested. Be sure if you do this that you use the patched sources, as there are a fair number of cygming local patches not in upstream. However, it seems you also want it to not even consider /usr/include and /usr/lib (or for the case of -mno-cygwin it's actually /usr/include/mingw and /usr/lib/mingw) and instead use a different tree alltogether. That is going to take a lot more work, and just changing --prefix won't do it. I'm not even sure it's possible to build a native compiler that does not consider /usr/{include,lib} without doing what you've done already: specify -nostdlib plus -B and a bunch of -L and -I. In regard to binutils, you can achieve separation there relatively easily just by manipulating the PATH so that the desired 'as' and 'ld' (themselves build with the alternative --prefix) come first. But binutils separation would be the least of my worries, since there's not a lot there that could change in a way as to break anything. Here again I'm going to suggest simply using the MinGW toolchain, either with a wrapper script or MSYS. The reason? Since MinGW gcc is a native app there is no mount table and thus no concept of what "/usr/include" or "/usr/lib" even means, so MinGW gcc does all its location of paths relative to the base directory that gcc is installed in. Therefore you can unpack {gcc,binutils,mingw-runtime,w32api} into any directory and without even having to touch PATH, you know that any binary invoked from that tree will use and find everything rooted below that tree. > Can someone offer any pointers on an easier way to get this working? I've > been having a hard time telling from the gcc web site and change notes when > --sysroot made it into the tool chain. It's possible --sysroot didn't get in > until gcc 4.x sometime, but -isysroot I believe definitely should be working > in 3.4. -isysroot seems to be a 4.1 feature too, based on the manuals. > I guess what I would really like is a version of the MinGW compiler tools > that understand Cygwin paths. Is there such a beast? As above, it's called MSYS. > As an aside, is object code and libraries generated by MinGW gcc/g++ 3.4.2 > (the latest stable release, I believe) fully compatible with Cygwin's > gcc/g++ 3.4.4 code generated in -mno-cygwin? It's marked candidate, but MinGW gcc 3.4.5 is the latest and is now 17 months old, so I think you're doing yourself a disservice by not using it. I'd call it stable, and it fixes known bugs in 3.4.2 which is nearly three years old! In general any gcc x.y.a->b point release is typically binary compatible, so 3.4.2 and 3.4.5 should be fine. However, in the specific case of MinGW that is not the case and .2 and .5 are binary incompatible as explained here: In the case of using Cygwin's gcc -mno-cygwin you're in a bit of a strange spot, as you are not technically using the MinGW binaries (note that /usr/lib/gcc/i686-pc-mingw32/?.?.?/*.exe are symlinks) so it depends on the patchset included with the Cygwin gcc release. I'm fairly sure the Cygwin gcc 3.4.4 release contains the correct shared_ptr patch that Danny talks about above, meaning it would be binary compatible with MinGW 3.4.5 but not 3.4.2. But you'd have to compare the patchsets between the two to confirm this. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/