Xen devel - Jul 2008 - [Patch] ioemu-remote: fix gcc4 build problem (?)

Ian,

although I read that the gcc4 build problem should already be fixed, I 
cannot ack this for me: I just did
$ git clone http://xenbits.xensource.com/git-http/qemu-xen-unstable.git 
and "$ hg pull -u" in xen-staging and still configure stops with
missing
gcc3. In ioemu-remote "git log" says the latest patch was:
----------
commit 1ec7aa3263bc7fd78bcc40e4ceb2ca067a1a8687
Author: Ian Jackson <iwj@mariner.uk.xensource.com>
Date:   Mon Jul 14 13:46:28 2008 +0100
     qemu ioemu rendering fixes for palette handling (another dropped patch)
.....
----------

If a fix is already submitted, it would be nice if someone could point 
me how keep my tree up-to-date.

Anyway now my version of the patch:
AFAIK the qemu gcc3 build restriction does not apply to ioemu, in the 
old embedded tree "check_gcc" was set to "no" per default in
tools/ioemu/configure. Either we do the same in the ioemu-remote tree or 
use the below patch to fix the shell test error (already in qemu since 
May 23rd: 
http://lists.gnu.org/archive/html/qemu-devel/2008-05/msg00875.html) and 
call configure with --disable-gcc-check (which is closer to the upstream 
qemu tree).

Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Original QEMU patch by Paul Brook

Regards,
Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 277-84917
----to satisfy European Law for business letters:
AMD Saxony Limited Liability Company & Co. KG,
Wilschdorfer Landstr. 101, 01109 Dresden, Germany
Register Court Dresden: HRA 4896, General Partner authorized
to represent: AMD Saxony LLC (Wilmington, Delaware, US)
General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Andre Przywara writes ("[Patch] ioemu-remote: fix gcc4 build problem
(?)"):
> although I read that the gcc4 build problem should already be fixed, I 
> cannot ack this for me: I just did
> $ git clone http://xenbits.xensource.com/git-http/qemu-xen-unstable.git 
> and "$ hg pull -u" in xen-staging and still configure stops with
missing
> gcc3. In ioemu-remote "git log" says the latest patch was:
It''s not clear to me in which directory you ran `git clone''
in.
There are two sensible ways to use the new tree:

Automatically checked out tree:
  ~:$ cd ~/work
  ~/work:$ hg clone .../xen-unstable.hg
  ~/work:$ cd xen-unstable.hg
  ~/work/xen-unstable.hg:$ make -j4
  [ build system runs hg clone ]
Then if you want to update ioemu-remote:
  ~/work/xen-unstable.hg:$ cd tools/ioemu-remote
  ~/work/xen-unstable.hg/tools/ioemu-remote:$ git pull
or
  ~/work/xen-unstable.hg/tools/ioemu-remote:$ git pull http://somewhere

Separate tree managed by you:
  ~:$ cd ~/work
  ~/work:$ hg clone .../xen-unstable.hg
  ~/work:$ git clone .../qemu-xen-unstable.git
  ~/work:$ cd xen-unstable.hg
  ~/work/xen-unstable.hg:$ CONFIG_QEMU=$HOME/work/qemu-xen-unstable make -j4 
  ...

Simply running
  git clone http://xenbits.xensource.com/git-http/qemu-xen-unstable.git 
isn''t really going to help, no matter where you run it.  That will
create a directory qemu-xen-unstable but you also need to make sure
the build system will use that directory.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

iwj writes ("Re: [Patch] ioemu-remote: fix gcc4 build problem
(?)"):
> Automatically checked out tree:
>   ~:$ cd ~/work
NB I constructed those `transcripts'' by hand so they may have small
errors.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Ian Jackson wrote:
> Andre Przywara writes ("[Patch] ioemu-remote: fix gcc4 build problem
(?)"):
>> although I read that the gcc4 build problem should already be fixed, I 
>> cannot ack this for me: I just did
>> $ git clone http://xenbits.xensource.com/git-http/qemu-xen-unstable.git
>> and "$ hg pull -u" in xen-staging and still configure stops
with missing
>> gcc3. In ioemu-remote "git log" says the latest patch was:
> 
> It''s not clear to me in which directory you ran `git
clone'' in.
 > There are two sensible ways to use the new tree:
> 
> Automatically checked out tree:
>   ~:$ cd ~/work
>   ~/work:$ hg clone .../xen-unstable.hg
>   ~/work:$ cd xen-unstable.hg
>   ~/work/xen-unstable.hg:$ make -j4
>   [ build system runs hg clone ]
You mean git clone here, right?
> Then if you want to update ioemu-remote:
>   ~/work/xen-unstable.hg:$ cd tools/ioemu-remote
>   ~/work/xen-unstable.hg/tools/ioemu-remote:$ git pull
> or
>   ~/work/xen-unstable.hg/tools/ioemu-remote:$ git pull http://somewhere
I tried these both version. It says I am up-to-date.
Then I just cloned the git tree externally to make sure I am not fooled 
by some obsolete remote path, broken updates or wrong caching etc. When 
doing so I assume I get the latest and greatest. But the tree is 
essentially the same as in tools/ioemu-remote.
What were the latest changes you submitted? What changeset should fix this?
> Separate tree managed by you:
>   ~:$ cd ~/work
>   ~/work:$ hg clone .../xen-unstable.hg
>   ~/work:$ git clone .../qemu-xen-unstable.git
>   ~/work:$ cd xen-unstable.hg
>   ~/work/xen-unstable.hg:$ CONFIG_QEMU=$HOME/work/qemu-xen-unstable make
-j4
>   ...
> 
> Simply running
>   git clone http://xenbits.xensource.com/git-http/qemu-xen-unstable.git 
> isn''t really going to help, no matter where you run it.  That will
> create a directory qemu-xen-unstable but you also need to make sure
> the build system will use that directory.
Sure. This was just a check to be sure.

Regards,
Andre.

BTW: What were the reasons to use git here? Isn''t that making the whole
building process more complicated (let alone forgotten updates due to a 
separate repository)?

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 277-84917
----to satisfy European Law for business letters:
AMD Saxony Limited Liability Company & Co. KG,
Wilschdorfer Landstr. 101, 01109 Dresden, Germany
Register Court Dresden: HRA 4896, General Partner authorized
to represent: AMD Saxony LLC (Wilmington, Delaware, US)
General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Andre Przywara writes ("Re: [Patch] ioemu-remote: fix gcc4 build problem
(?)"):
> I tried these both version. It says I am up-to-date.
How odd.  I have checked all of the locations you might be pulling
from and they are all current, and contain this as the current head:

    commit 30f00a0284a5ee356de6f6095e52173f2234145b
    Author: Ian Jackson <ian.jackson@eu.citrix.com>
    Date:   Fri Jul 18 16:02:23 2008 +0100

    hw/pass-through.c: pt_unregister_regions returns void
> BTW: What were the reasons to use git here? Isn''t that making the
whole
> building process more complicated (let alone forgotten updates due to a 
> separate repository)?
Everyone else working with upstream qemu is using git.  Using git
makes it very easy to pull in changes from their trees as well as
merging new changes from upstream''s svn.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Ian Jackson wrote:
> Andre Przywara writes ("Re: [Patch] ioemu-remote: fix gcc4 build
problem (?)"):
>> I tried these both version. It says I am up-to-date.
> 
> How odd.
Right you are. Now it works... Have you changed something on the servers 
since yesterday?

I have checked commit b5123e05cce4be4c6c8c822fad0f0df4c053da06 (With 
--disable-gcc-check, do not produce spurious errors if no GCC3 at all.)

To be honest this is almost the same fix I had created in the first try, 
but later I found the far more elegant fix in upstream QEMU:
--- configure.old       2008-07-21 15:45:25.000000000 +0200
+++ configure.qemu      2008-07-21 15:44:31.000000000 +0200
@@ -1241,7 +1241,7 @@
      fi
      echo "#define CONFIG_DYNGEN_OP 1" >> $config_h
      gcc3minver=`$cc --version 2> /dev/null| fgrep "(GCC) 3." |
awk ''{
print $3 }'' | cut -f2 -d.`
-    if test -n "$gcc3minver" -a $gcc3minver -gt 3
+    if test -n "$gcc3minver" && test $gcc3minver -gt 3
      then
        echo "HAVE_GT_GCC_3_3=true" >> $config_mak
      else

Mmmh, shouldn''t that be -ge instead of -gt?

Attached a version against the current ;-) git head.
I think it is much cleaner and the same as in upstream QEMU.

Regards,
Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 277-84917
----to satisfy European Law for business letters:
AMD Saxony Limited Liability Company & Co. KG,
Wilschdorfer Landstr. 101, 01109 Dresden, Germany
Register Court Dresden: HRA 4896, General Partner authorized
to represent: AMD Saxony LLC (Wilmington, Delaware, US)
General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Andre Przywara writes ("[Xen-devel] Re: [Patch] ioemu-remote: fix gcc4
build problem (?)"):
> To be honest this is almost the same fix I had created in the first try, 
> but later I found the far more elegant fix in upstream QEMU:
I hadn''t spotted that, thanks.  I''ve applied that now instead,
and a
couple of other fixes.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel