Re: [Qemu-block] [Qemu-devel] [PATCH] tcmu: Introduce qemu-tcmu utility

2019-03-12 Thread Fam Zheng 



> On Mar 12, 2019, at 18:03, Kevin Wolf  wrote:
> 
> Am 12.03.2019 um 03:18 hat Fam Zheng geschrieben:
>>> On Mar 11, 2019, at 19:06, Kevin Wolf  wrote:
>>> Am 09.03.2019 um 02:46 hat Yaowei Bai geschrieben:
 Thanks for explaining the background. It comes to my mind that actually we
 talked about these two cases with Fam a bit long time ago and decided to
 support both these two cases. The reason why we implement case2 first is
 currently we care more about exporting new opened images and it's a bit
 more convenient, exporting from a VM or QMP can be added in the later
 release. Do you think it's reasonable/acceptable that we support both
 cases and use case2 for normal new opened images and case1 for the
 circumstances you mention above?
>>> 
>>> I would like to avoid a second code path because it comes with a
>>> maintenance cost.
>>> 
>>> Experience also tells that adding a new way to parse option strings will
>>> come back at us later because it we must always maintain compatibility
>>> with yet another format.
>> 
>> If the rule is that cfgstr strictly follows -blockdev syntax and the
>> parsing code is mostly shared, it shouldn’t be a problem, right? I
>> suppose this will limit the expressiveness of cfgstr but might be a
>> reasonable tradeoff between implementation complexity, user
>> friendliness and interface consistency.
> 
> Yes, if we could pass the cfgstr directly to an existing parser, that
> would make it less bad at least.
> 
> Of course, if we directly pass cfgstr to the -blockdev parser, it also
> means that we can't have additional options for configuring the
> BlockBackend (which could be part of the -export command line option for
> qemu-tcmu).
> 
> That could be addressed by wrapping another QAPI object around it that
> only contain BlockdevOptions as one field, but then you have to prefix
> every block node option if you use keyval visitor syntax.
> 
>> Another possibility is to use json: format in cfgstr for anything more
>> complex than a single -blockdev.
> 
> Parsing like -blockdev already includes JSON syntax (which is necessary
> to get the full expressiveness).
> 
> If you want to support the equivalent of multiple -blockdevs, you'd need
> to wrap the BlockdevOptions in a QAPI list.
> 
>>> So I would prefer not doing this and just passing command line options
>>> to qemu-tcmu, which can reuse the already existing code paths.
>> 
>> I think the effect of not supporting adding new blockdev from cfgstr
>> is that we have to resort to QMP to allow hot-adding targets. It’s not
>> necessarily bad, though I’m not sure hwo that aligns with Yaowei’s
>> development plan.
> 
> This is true, but we need a way to do this from QMP anyway. So the
> question is whether we want to introduce a second way to achieve the
> same thing a bit more conveniently. But I expect that hot-adding is
> something that is usually done with management software anyway, so does
> the convenience actually buy us much?

The real difference is, are existing management software to adopt qemu-tcmu 
built around targetcli family or QMP? I think the management must understand 
targetcli interface to work, talking QMP is an additional burden.

So IMO cfgstr can ideally be the only channel that the management interacts 
with, if we could reuse existing QMP/QAPI code well enough.

Fam

> 
> Kevin

Re: [Qemu-block] [Qemu-devel] [PATCH] tcmu: Introduce qemu-tcmu utility

2019-03-12 Thread Fam Zheng 



> On Mar 11, 2019, at 19:06, Kevin Wolf  wrote:
> 
> Am 09.03.2019 um 02:46 hat Yaowei Bai geschrieben:
>> Thanks for explaining the background. It comes to my mind that actually we
>> talked about these two cases with Fam a bit long time ago and decided to
>> support both these two cases. The reason why we implement case2 first is
>> currently we care more about exporting new opened images and it's a bit
>> more convenient, exporting from a VM or QMP can be added in the later
>> release. Do you think it's reasonable/acceptable that we support both
>> cases and use case2 for normal new opened images and case1 for the
>> circumstances you mention above?
> 
> I would like to avoid a second code path because it comes with a
> maintenance cost.
> 
> Experience also tells that adding a new way to parse option strings will
> come back at us later because it we must always maintain compatibility
> with yet another format.

If the rule is that cfgstr strictly follows -blockdev syntax and the parsing 
code is mostly shared, it shouldn’t be a problem, right? I suppose this will 
limit the expressiveness of cfgstr but might be a reasonable tradeoff between 
implementation complexity, user friendliness and interface consistency.

Another possibility is to use json: format in cfgstr for anything more complex 
than a single -blockdev.

> 
> So I would prefer not doing this and just passing command line options
> to qemu-tcmu, which can reuse the already existing code paths.

I think the effect of not supporting adding new blockdev from cfgstr is that we 
have to resort to QMP to allow hot-adding targets. It’s not necessarily bad, 
though I’m not sure hwo that aligns with Yaowei’s development plan.

Fam


> 
> Kevin
>

Re: [Qemu-block] [Qemu-devel] [PATCH] tcmu: Introduce qemu-tcmu utility

2019-03-12 Thread Kevin Wolf 
Am 12.03.2019 um 03:18 hat Fam Zheng geschrieben:
> > On Mar 11, 2019, at 19:06, Kevin Wolf  wrote:
> > Am 09.03.2019 um 02:46 hat Yaowei Bai geschrieben:
> >> Thanks for explaining the background. It comes to my mind that actually we
> >> talked about these two cases with Fam a bit long time ago and decided to
> >> support both these two cases. The reason why we implement case2 first is
> >> currently we care more about exporting new opened images and it's a bit
> >> more convenient, exporting from a VM or QMP can be added in the later
> >> release. Do you think it's reasonable/acceptable that we support both
> >> cases and use case2 for normal new opened images and case1 for the
> >> circumstances you mention above?
> > 
> > I would like to avoid a second code path because it comes with a
> > maintenance cost.
> > 
> > Experience also tells that adding a new way to parse option strings will
> > come back at us later because it we must always maintain compatibility
> > with yet another format.
> 
> If the rule is that cfgstr strictly follows -blockdev syntax and the
> parsing code is mostly shared, it shouldn’t be a problem, right? I
> suppose this will limit the expressiveness of cfgstr but might be a
> reasonable tradeoff between implementation complexity, user
> friendliness and interface consistency.

Yes, if we could pass the cfgstr directly to an existing parser, that
would make it less bad at least.

Of course, if we directly pass cfgstr to the -blockdev parser, it also
means that we can't have additional options for configuring the
BlockBackend (which could be part of the -export command line option for
qemu-tcmu).

That could be addressed by wrapping another QAPI object around it that
only contain BlockdevOptions as one field, but then you have to prefix
every block node option if you use keyval visitor syntax.

> Another possibility is to use json: format in cfgstr for anything more
> complex than a single -blockdev.

Parsing like -blockdev already includes JSON syntax (which is necessary
to get the full expressiveness).

If you want to support the equivalent of multiple -blockdevs, you'd need
to wrap the BlockdevOptions in a QAPI list.

> > So I would prefer not doing this and just passing command line options
> > to qemu-tcmu, which can reuse the already existing code paths.
> 
> I think the effect of not supporting adding new blockdev from cfgstr
> is that we have to resort to QMP to allow hot-adding targets. It’s not
> necessarily bad, though I’m not sure hwo that aligns with Yaowei’s
> development plan.

This is true, but we need a way to do this from QMP anyway. So the
question is whether we want to introduce a second way to achieve the
same thing a bit more conveniently. But I expect that hot-adding is
something that is usually done with management software anyway, so does
the convenience actually buy us much?

Kevin

Re: [Qemu-block] [Qemu-devel] [PATCH] tcmu: Introduce qemu-tcmu utility

2019-01-01 Thread Yaowei Bai 
Ping.

BTW, it should be update docker image to install glib to fix this.

