At present winsymlinks is set to 'nativestrict', and its behavior is:
a) if native symlinks are enabled and <target> exists, creates
<destination> as a native Windows symlink;
b) else if native symlinks are not enabled or if <target> does
not exist, 'ln -s' fails.
This causes the following error message was seen during the configure:
"ln: failed to create symbolic link
'x86_64-softmmu/qemu-system-x86_64.exe': No such file or directory"
Change winsymlinks to 'native' whose behavior is most similar to the
behavior of 'ln -s' on *nix, that is:
a) if native symlinks are enabled, and whether <target> exists
or not, creates <destination> as a native Windows symlink;
b) else if native symlinks are not enabled, and whether <target>
exists or not, 'ln -s' creates as a Windows shortcut file.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Acked-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Message-Id: <20220719161230.766063-1-bmeng.cn@gmail.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20220725140520.515340-5-alex.bennee@linaro.org>
The MSYS2 task in the Cirrus-CI is currently failing with error messages
like this:
warning: database file for 'ucrt64' does not exist (use '-Sy' to download)
:: Starting core system upgrade...
there is nothing to do
:: Starting full system upgrade...
error: failed to prepare transaction (could not find database)
Seems like it can be fixed by switching to a newer release and by refreshing
the database one more time after changing the /etc/pacman.conf file.
Message-Id: <20210504100223.25427-30-alex.bennee@linaro.org>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
The Cirrus CI macOS build hosts have exhibited a serious performance
degradation in recent months. For example the "qom-test" qtest takes
over an hour for only the qemu-system-aarch64 binary. This is as much
20-40 times slower than other environments. The other qtests all show
similar performance degradation, as do many of the unit tests.
This does not appear related to QEMU code changes, since older git
commits which were known to fully complete in less than 1 hour on
Cirrus CI now also show similar bad performance. Either Cirrus CI
performance has degraded, or an change in its environment has exposed
a latent bug widely affecting all of QEMU. Debugging the qom-test
showed no easily identified large bottleneck - every step of the
test execution was simply slower.
macOS builds/tests run outside Cirrus CI show normal performance.
With an inability to identify any obvious problem, the only viable
way to get a reliably completing Cirrus CI macOS job is to cut out
almost all of the qtests. We choose to run the x86_64 target only,
since that has very few machine types and thus is least badly
impacted in the qom-test execution.
With this change, the macOS jobs complete in approx 35 minutes.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Willian Rampazzo <willianr@redhat.com>
Message-Id: <20210106114159.981538-1-berrange@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Setuptools is not needed anymore by the bundled copy of meson,
remove it.
Suggested-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Apple's nm implementation includes empty lines in the output that are not
found in GNU binutils. This confuses scripts/undefsym.py, though it did
not confuse the scripts/undefsym.sh script that it replaced. To fix
this, ignore lines that do not have two fields.
Reported-by: Emmanuel Blot <eblot.ml@gmail.com>
Tested-by: Emmanuel Blot <eblot.ml@gmail.com>
Fixes: 604f3e4e90 ("meson: Convert undefsym.sh to undefsym.py", 2020-09-08)
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The FreeBSD jobs currently hit the 1h time limit in the Cirrus-CI.
We have to split the build targets here to make sure that the job
finishes in time again. According to the Cirrus-CI docs and some
tests that I did, it also seems like the total amount of CPUs that
can be used for FreeBSD jobs is limited to 8, so each job now only
gets 4 CPUs. That increases the compilation time of each job a little
bit, but it still seems to be better to run two jobs with 4 CPUs each
in parallel than to run two jobs with 8 CPUs sequentially.
Message-Id: <20200831154405.229706-1-thuth@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
When looking at the CI jobs on cirrus-ci.com, it seems like the mojave-based
images have been decomissioned a while ago already, since apparently all our
jobs get automatically upgraded to catalina. So let's update our YML script
accordingly to avoid confusion.
Reviewed-by: Ed Maste <emaste@freebsd.org>
Message-Id: <20200728074405.13118-5-thuth@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Compiler warnings currently go unnoticed in our macOS builds, since -Werror
is only enabled for Linux and MinGW builds by default. So let's enable them
here now, too.
Unfortunately, the sasl header is marked as deprecated in the macOS headers
and thus generates a lot of deprecation warnings. Thus we have to also use
-Wno-error=deprecated-declarations to be able to compile the code here.
Message-Id: <20200728074405.13118-4-thuth@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
CirrusCI provides a mojave-xcode alias for the latest Xcode available.
Let's use it to make sure we track the latest releases.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
cirrus-ci.com also has the possibility to run CI tasks on macOS.
Since most of the QEMU developers do not have access to macOS yet,
let's add a CI pipeline for this operating system here, too.
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Ed Maste <emaste@freebsd.org>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
