public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Brian Dessent <brian@dessent.net>
To: gcc-help@gcc.gnu.org
Cc: Sebastian Ebenbeck <seb@work-gmbh.de>
Subject: Re: Cross Compiler Host MinGW Target PowerPC
Date: Mon, 20 Nov 2006 11:57:00 -0000	[thread overview]
Message-ID: <45619828.55BF5D8E@dessent.net> (raw)
In-Reply-To: <456193F9.99DF4C1F@dessent.net>

Brian Dessent wrote:

> > I have read some good informations in the Web and use now a combined
> > build tree.
> > So I am able to compile the GCC in Linux now!
> > Today I tried the same procedure in MinGW and fail.
> 
> You need to provide more information.  What *exact* configure command
> are you using, specifically what are you providing for --host, --build,
> --target, and --prefix?  What is the build host, MSYS or Cygwin?  Are
> you providing a relative path to the location of configure or an
> absolute path?
> 
> > build/gengtype.exe
> > /home/seb/combined/gcc/input.h: No such file or directory
> 
> Here it looks like you have a mingw program trying to access posix
> paths.  That won't work, mingw programs need to use win32 paths.

Just to clarify, the reason that MinGW can be a difficult host is
because the build tools (MSYS) understand posix paths but native MinGW
binaries do not.  This means that you have to be careful that all paths
that are compiled into binaries/headers (such as in specs or the build
helper programs like gengtype) are either relative paths or win32 paths
(c:/foo/bar).

In the case above it looks like you've got a gengtype.exe that
apparently got a posix-style absolute path leaked into it somewhere.  So
you have to ensure that the $srcdir, $builddir, $prefix etc. in the
Makefile end up as either relative paths or win32 paths.  $srcdir gets
set based on the path used to invoke configure, which is why the
particulars of how you do this can matter greatly on MinGW.

It would be a lot easier to instead use Cygwin as the host for a cross
compiler because you don't have to worry about any of this, as all
Cygwin binaries understand posix paths so there is none of this
"cognitive dissonance" between the build system and the actual binaries.

Brian

  reply	other threads:[~2006-11-20 11:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-10 15:26 Sebastian Ebenbeck
2006-11-10 15:48 ` John Love-Jensen
2006-11-20 11:04   ` Sebastian Ebenbeck
2006-11-20 11:39     ` Brian Dessent
2006-11-20 11:57       ` Brian Dessent [this message]
2006-11-20 13:35         ` Kai Ruottu
2006-11-20 14:39         ` Sebastian Ebenbeck
2006-11-21 11:42           ` Brian Dessent
2006-11-21 12:05             ` Brian Dessent
2006-11-21 11:01         ` Sebastian Ebenbeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45619828.55BF5D8E@dessent.net \
    --to=brian@dessent.net \
    --cc=gcc-help@gcc.gnu.org \
    --cc=seb@work-gmbh.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).