On Wed, Dec 26, 2018 at 12:19:48AM -0800, no-re...@patchew.org wrote:
> Patchew URL: 
> https://patchew.org/QEMU/1545387387-9613-1-git-send-email-baiyao...@cmss.chinamobile.com/
> 
> 
> 
> Hi,
> 
> This series seems to have some coding style problems. See output below for
> more information:
> 
> Message-id: 1545387387-9613-1-git-send-email-baiyao...@cmss.chinamobile.com
> Type: series
> Subject: [Qemu-devel] [PATCH] tcmu: Introduce qemu-tcmu utility
> 
> === TEST SCRIPT BEGIN ===
> #!/bin/bash
> 
> BASE=base
> n=1
> total=$(git log --oneline $BASE.. | wc -l)
> failed=0
> 
> git config --local diff.renamelimit 0
> git config --local diff.renames True
> git config --local diff.algorithm histogram
> 
> commits="$(git log --format=%H --reverse $BASE..)"
> for c in $commits; do
> echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
> if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; 
> then
> failed=1
> echo
> fi
> n=$((n+1))
> done
> 
> exit $failed
> === TEST SCRIPT END ===
> 
> Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
> Switched to a new branch 'test'
> 52869e1 tcmu: Introduce qemu-tcmu utility
> 
> === OUTPUT BEGIN ===
> Checking PATCH 1/1: tcmu: Introduce qemu-tcmu utility...
> WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
> #157: 
> new file mode 100644
> 
> ERROR: trailing whitespace
> #329: FILE: qemu-tcmu.c:51:
> +"Usage:\n" $
> 
> WARNING: Block comments use a leading /* on a separate line
> #466: FILE: qemu-tcmu.c:188:
> +/* now when the initialization is (almost) complete, chdir("/")
> 
> WARNING: Block comments use a trailing */ on a separate line
> #467: FILE: qemu-tcmu.c:189:
> + * to free any busy filesystems */
> 
> ERROR: code indent should never use tabs
> #525: FILE: tcmu/helper.c:16:
> +^Iuint8_t *cdb,$
> 
> ERROR: code indent should never use tabs
> #526: FILE: tcmu/helper.c:17:
> +^Istruct iovec *iovec,$
> 
> ERROR: code indent should never use tabs
> #527: FILE: tcmu/helper.c:18:
> +^Isize_t iov_cnt)$
> 
> ERROR: code indent should never use tabs
> #529: FILE: tcmu/helper.c:20:
> +^Iuint8_t buf[36];$
> 
> ERROR: code indent should never use tabs
> #531: FILE: tcmu/helper.c:22:
> +^Imemset(buf, 0, sizeof(buf));$
> 
> ERROR: code indent should never use tabs
> #533: FILE: tcmu/helper.c:24:
> +^Ibuf[2] = 0x05; /* SPC-3 */$
> 
> ERROR: code indent should never use tabs
> #534: FILE: tcmu/helper.c:25:
> +^Ibuf[3] = 0x02; /* response data format */$
> 
> ERROR: code indent should never use tabs
> #536: FILE: tcmu/helper.c:27:
> +^I/*$
> 
> ERROR: code indent should never use tabs
> #537: FILE: tcmu/helper.c:28:
> +^I * A Third-Party Copy (3PC)$
> 
> ERROR: code indent should never use tabs
> #538: FILE: tcmu/helper.c:29:
> +^I *$
> 
> ERROR: code indent should never use tabs
> #539: FILE: tcmu/helper.c:30:
> +^I * Enable the XCOPY$
> 
> ERROR: code indent should never use tabs
> #540: FILE: tcmu/helper.c:31:
> +^I */$
> 
> ERROR: code indent should never use tabs
> #541: FILE: tcmu/helper.c:32:
> +^Ibuf[5] = 0x08;$
> 
> ERROR: code indent should never use tabs
> #543: FILE: tcmu/helper.c:34:
> +^Ibuf[7] = 0x02; /* CmdQue */$
> 
> ERROR: code indent should never use tabs
> #545: FILE: tcmu/helper.c:36:
> +^Imemcpy([8], "LIO-ORG ", 8);$
> 
> ERROR: code indent should never use tabs
> #546: FILE: tcmu/helper.c:37:
> +^Imemset([16], 0x20, 16);$
> 
> ERROR: code indent should never use tabs
> #547: FILE: tcmu/helper.c:38:
> +^Imemcpy([16], "TCMU device", 11);$
> 
> ERROR: code indent should never use tabs
> #548: FILE: tcmu/helper.c:39:
> +^Imemcpy([32], "0002", 4);$
> 
> ERROR: code indent should never use tabs
> #549: FILE: tcmu/helper.c:40:
> +^Ibuf[4] = 31; /* Set additional length to 31 */$
> 
> ERROR: code indent should never use tabs
> #551: FILE: tcmu/helper.c:42:
> +^Itcmu_memcpy_into_iovec(iovec, iov_cnt, buf, sizeof(buf));$
> 
> ERROR: code indent should never use tabs
> #552: FILE: tcmu/helper.c:43:
> +^Ireturn TCMU_STS_OK;$
> 
> ERROR: code indent should never use tabs
> #558: FILE: tcmu/helper.c:49:
> +^Iif (c >= '0' && c <= '9') {$
> 
> ERROR: code indent should never use tabs
> #559: FILE: tcmu/helper.c:50:
> +^I^I*val = c - '0';$
> 
> ERROR: code indent should never use tabs
> #560: FILE: tcmu/helper.c:51:
> +^I^Ireturn true;$
> 
> ERROR: code indent should never use tabs
> #561: FILE: tcmu/helper.c:52:
> +^I}$
> 
> ERROR: code indent should never use tabs
> #562: FILE: tcmu/helper.c:53:
> +^Iif (c >= 'a' && c <= 'f') {$
> 
> ERROR: code indent should never use tabs
> #563: FILE: tcmu/helper.c:54:
> +^I^I*val = c - 'a' + 10;$
> 
> ERROR: code indent should never use tabs
> #564: FILE: tcmu/helper.c:55:
> +^I^Ireturn true;$
> 
> ERROR: code indent should never use tabs
> #565: FILE: tcmu/helper.c:56:
> +^I}$
> 
> ERROR: code indent should never use tabs
> #566: FILE: tcmu/helper.c:57:
> +^Iif (c

Re: [Qemu-block] [Qemu-devel] [PATCH] tcmu: Introduce qemu-tcmu utility

2018-12-26 Thread no-reply 
Patchew URL: 
https://patchew.org/QEMU/1545387387-9613-1-git-send-email-baiyao...@cmss.chinamobile.com/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Message-id: 1545387387-9613-1-git-send-email-baiyao...@cmss.chinamobile.com
Type: series
Subject: [Qemu-devel] [PATCH] tcmu: Introduce qemu-tcmu utility

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
52869e1 tcmu: Introduce qemu-tcmu utility

=== OUTPUT BEGIN ===
Checking PATCH 1/1: tcmu: Introduce qemu-tcmu utility...
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#157: 
new file mode 100644

ERROR: trailing whitespace
#329: FILE: qemu-tcmu.c:51:
+"Usage:\n" $

WARNING: Block comments use a leading /* on a separate line
#466: FILE: qemu-tcmu.c:188:
+/* now when the initialization is (almost) complete, chdir("/")

WARNING: Block comments use a trailing */ on a separate line
#467: FILE: qemu-tcmu.c:189:
+ * to free any busy filesystems */

ERROR: code indent should never use tabs
#525: FILE: tcmu/helper.c:16:
+^Iuint8_t *cdb,$

ERROR: code indent should never use tabs
#526: FILE: tcmu/helper.c:17:
+^Istruct iovec *iovec,$

ERROR: code indent should never use tabs
#527: FILE: tcmu/helper.c:18:
+^Isize_t iov_cnt)$

