On Mar 14 10:53, NightStrike wrote:
> On Thu, Mar 14, 2013 at 5:13 AM, Corinna Vinschen <[email protected]> wrote:
> > On Mar 13 16:18, NightStrike wrote:
> >> On Wed, Mar 13, 2013 at 7:22 AM, Corinna Vinschen <[email protected]> 
> >> wrote:
> >> > Hi,
> >> >
> >> > I'd like to resurrect a patch which has been refused last year, but
> >> > I think it's still helpful and maybe the opinions have changed a bit.
> >>
> >> Sorry.. did I refuse it?  Can you link to the mailing list archive (I
> >> understand that the SF interface blows for that...)
> 
> No link?  I tried to find it and could not.

Do we really need that?  I didn't keep a local copy and searching the
ML archive sucks.

> >> I'm a little confused here.  What we require, ie, the only situation
> >> that we support, is when the version of the headers is the same
> >> version of the crt.  Ie, svn checkout revision.  Anything outside of
> >> that will probably work, of course, but nobody tests it.
> >
> > Sure, I'm not claiming anything else, nor am I trying to do anything
> > else.  I want to build a full mingw tree, without having to have
> > anything installed outside the source or build tree.
> 
> When you say "full mingw tree", do you mean that you are building crt,
> headers, and tools using the top level configure/make, as opposed to
> building each thing you want independently?

Exactly.  Doing that is a fairly typical scenario, isn't it?

> >> Now, in terms of the configure test that errors out in the case of not
> >> finding _mingw_mac.h, that is due to the fact that the headers are
> >> required to build the crt.  We don't care where they are, we just care
> >> that they exist.  If they don't, the crt build will be all fouled up.
> >
> > I'm puzzeled.  That has nothing to do with my patch.
> 
> Your patch changed when it errored out.

Sorry?  When did my patch change?  When did it error out?  I realy don't
understand what you're talking about.

> >> The default, of course, is for the headers to exist in the sysroot
> >> that the crt is getting installed into.  This is a fairly common usage
> >> pattern, and modeled after the gcc build.  If they're somewhere else
> >> instead, you can just use --with-sysroot=some/wheres/else
> >>
> >> In fact, the help text for with-sysroot even says this:
> >>      --with-sysroot=DIR       Search for headers within DIR/include
> >>
> >> So if you for whatever reason want to stage a build of
> >> mingw-w64-headers in /tmp/my/dir, you just build the crt with
> >> --with-sysroot=/tmp/my/dir
> >>
> >> Does that not work for you?
> >
> > Sorry, but I'm really confused about the unnecessary complexity.  I don't
> > want to "stage" anything.  I would like to be able call
> >
> >   configure --prefix=...
> >   make
> >   make install
> 
> Which configure are we talking about in all of this?  I thought you
> were always asking about the crt configure, but I'm getting the
> feeling that you're really asking about the top level configure.

The crt configurey needs a change to be able to build a full mingw
tree from top level.  I thought that was clear.  Only building crt
without the headers makes only marginal sense.  My below example
shows that:

> > That's a pretty standard scenario.  But here's what happens: Try to
> > build a full set of headers and libs for a Cygwin target:
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> >
> >   ${srcdir}/configure \
> >     --host=x86_64-w64-mingw32 \
> >     --prefix=/home/corinna/mingw \
> >     --enable-w32api
> >
> > As common as it looks, the build will fail:
> >
> >   x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H \
> >     -I. \
> >     -I${srcdir}/mingw-w64-crt  \
> >     -m32 \
> >     -I/home/corinna/mingw64/include   \
> >     [...] -g -O2 [...] \
> >     -c -o libsrc/lib32_libwmcodecdspuuid_a-wmcodecdspuuid.o \
> >     [...]/wmcodecdspuuid.c
> >   ${srcdir}/mingw-w64-crt/libsrc/wmcodecdspuuid.c:8:24: fatal error: 
> > wmcodecdsp.h: No such file or directory
> >   compilation terminated.
> >
> > The reason is obvious.  The -I don't include the headers within the
> > same src tree, and they don't contain the generated headers within
> > the same build tree *even though thay are available*.
> >
> > It simply doesn't make sense to require having a copy of these headers
> > installed to some arbitrary sysroot dir, just to be able to build crt.

Corinna

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to