Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
Hi, On Mar 15 16:14, Corinna Vinschen wrote: On Mar 15 06:09, JonY wrote: On 3/14/2013 23:52, Corinna Vinschen wrote: What two build systems? It's a fairly simple patch which allows the normal user of mingw64 to build the entire source tree in a single `configure; make; make install', nothing more, nothing less. I don't understand why the unnecessary complicated 2-stage process is enforced. After having some proper sleep and looking at your patch again, I can see what you are trying to do. Please keep the changes to the top level configure, pass the -I arguments to the lower levels. None of the lower modules have any business getting too familiar with each other. I think NightStrike is already looking into this, so I shut up for now. Feel free to ping me if I I'm supposed to do something in this matter. Is there some progress in this matter, which allows to build the headers and crt in a single configure/make run? Just asking... Thanks, Corinna -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
On Fri, Mar 15, 2013 at 12:55 AM, John E. / TDM tdra...@tdragon.net wrote: On 3/14/2013 8:54 PM, NightStrike wrote: On Thu, Mar 14, 2013 at 4:22 PM, John E. / TDM tdra...@tdragon.net wrote: $(RUNTIME_SRC)/configure --build=x86_64-w64-mingw32 --enable-lib32 --enable-sdk=all --with-libraries=libmangle --with-tools=all --prefix=$(RUNTIME_STAGE) make make install If GCC or mingw-w64 introduce ABI-breaking changes (this happens often), I build a non-bootstrap GCC first in order to run this top-level mingw-w64 build before bootstrapping; otherwise I use the bootstrapped GCC. So no headers? IIUC, it's only the headers package that is screwing up. The headers seem to get built along with all the other subtrees... ? Curious... when configuring the crt, which headers is it checking for _mingw_mac.h? The soon-to-be-built ones, or the already-installed-as-part-of-the-toolchain ones? Similarly, which is it compiling against? -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
On Mar 15 06:09, JonY wrote: On 3/14/2013 23:52, Corinna Vinschen wrote: What two build systems? It's a fairly simple patch which allows the normal user of mingw64 to build the entire source tree in a single `configure; make; make install', nothing more, nothing less. I don't understand why the unnecessary complicated 2-stage process is enforced. After having some proper sleep and looking at your patch again, I can see what you are trying to do. Please keep the changes to the top level configure, pass the -I arguments to the lower levels. None of the lower modules have any business getting too familiar with each other. I think NightStrike is already looking into this, so I shut up for now. Feel free to ping me if I I'm supposed to do something in this matter. 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
On 3/15/2013 22:14, NightStrike wrote: Curious... when configuring the crt, which headers is it checking for _mingw_mac.h? The soon-to-be-built ones, or the already-installed-as-part-of-the-toolchain ones? Similarly, which is it compiling against? It is a sanity check, to make sure we are really building against mingw-w64 headers, not Linux headers nor mingw.org headers. signature.asc Description: OpenPGP digital signature -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
On 3/15/2013 8:14 AM, NightStrike wrote: On Fri, Mar 15, 2013 at 12:55 AM, John E. / TDM tdra...@tdragon.net wrote: The headers seem to get built along with all the other subtrees... ? Curious... when configuring the crt, which headers is it checking for _mingw_mac.h? The soon-to-be-built ones, or the already-installed-as-part-of-the-toolchain ones? Similarly, which is it compiling against? I haven't ever dug into the mingw-w64 build system to be able to answer these questions -- it's always worked, so I haven't worried about it. -John E. / TDM -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
On Fri, Mar 15, 2013 at 3:24 PM, John E. / TDM tdra...@tdragon.net wrote: On 3/15/2013 8:14 AM, NightStrike wrote: On Fri, Mar 15, 2013 at 12:55 AM, John E. / TDM tdra...@tdragon.net wrote: The headers seem to get built along with all the other subtrees... ? Curious... when configuring the crt, which headers is it checking for _mingw_mac.h? The soon-to-be-built ones, or the already-installed-as-part-of-the-toolchain ones? Similarly, which is it compiling against? I haven't ever dug into the mingw-w64 build system to be able to answer these questions -- it's always worked, so I haven't worried about it. I have a hunch that it's working because you are building mingw-w64 with mingw-w64. If you did it with, say, mingw.org, it'd probably fail... which means, it's taking the files from the build compiler to jimmy the tests. -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 13.03.2013 21:18, schrieb NightStrike: On Wed, Mar 13, 2013 at 7:22 AM, Corinna Vinschen vinsc...@redhat.com 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...) For people building just the latest mingw64-headers and mingw64-crt, it's kind of surprising that mingw64-crt requires that the headers are already installed. In theory, the right thing to do should be that mingw64-crt is build after mingw64-headers, and then prefer the just built in-tree headers over the already installed headers. 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. 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. 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 I just kick in because Corrina is completly right. A common case as for me, is to update the mingw-w64 runtime for an existing installation. So what you want, is to compile the runtime in one go, configue, make, make install. That's impossible for now. At the moment you have to install the headers first and afterwards you are able to build and install the runtime. For me that work as so: mkdir build cd build ../mingw-w64/configure cd mingw-w64-headers make make install cd .. ../mingw-w64/configure make make install That's not how it should work. The ming-w64 package includes all what is neccessary to build. You don't need already installed headers. This requirement is wrong! You only have to make sure to use the headers included in the package. That's as with any other software package. Really no package I know of requires to install the package headers first to build the package. 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 That's not the point see above. Even here you have to install the headers first. Cheers Rainer Does that not work for you? The below patch does that, unless the --without-headers option is set. This should work in all typical scenarios: - cross build gcc: The headers have to be build first. At the time crt gets build, the in-tree headers already have been built for gcc, so they are nicely available for the crt build. - native build gcc: The installed headers are potentially old. Building crt with the latest in-tree headers is preferrable to circumnavigate potential bugs in the older headers. - native mingw-only build: Same as above. I can't come up with a scenario in which it would be bad to use the in-tree headers, unless you don't build the headers, but crt only. This should be fixable, shouldn't it? -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRQY+WAAoJEB3HOsWs+KJb+hMH/3uwtbVoSvwXo5mlSoFxDaRG R/Suh2GdILBIIX2raque/ZSFgUItcvvrSDulStvvyEk0dCBRn6wq3lijuu87a9U2 NCrLuSfmebrxYYSwFJdVDldCEYvNzefAL8PyUWWXWjVR5OR4qGcooE3CrgbG5Dja 7cgKc6/oURyIyFsFCe5l000D6gjGmFe2KwAwbUBY3WgwWwHVvyonJ6ZJV/nqoQL2 EltzBDBZE5MUMIRQQtwHzYtSc2wVmz5u14js8Iuhtp998q2oqV8OE8q+vnQxj6yU mjUHaOick/tJ88zkuCIzmSdbee+stzHT51YWJtV4XEnScr44yXV9Ectk3F5Ywds= =pH0D -END PGP SIGNATURE- -- 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 Mingw-w64-public@lists.sourceforge.net
Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
On Mar 14 10:13, Corinna Vinschen wrote:
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
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 \
That should have been --prefix=/home/corinna/mingw64 to match the below
error message. Sorry.
--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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
On 3/14/2013 16:51, Rainer Emrich wrote: I just kick in because Corrina is completly right. A common case as for me, is to update the mingw-w64 runtime for an existing installation. So what you want, is to compile the runtime in one go, configue, make, make install. That's impossible for now. At the moment you have to install the headers first and afterwards you are able to build and install the runtime. For me that work as so: mkdir build cd build ../mingw-w64/configure cd mingw-w64-headers make make install cd .. ../mingw-w64/configure make make install That's not how it should work. The ming-w64 package includes all what is neccessary to build. You don't need already installed headers. This requirement is wrong! You only have to make sure to use the headers included in the package. That's as with any other software package. Really no package I know of requires to install the package headers first to build the package. You *have* to install the headers first as a prerequisite for the crt to work. There are generated headers required for the CRT, not a plain and simple -I. You do NOT need to use the top level configure. The more I think of it, the more I think it was a bad idea. signature.asc Description: OpenPGP digital signature -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 14.03.2013 10:37, schrieb JonY: On 3/14/2013 16:51, Rainer Emrich wrote: I just kick in because Corrina is completly right. A common case as for me, is to update the mingw-w64 runtime for an existing installation. So what you want, is to compile the runtime in one go, configue, make, make install. That's impossible for now. At the moment you have to install the headers first and afterwards you are able to build and install the runtime. For me that work as so: mkdir build cd build ../mingw-w64/configure cd mingw-w64-headers make make install cd .. ../mingw-w64/configure make make install That's not how it should work. The ming-w64 package includes all what is neccessary to build. You don't need already installed headers. This requirement is wrong! You only have to make sure to use the headers included in the package. That's as with any other software package. Really no package I know of requires to install the package headers first to build the package. You *have* to install the headers first as a prerequisite for the crt to work. There are generated headers required for the CRT, not a plain and simple -I. No, that's wrong! The build machinery has to be smart to take this into account. Even if you use generated headers, you don't need to install the headers first. Eventually you have to build the generated headers before you configure the runtime. But after that the right include path should do. You do NOT need to use the top level configure. The more I think of it, the more I think it was a bad idea. No, that's the way it should work. But has to be improved. Maybe you have to call the configure script for the crt from within the toplevel make. I don't have the time to propose any patches for this issue at the moment, but I'm sure that's feasible. Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRQZ8BAAoJEB3HOsWs+KJb8xoH/0K7DZ6HWohg10uQgTaLCJ1G mVdcezVs35NByqaP1RCpOK+zy1zeWLbLE5UdN5i4qDwsCQ/eGGX2R5a2qo6n9rox eDV8DKo70rgmyuR4Lp7CJCCJhxQLVUZEMATqIUcQxNj0uFyWesUlmHx5RpGKmsF4 inEW1I6BUsXpELukeJ98a+gvs4l7u8w98hrpKho39uErSOAgcXezoH6cfxUPkExq F4f5Rm8B8HXZNqXzi7DdkFjFFCys+7P2b6KTo/boKQbwKWAPujtDu79v4/ZclvS/ 9N8WRTVbXyMRTY6haTagPn2HE5BZwQHg4zz3gtK21I+VNcsjLEbAIfQuf1wMuz0= =kXE/ -END PGP SIGNATURE- -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
On Mar 14 11:13, m...@morous.org wrote: You *have* to install the headers first as a prerequisite for the crt to work. There are generated headers required for the CRT, not a plain and simple -I. Many packages generate headers or some sources. Consider config.h.in - config.h as the most common case. I cannot see that as a reason for increased build complexity. There just implies one extra level of dependencies in (generated) Makefile. Exactly. Also, the just built headers *are* taken into account by my patch, because they are included as well. I don't see why we need a two stage build at all, if a one stage build can do the right thing out of the box. 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
2013/3/14 Corinna Vinschen vinsc...@redhat.com On Mar 14 11:13, m...@morous.org wrote: You *have* to install the headers first as a prerequisite for the crt to work. There are generated headers required for the CRT, not a plain and simple -I. Many packages generate headers or some sources. Consider config.h.in - config.h as the most common case. I cannot see that as a reason for increased build complexity. There just implies one extra level of dependencies in (generated) Makefile. Exactly. Also, the just built headers *are* taken into account by my patch, because they are included as well. I don't see why we need a two stage build at all, if a one stage build can do the right thing out of the box. The two stage build is only required to be possible in the case of building a Canadian Cross, in which the build sequence is headers,binutils+gcc-c,crt,gcc-all. But it is indeed not necessary at all when there's a preexisting gcc available. Ruben 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
On Thu, Mar 14, 2013 at 5:13 AM, Corinna Vinschen vinsc...@redhat.com wrote:
On Mar 13 16:18, NightStrike wrote:
On Wed, Mar 13, 2013 at 7:22 AM, Corinna Vinschen vinsc...@redhat.com
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.
For people building just the latest mingw64-headers and mingw64-crt,
it's kind of surprising that mingw64-crt requires that the headers
are already installed. In theory, the right thing to do should be
that mingw64-crt is build after mingw64-headers, and then prefer the
just built in-tree headers over the already installed headers.
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?
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.
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.
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
On Mar 14 10:53, NightStrike wrote:
On Thu, Mar 14, 2013 at 5:13 AM, Corinna Vinschen vinsc...@redhat.com wrote:
On Mar 13 16:18, NightStrike wrote:
On Wed, Mar 13, 2013 at 7:22 AM, Corinna Vinschen vinsc...@redhat.com
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
On 3/14/2013 18:41, Ruben Van Boxem wrote: 2013/3/14 Corinna Vinschen vinsc...@redhat.com On Mar 14 11:13, m...@morous.org wrote: You *have* to install the headers first as a prerequisite for the crt to work. There are generated headers required for the CRT, not a plain and simple -I. Many packages generate headers or some sources. Consider config.h.in - config.h as the most common case. I cannot see that as a reason for increased build complexity. There just implies one extra level of dependencies in (generated) Makefile. Some of the library headers are designed to overwrite default copies from mingw-w64-headers, not a simple config.h, eg winpthreads. Exactly. Also, the just built headers *are* taken into account by my patch, because they are included as well. I don't see why we need a two stage build at all, if a one stage build can do the right thing out of the box. I'm still not sure about saving a few keystrokes for convenience to justify the increased maintenance. Now you have *two* build systems to take care of. The two stage build is only required to be possible in the case of building a Canadian Cross, in which the build sequence is headers,binutils+gcc-c,crt,gcc-all. But it is indeed not necessary at all when there's a preexisting gcc available. Don't forget about doing a clean bootstrap with no cross gcc available. signature.asc Description: OpenPGP digital signature -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
On Thu, Mar 14, 2013 at 11:27 AM, Corinna Vinschen vinsc...@redhat.com wrote: On Mar 14 10:53, NightStrike wrote: On Thu, Mar 14, 2013 at 5:13 AM, Corinna Vinschen vinsc...@redhat.com wrote: On Mar 13 16:18, NightStrike wrote: On Wed, Mar 13, 2013 at 7:22 AM, Corinna Vinschen vinsc...@redhat.com 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 just thought maybe there was more enlightening discussion. 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? Actually, no. Pretty much nobody uses the top level configure. It was an idea that I had that nobody really wanted, and so it fell into disuse and doesn't really work (which I guess is what you are seeing). If you want top level configure to work again, give me some time and I'll work on it to make it useful. There's actually numerous problems with it, not just the hokiness of trying to stage a headers install. 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. Your patch moved the criteria for erroring out on the non-existence of mingw_mac.h: -AC_CHECK_HEADER([_mingw_mac.h], [], [AC_MSG_ERROR([Please check if the mingw-w64 header set and the build/host option are set properly.])]) +AS_CASE([$with_headers], + [yes],[], + [AC_CHECK_HEADER([_mingw_mac.h], + [], + [AC_MSG_ERROR([Please check if the mingw-w64 header set and the build/host option are set properly.])])]) After your patch, configure won't always verify that the headers are usable for building crt. 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: Well, it's clear now. Although note that until now, every user always does configure/make/install of headers and crt independently. Mostly because top level doesn't really work :) So at least now I understand your use case I'll look into it from a different perspective and see what I can see. -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
On 3/14/13 8:00 PM, NightStrike wrote: Pretty much nobody uses the top level configure. It was an idea that I had that nobody really wanted, and so it fell into disuse and doesn't really work (which I guess is what you are seeing). Personally I like the idea of top level configure, *but* the fact that it doesn't work is a reason I use it. Ideally, the scenario: ./configure make install-headers # ... GCC stuff ... make make install would be much cleaner than current solution IMHO. And it this scenario, Corinna's proposal to use in-tree headers seems a very much expected behavior. If you want top level configure to work again, give me some time and I'll work on it to make it useful. There's actually numerous problems with it, not just the hokiness of trying to stage a headers install. Yes, please :) Cheers, Jacek -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
On Mar 14 15:00, NightStrike wrote: On Thu, Mar 14, 2013 at 11:27 AM, Corinna Vinschen vinsc...@redhat.com wrote: On Mar 14 10:53, NightStrike wrote: On Thu, Mar 14, 2013 at 5:13 AM, Corinna Vinschen vinsc...@redhat.com wrote: On Mar 13 16:18, NightStrike wrote: On Wed, Mar 13, 2013 at 7:22 AM, Corinna Vinschen vinsc...@redhat.com wrote: 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? Actually, no. Pretty much nobody uses the top level configure. It was an idea that I had that nobody really wanted, and so it fell into disuse and doesn't really work (which I guess is what you are seeing). The top-level configure works excellent for creating the w32api installation, except for the missing header file paths. Your patch moved the criteria for erroring out on the non-existence of mingw_mac.h: -AC_CHECK_HEADER([_mingw_mac.h], [], [AC_MSG_ERROR([Please check if the mingw-w64 header set and the build/host option are set properly.])]) +AS_CASE([$with_headers], + [yes],[], + [AC_CHECK_HEADER([_mingw_mac.h], + [], + [AC_MSG_ERROR([Please check if the mingw-w64 header set and the build/host option are set properly.])])]) After your patch, configure won't always verify that the headers are usable for building crt. The criteria are pretty clear, so maybe I just didn't create the test correctly: - Either we're building a full tree with headers and crt, then the we don't need the test for _mingw_mac.h, because it will be created early enough while building the headers. - Or we're building a standalone crt, then the _mingw_mac.h test is ok. So, to get that right, the crt configure just needs to know if we're building with in-tree headers or not. I'd appreciate it very much if that could be done to allow an easy single-stage build of the full tree. 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
On 3/14/2013 23:52, Corinna Vinschen wrote: What two build systems? It's a fairly simple patch which allows the normal user of mingw64 to build the entire source tree in a single `configure; make; make install', nothing more, nothing less. I don't understand why the unnecessary complicated 2-stage process is enforced. After having some proper sleep and looking at your patch again, I can see what you are trying to do. Please keep the changes to the top level configure, pass the -I arguments to the lower levels. None of the lower modules have any business getting too familiar with each other. signature.asc Description: OpenPGP digital signature -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
On 3/14/2013 1:00 PM, NightStrike wrote: On Thu, Mar 14, 2013 at 11:27 AM, Corinna Vinschen vinsc...@redhat.com wrote: On Mar 14 10:53, NightStrike wrote: 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? Actually, no. Pretty much nobody uses the top level configure. It was an idea that I had that nobody really wanted, and so it fell into disuse and doesn't really work (which I guess is what you are seeing). If you want top level configure to work again, give me some time and I'll work on it to make it useful. There's actually numerous problems with it, not just the hokiness of trying to stage a headers install. Just to throw another data point out there, I use top-level configure for TDM-GCC (i.e. an x86_64-w64-mingw32 native bootstrap). It seems to work and is far easier than building each sub-tree individually. -John E. / TDM -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
On Thu, Mar 14, 2013 at 1:26 PM, John E. / TDM tdra...@tdragon.net wrote: On 3/14/2013 1:00 PM, NightStrike wrote: On Thu, Mar 14, 2013 at 11:27 AM, Corinna Vinschen vinsc...@redhat.com wrote: On Mar 14 10:53, NightStrike wrote: 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? Actually, no. Pretty much nobody uses the top level configure. It was an idea that I had that nobody really wanted, and so it fell into disuse and doesn't really work (which I guess is what you are seeing). If you want top level configure to work again, give me some time and I'll work on it to make it useful. There's actually numerous problems with it, not just the hokiness of trying to stage a headers install. Just to throw another data point out there, I use top-level configure for TDM-GCC (i.e. an x86_64-w64-mingw32 native bootstrap). It seems to work and is far easier than building each sub-tree individually. How do you use it? What I am finding is that there is a fundamental difference in how AC_CONFIG_SUBDIRS works, and how we would like it to work. Let's say we have two packages, p1 and p2. Both need to be configured, made and installed (c/m/i for short). Let's say further that we want to build p1 and p2 serially such that we would do c1/m1/i1 followed by c2/m2/i2. What AC_CONFIG_SUBDIRS does instead is c1/c2, m1/m2, i1/i2. This means that in the case of the headers/crt packages, we will be forcing all work on the headers to be done at configure time. Translation -- we can't actually build the headers. This is not ideal. Now, currently, we do a lot at configure time, but we do three things at build time: Create _mingw_directx.h Create _mingw_ddk.h (Optional) Run widl to convert from .widl to .h You could argue that those three things don't need to happen before you configure the crt, but currently, we don't have such a limitation in place. It's really not my place to create that limitation without input from the people working in those areas. I have no idea what's planned for the future (ie, a future situation where the dependency does exist.) I'm open to ideas. I'm also open to making the top level configury smarter. I looked at the gcc top level configury to see how that gets so smart. This works more like what I would expect -- serialize the c/m/i process for each sub package. It's also insanely complicated, and I guess hearkens back to what people used to call the cygnus tree. I am remembering now why I abandoned the top level idea :P That said, it does work pretty well for the libs and tools, which have no crazy dependencies. -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
On 3/14/2013 6:26 PM, NightStrike wrote: On Thu, Mar 14, 2013 at 1:26 PM, John E. / TDM tdra...@tdragon.net wrote: Just to throw another data point out there, I use top-level configure for TDM-GCC (i.e. an x86_64-w64-mingw32 native bootstrap). It seems to work and is far easier than building each sub-tree individually. How do you use it? $(RUNTIME_SRC)/configure --build=x86_64-w64-mingw32 --enable-lib32 --enable-sdk=all --with-libraries=libmangle --with-tools=all --prefix=$(RUNTIME_STAGE) make make install If GCC or mingw-w64 introduce ABI-breaking changes (this happens often), I build a non-bootstrap GCC first in order to run this top-level mingw-w64 build before bootstrapping; otherwise I use the bootstrapped GCC. -John E. / TDM -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
On Thu, Mar 14, 2013 at 4:22 PM, John E. / TDM tdra...@tdragon.net wrote: On 3/14/2013 6:26 PM, NightStrike wrote: On Thu, Mar 14, 2013 at 1:26 PM, John E. / TDM tdra...@tdragon.net wrote: Just to throw another data point out there, I use top-level configure for TDM-GCC (i.e. an x86_64-w64-mingw32 native bootstrap). It seems to work and is far easier than building each sub-tree individually. How do you use it? $(RUNTIME_SRC)/configure --build=x86_64-w64-mingw32 --enable-lib32 --enable-sdk=all --with-libraries=libmangle --with-tools=all --prefix=$(RUNTIME_STAGE) make make install If GCC or mingw-w64 introduce ABI-breaking changes (this happens often), I build a non-bootstrap GCC first in order to run this top-level mingw-w64 build before bootstrapping; otherwise I use the bootstrapped GCC. So no headers? IIUC, it's only the headers package that is screwing up. -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers
On Wed, Mar 13, 2013 at 7:22 AM, Corinna Vinschen vinsc...@redhat.com 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...) For people building just the latest mingw64-headers and mingw64-crt, it's kind of surprising that mingw64-crt requires that the headers are already installed. In theory, the right thing to do should be that mingw64-crt is build after mingw64-headers, and then prefer the just built in-tree headers over the already installed headers. 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. 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. 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? The below patch does that, unless the --without-headers option is set. This should work in all typical scenarios: - cross build gcc: The headers have to be build first. At the time crt gets build, the in-tree headers already have been built for gcc, so they are nicely available for the crt build. - native build gcc: The installed headers are potentially old. Building crt with the latest in-tree headers is preferrable to circumnavigate potential bugs in the older headers. - native mingw-only build: Same as above. I can't come up with a scenario in which it would be bad to use the in-tree headers, unless you don't build the headers, but crt only. This should be fixable, shouldn't it? -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