ERROR: code indent should never use tabs
#529: FILE: tcmu/helper.c:20:
+^Iuint8_t buf[36];$

ERROR: code indent should never use tabs
#531: FILE: tcmu/helper.c:22:
+^Imemset(buf, 0, sizeof(buf));$

ERROR: code indent should never use tabs
#533: FILE: tcmu/helper.c:24:
+^Ibuf[2] = 0x05; /* SPC-3 */$

ERROR: code indent should never use tabs
#534: FILE: tcmu/helper.c:25:
+^Ibuf[3] = 0x02; /* response data format */$

ERROR: code indent should never use tabs
#536: FILE: tcmu/helper.c:27:
+^I/*$

ERROR: code indent should never use tabs
#537: FILE: tcmu/helper.c:28:
+^I * A Third-Party Copy (3PC)$

ERROR: code indent should never use tabs
#538: FILE: tcmu/helper.c:29:
+^I *$

ERROR: code indent should never use tabs
#539: FILE: tcmu/helper.c:30:
+^I * Enable the XCOPY$

ERROR: code indent should never use tabs
#540: FILE: tcmu/helper.c:31:
+^I */$

ERROR: code indent should never use tabs
#541: FILE: tcmu/helper.c:32:
+^Ibuf[5] = 0x08;$

