This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Brian Dessent wrote:

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

I forgot to mention that an alternative would be to build gcc as a cross
(i.e. --host=i686-pc-cygwin --build=i686-pc-cygwin
--target=i686-pc-mingw32) and use --with-sysroot to give the location of
the desired isolated copy of the headers/libs.  That should produce
something that both understands POSIX paths and doesn't look at native
headers.  You'd invoke it as i686-pc-mingw32-gcc without -mno-cygwin,
which fits more gracefully into the autoconf world, as you just
configure for a standard cross compile, e.g. "configure
--host=i686-pc-mingw32" and it should find and use i686-pc-mingw32-gcc
et al.

The problem then becomes that since you are essentially cross compiling
everything you run into configure scripts that weren't designed to work
in cross environments, typically by requiring execute tests instead of
just compile or link tests.  You can generally work around this by
either preloading the cache for such values (e.g. "configure ...
cv_foo_bar=yes") or otherwise just faking the build system into actually
running the test.  Most larger libraries should support cross
compilation, so it's only the smaller or less well-tested ones that
you'd have to worry about.

Yet another workaround, which to my eyes is even yet uglier, is telling
autoconf you're doing a native build but using the cross-gcc, e.g.

configure CC="i686-pc-mingw32-gcc" CXX="i686-pc-mingw32-g++"

I suppose this is no more ugly than what you're doing now by adding
-mno-cygwin to CFLAGS, since "gcc -mno-cygwin" is roughly the same in
concept as a cross compiler only the results are still executable on the


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]