| Message ID | 1478002070-26676-1-git-send-email-rth@twiddle.net |
|---|---|
| State | New |
| Headers | show |
On 1 November 2016 at 12:07, Richard Henderson <rth@twiddle.net> wrote: > V2, now with more windows workarounds. I'll note that I have not > been 100% successful in actually building a mingw64 image. But > at least the error Peter saw with v1 is fixed. > > I'll report on the other mingw64 failures under separate cover. > > > r~ > > > > The following changes since commit e80b4b8fb6babce7dcc91ea9ddeecbc351fd4646: > > Merge remote-tracking branch 'remotes/awilliam/tags/vfio-updates-20161031.0' into staging (2016-10-31 18:19:06 +0000) > > are available in the git repository at: > > git://github.com/rth7680/qemu.git tags/pull-tcg-20161101 > > for you to fetch changes up to 13110e2d41d0b9d77edea5b23e1a808c86eb22cb: > > tcg: correct 32-bit tcg_gen_ld8s_i64 sign-extension (2016-10-31 21:36:29 -0600) > > ---------------------------------------------------------------- > tcg queued patches i686-w64-mingw32 builds fail to link :-( exec.o: In function `qemu_flockfile': /home/petmay01/linaro/qemu-for-merges/include/sysemu/os-win32.h:110: undefined reference to `_imp___lock_file' exec.o: In function `qemu_funlockfile': /home/petmay01/linaro/qemu-for-merges/include/sysemu/os-win32.h:115: undefined reference to `_imp___unlock_file' (repeated a lot of times) thanks -- PMM
On 11/01/2016 06:07 AM, Richard Henderson wrote: > V2, now with more windows workarounds. I'll note that I have not > been 100% successful in actually building a mingw64 image. But > at least the error Peter saw with v1 is fixed. > > I'll report on the other mingw64 failures under separate cover. Bah. I think I've been tripped up by the fact that we fail to preserve PKG_CONFIG_PATH when re-running configure via make. We really should finally fix that -- it's really really annoying when building a non-default config. r~
On 1 November 2016 at 15:34, Richard Henderson <rth@twiddle.net> wrote: > Bah. I think I've been tripped up by the fact that we fail to preserve > PKG_CONFIG_PATH when re-running configure via make. We really should > finally fix that -- it's really really annoying when building a non-default > config. FWIW this doesn't bite me because I use configure --cross-prefix=i686-w64-mingw32- and then configure runs i686-w64-mingw32-pkg-config, which is a wrapper script that gets the PKG_CONFIG_LIBDIR right. thanks -- PMM
On Tue, Nov 01, 2016 at 09:34:24AM -0600, Richard Henderson wrote: > On 11/01/2016 06:07 AM, Richard Henderson wrote: > > V2, now with more windows workarounds. I'll note that I have not > > been 100% successful in actually building a mingw64 image. But > > at least the error Peter saw with v1 is fixed. > > > > I'll report on the other mingw64 failures under separate cover. > > Bah. I think I've been tripped up by the fact that we fail to preserve > PKG_CONFIG_PATH when re-running configure via make. We really should > finally fix that -- it's really really annoying when building a non-default > config. I sent a fix for this issue last year, but it never got picked up by anyone for merge https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg04074.html Regards, Daniel
On 1 November 2016 at 16:20, Daniel P. Berrange <berrange@redhat.com> wrote: > On Tue, Nov 01, 2016 at 09:34:24AM -0600, Richard Henderson wrote: >> On 11/01/2016 06:07 AM, Richard Henderson wrote: >> > V2, now with more windows workarounds. I'll note that I have not >> > been 100% successful in actually building a mingw64 image. But >> > at least the error Peter saw with v1 is fixed. >> > >> > I'll report on the other mingw64 failures under separate cover. >> >> Bah. I think I've been tripped up by the fact that we fail to preserve >> PKG_CONFIG_PATH when re-running configure via make. We really should >> finally fix that -- it's really really annoying when building a non-default >> config. > > I sent a fix for this issue last year, but it never got picked up > by anyone for merge > > https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg04074.html Hmm, that's a lot of random environment variables. I think I prefer the approach of "if you care about anything in the environment, pass it to both configure and to make". For instance we don't pass PATH from configure to make, so with that patch we would have the opposite behaviour, that make can run configure (which will get the saved PATH from config.status) but then make itself runs with a different PATH. That seems awkwardly inconsistent. thanks -- PMM
On 11/01/2016 08:26 AM, Peter Maydell wrote: > i686-w64-mingw32 builds fail to link :-( > > exec.o: In function `qemu_flockfile': > /home/petmay01/linaro/qemu-for-merges/include/sysemu/os-win32.h:110: > undefined reference to `_imp___lock_file' > exec.o: In function `qemu_funlockfile': > /home/petmay01/linaro/qemu-for-merges/include/sysemu/os-win32.h:115: I see the symbols present in libmsvcrt.a. I wonder why it isn't being seen. Oh well. I'm going to simply disable file locking for mingw32 and let someone who cares deal with it later. The situation with logging is no worse than before the patch. r~
On Tue, Nov 01, 2016 at 04:26:57PM +0000, Peter Maydell wrote: > On 1 November 2016 at 16:20, Daniel P. Berrange <berrange@redhat.com> wrote: > > On Tue, Nov 01, 2016 at 09:34:24AM -0600, Richard Henderson wrote: > >> On 11/01/2016 06:07 AM, Richard Henderson wrote: > >> > V2, now with more windows workarounds. I'll note that I have not > >> > been 100% successful in actually building a mingw64 image. But > >> > at least the error Peter saw with v1 is fixed. > >> > > >> > I'll report on the other mingw64 failures under separate cover. > >> > >> Bah. I think I've been tripped up by the fact that we fail to preserve > >> PKG_CONFIG_PATH when re-running configure via make. We really should > >> finally fix that -- it's really really annoying when building a non-default > >> config. > > > > I sent a fix for this issue last year, but it never got picked up > > by anyone for merge > > > > https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg04074.html > > Hmm, that's a lot of random environment variables. > I think I prefer the approach of "if you care about anything > in the environment, pass it to both configure and to make". > For instance we don't pass PATH from configure to make, so > with that patch we would have the opposite behaviour, that > make can run configure (which will get the saved PATH from > config.status) but then make itself runs with a different PATH. > That seems awkwardly inconsistent. Yeah, it is akward - I was coming at it from an autotools perspective where the generated Makefile tends to get variables added for each tool used, containing the fully qualified path. eg so 'make' ends up running '/usr/bin/sed' instead of just 'sed', and so 'make' is not dependant on stuff in your env like $PATH - it mostly honours the env that was set at time of configure. Of course QEMU is not using autotools, so this doesn't map exactly hence the inconsistency you point out. Personally the idea that you must explicitly pass the same environment to both configure & make is kind of hard to guarantee - I'll have many terminal windows open when working on QEMU and I can't have any confidence that the env seen by 'make' will exactly match what I used with 'configure' (which may have been run quite some time earlier - hours or even days). It was a particular pain-point for me when doing mingw builds, where I would typically use 'PKG_CONFIG_PATH=/blah ./configure' so that I didn't permanently pollute my shell with mingw32 pkg-config env Regards, Daniel
On 11/01/2016 11:43 AM, Daniel P. Berrange wrote: > It was a particular pain-point for me when doing mingw builds, where > I would typically use 'PKG_CONFIG_PATH=/blah ./configure' so that I > didn't permanently pollute my shell with mingw32 pkg-config env The usual pain point for me is building for 32-bit on a 64-bit system, where there is no cross-prefix that one can use, and PKG_CONFIG_PATH and --extra-cflags are the only changes. r~
On 1 November 2016 at 17:51, Richard Henderson <rth@twiddle.net> wrote: > The usual pain point for me is building for 32-bit on a 64-bit > system, where there is no cross-prefix that one can use, and > PKG_CONFIG_PATH and --extra-cflags are the only changes. That sounds like a bug in how the 32-bit compilers work on x86 ;-) Ideally you should be able to get a 32-bit compile with i586-linux-gnu-gcc... thanks -- PMM
On 11/01/2016 12:17 PM, Peter Maydell wrote: > On 1 November 2016 at 17:51, Richard Henderson <rth@twiddle.net> wrote: >> The usual pain point for me is building for 32-bit on a 64-bit >> system, where there is no cross-prefix that one can use, and >> PKG_CONFIG_PATH and --extra-cflags are the only changes. > > That sounds like a bug in how the 32-bit compilers work on > x86 ;-) Ideally you should be able to get a 32-bit compile > with i586-linux-gnu-gcc... gcc -m32 worked very well for years, before pkg-config came along and mucked things up by using package-local include and library directories. As long as everything was installed in the toolchain-aware search paths, everything Just Worked. r~
On 1 November 2016 at 19:21, Richard Henderson <rth@twiddle.net> wrote: > On 11/01/2016 12:17 PM, Peter Maydell wrote: >> On 1 November 2016 at 17:51, Richard Henderson <rth@twiddle.net> wrote: >>> >>> The usual pain point for me is building for 32-bit on a 64-bit >>> system, where there is no cross-prefix that one can use, and >>> PKG_CONFIG_PATH and --extra-cflags are the only changes. >> >> >> That sounds like a bug in how the 32-bit compilers work on >> x86 ;-) Ideally you should be able to get a 32-bit compile >> with i586-linux-gnu-gcc... > gcc -m32 worked very well for years, before pkg-config > came along and mucked things up by using package-local > include and library directories. As long as everything > was installed in the toolchain-aware search paths, everything > Just Worked. -m32 doesn't extend to anything other than the 32-bit/64-bit special case, though, and pkg-config does more than just tell you include paths. thanks -- PMM
V2, now with more windows workarounds. I'll note that I have not been 100% successful in actually building a mingw64 image. But at least the error Peter saw with v1 is fixed. I'll report on the other mingw64 failures under separate cover. r~ The following changes since commit e80b4b8fb6babce7dcc91ea9ddeecbc351fd4646: Merge remote-tracking branch 'remotes/awilliam/tags/vfio-updates-20161031.0' into staging (2016-10-31 18:19:06 +0000) are available in the git repository at: git://github.com/rth7680/qemu.git tags/pull-tcg-20161101 for you to fetch changes up to 13110e2d41d0b9d77edea5b23e1a808c86eb22cb: tcg: correct 32-bit tcg_gen_ld8s_i64 sign-extension (2016-10-31 21:36:29 -0600) ---------------------------------------------------------------- tcg queued patches ---------------------------------------------------------------- Joseph Myers (1): tcg: correct 32-bit tcg_gen_ld8s_i64 sign-extension Peter Maydell (1): tcg/tcg.h: Improve documentation of TCGv_i32 etc types Pranith Kumar (1): MAINTAINERS: Update PPC status and maintainer Richard Henderson (6): target-cris: Do not dump cpu state with -d in_asm target-microblaze: Do not dump cpu state with -d in_asm target-openrisc: Do not dump cpu state with -d in_asm log: Add locking to large logging blocks tcg: Add tcg_gen_mulsu2_{i32,i64,tl} target-microblaze: Cleanup dec_mul MAINTAINERS | 4 +-- cpu-exec.c | 2 ++ exec.c | 2 ++ include/qemu/log.h | 16 ++++++++++ include/sysemu/os-posix.h | 12 ++++++++ include/sysemu/os-win32.h | 11 +++++++ target-alpha/translate.c | 2 ++ target-arm/translate-a64.c | 2 ++ target-arm/translate.c | 2 ++ target-cris/translate.c | 27 +++------------- target-i386/translate.c | 4 +++ target-lm32/translate.c | 2 ++ target-m68k/translate.c | 2 ++ target-microblaze/translate.c | 72 ++++++++----------------------------------- target-mips/translate.c | 2 ++ target-openrisc/translate.c | 9 +++--- target-ppc/translate.c | 2 ++ target-s390x/translate.c | 2 ++ target-sh4/translate.c | 2 ++ target-sparc/translate.c | 2 ++ target-tilegx/translate.c | 6 +++- target-tricore/translate.c | 2 ++ target-unicore32/translate.c | 2 ++ target-xtensa/translate.c | 2 ++ tcg/tcg-op.c | 45 ++++++++++++++++++++++++++- tcg/tcg-op.h | 4 +++ tcg/tcg.c | 8 +++++ tcg/tcg.h | 38 ++++++++++++++++++----- translate-all.c | 2 ++ 29 files changed, 188 insertions(+), 100 deletions(-)