ERROR: code indent should never use tabs
#543: FILE: tcmu/helper.c:34:
+^Ibuf[7] = 0x02; /* CmdQue */$

ERROR: code indent should never use tabs
#545: FILE: tcmu/helper.c:36:
+^Imemcpy([8], "LIO-ORG ", 8);$

ERROR: code indent should never use tabs
#546: FILE: tcmu/helper.c:37:
+^Imemset([16], 0x20, 16);$

ERROR: code indent should never use tabs
#547: FILE: tcmu/helper.c:38:
+^Imemcpy([16], "TCMU device", 11);$

ERROR: code indent should never use tabs
#548: FILE: tcmu/helper.c:39:
+^Imemcpy([32], "0002", 4);$

ERROR: code indent should never use tabs
#549: FILE: tcmu/helper.c:40:
+^Ibuf[4] = 31; /* Set additional length to 31 */$

ERROR: code indent should never use tabs
#551: FILE: tcmu/helper.c:42:
+^Itcmu_memcpy_into_iovec(iovec, iov_cnt, buf, sizeof(buf));$

ERROR: code indent should never use tabs
#552: FILE: tcmu/helper.c:43:
+^Ireturn TCMU_STS_OK;$

ERROR: code indent should never use tabs
#558: FILE: tcmu/helper.c:49:
+^Iif (c >= '0' && c <= '9') {$

ERROR: code indent should never use tabs
#559: FILE: tcmu/helper.c:50:
+^I^I*val = c - '0';$

ERROR: code indent should never use tabs
#560: FILE: tcmu/helper.c:51:
+^I^Ireturn true;$

ERROR: code indent should never use tabs
#561: FILE: tcmu/helper.c:52:
+^I}$

ERROR: code indent should never use tabs
#562: FILE: tcmu/helper.c:53:
+^Iif (c >= 'a' && c <= 'f') {$

ERROR: code indent should never use tabs
#563: FILE: tcmu/helper.c:54:
+^I^I*val = c - 'a' + 10;$

ERROR: code indent should never use tabs
#564: FILE: tcmu/helper.c:55:
+^I^Ireturn true;$

ERROR: code indent should never use tabs
#565: FILE: tcmu/helper.c:56:
+^I}$

ERROR: code indent should never use tabs
#566: FILE: tcmu/helper.c:57:
+^Iif (c >= 'A' && c <= 'F') {$

ERROR: code indent should never use tabs
#567: FILE: tcmu/helper.c:58:
+^I^I*val = c - 'A' + 10;$

ERROR: code indent should never use tabs
#568: FILE: tcmu/helper.c:59:
+^I^Ireturn true;$

ERROR: code indent should never use tabs
#569: FILE: tcmu/helper.c:60:
+^I}$

ERROR: code indent should never use tabs
#570: FILE: tcmu/helper.c:61:
+^Ireturn false;$

ERROR: code indent should never use tabs
#574: FILE: tcmu/helper.c:65:
+^Istruct tcmu_device *dev,$

ERROR: code indent should

Re: [Qemu-block] [Qemu-devel] [PATCH] tcmu: Introduce qemu-tcmu utility

2018-12-26 Thread no-reply 
Patchew URL: 
https://patchew.org/QEMU/1545387387-9613-1-git-send-email-baiyao...@cmss.chinamobile.com/



Hi,

