Re: Using a secondary install of gcc/g++ binutils

[Brian Dessent <brian at dessent dot net>]

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: <http://gcc.gnu.org/onlinedocs/>.

> 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:
<http://article.gmane.org/gmane.comp.gnu.mingw.user/22574>

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/