This series failed the docker-mingw@fedora build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
time make docker-test-mingw@fedora SHOW_ENV=1 J=8
=== TEST SCRIPT END ===

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/tmp/qemu-test/install --python=/usr/bin/python3 
--cross-prefix=x86_64-w64-mingw32- --enable-trace-backends=simple 
--enable-gnutls --enable-nettle --enable-curl --enable-vnc --enable-bzip2 
--enable-guest-agent --with-sdlabi=2.0

ERROR: glib is required to compile QEMU

# QEMU configure log Wed Dec 26 07:59:16 UTC 2018
# Configured with: '/tmp/qemu-test/src/configure' '--enable-werror' 
'--target-list=x86_64-softmmu,aarch64-softmmu' 
'--prefix=/tmp/qemu-test/install' '--python=/usr/bin/python3' 
'--cross-prefix=x86_64-w64-mingw32-' '--enable-trace-backends=simple' 
'--enable-gnutls' '--enable-nettle' '--enable-curl' '--enable-vnc' 
'--enable-bzip2' '--enable-guest-agent' '--with-sdlabi=2.0'
---
funcs: do_compiler do_cc compile_object check_define main
lines: 92 119 617 634 0
x86_64-w64-mingw32-gcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings 
-Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o 
config-temp/qemu-conf.o config-temp/qemu-conf.c
config-temp/qemu-conf.c:2:2: error: #error __linux__ not defined
 #error __linux__ not defined
  ^

---
funcs: do_compiler do_cc compile_object check_define main
lines: 92 119 617 686 0
x86_64-w64-mingw32-gcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings 
-Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o 
config-temp/qemu-conf.o config-temp/qemu-conf.c
config-temp/qemu-conf.c:2:2: error: #error __i386__ not defined
 #error __i386__ not defined
  ^

---
funcs: do_compiler do_cc compile_object check_define main
lines: 92 119 617 689 0
x86_64-w64-mingw32-gcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings 
-Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o 
config-temp/qemu-conf.o config-temp/qemu-conf.c
config-temp/qemu-conf.c:2:2: error: #error __ILP32__ not defined
 #error __ILP32__ not defined
  ^

---
lines: 92 125 917 0
x86_64-w64-mingw32-gcc -mthreads -D__USE_MINGW_ANSI_STDIO=1 
-DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef 
-Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv 
-o config-temp/qemu-conf.exe config-temp/qemu-conf.c -g -liberty
/usr/lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/bin/ld: 
cannot find -liberty
collect2: error: ld returned 1 exit status

funcs: do_compiler do_cc compile_object main
lines: 92 119 1817 0
---
funcs: do_compiler do_cc compile_prog cc_has_warning_flag main
lines: 92 125 1899 1903 0
x86_64-w64-mingw32-gcc -m64 -mcx16 -mthreads -D__USE_MINGW_ANSI_STDIO=1 
-DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef 
-Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv 
-Werror -Werror=address-of-packed-member -o config-temp/qemu-conf.exe 
config-temp/qemu-conf.c -m64 -g
cc1: error: -Werror=address-of-packed-member: no option 
-Waddress-of-packed-member

funcs: do_compiler do_cc compile_prog cc_has_warning_flag main
lines: 92 125 1899 1903 0
x86_64-w64-mingw32-gcc -m64 -mcx16 -mthreads -D__USE_MINGW_ANSI_STDIO=1 
-DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef 
-Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv 
-Werror -Wstring-plus-int -o config-temp/qemu-conf.exe config-temp/qemu-conf.c 
-m64 -g
x86_64-w64-mingw32-gcc: error: unrecognized command line option 
'-Wstring-plus-int'; did you mean '-Wstrict-aliasing'?

funcs: do_compiler do_cc compile_prog cc_has_warning_flag main
lines: 92 125 1899 1903 0
x86_64-w64-mingw32-gcc -m64 -mcx16 -mthreads -D__USE_MINGW_ANSI_STDIO=1 
-DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef 
-Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv 
-Werror -Winitializer-overrides -o config-temp/qemu-conf.exe 
config-temp/qemu-conf.c -m64 -g
x86_64-w64-mingw32-gcc: error: unrecognized command line option 
'-Winitializer-overrides'; did you mean '-Wno-suggest-override'?

funcs: do_compiler do_cc compile_prog