Richard Henderson <richard.hender...@linaro.org> wrote: > On 6/22/23 18:54, Juan Quintela wrote: >> The following changes since commit b455ce4c2f300c8ba47cba7232dd03261368a4cb: >> Merge tag 'q800-for-8.1-pull-request' >> ofhttps://github.com/vivier/qemu-m68k into staging (2023-06-22 >> 10:18:32 +0200) >> are available in the Git repository at: >> https://gitlab.com/juan.quintela/qemu.git tags/next-pull-request >> for you to fetch changes up to >> 23e4307eadc1497bd0a11ca91041768f15963b68: >> migration/rdma: Split qemu_fopen_rdma() into input/output >> functions (2023-06-22 18:11:58 +0200) >> ---------------------------------------------------------------- >> Migration Pull request (20230621) take 2 >> In this pull request the only change is fixing 32 bits complitaion >> issue. >> Please apply. >> [take 1] >> - fix for multifd thread creation (fabiano) >> - dirtylimity (hyman) >> * migration-test will go on next PULL request, as it has failures. >> - Improve error description (tejus) >> - improve -incoming and set parameters before calling incoming (wei) >> - migration atomic counters reviewed patches (quintela) >> - migration-test refacttoring reviewed (quintela)
I had the feeling when I wake up that today was going to be a great day. Confirmed. > New failure with check-cfi-x86_64: Aha. CFI. Something that I don't know what it is failing on me. /me googles. /me enables cfi+lto and compiles with clang. 50/491] Compiling C object subprojects/berkeley-testfloat-3/libtestfloat.a.p/source_test_az_f128_rx.c.o [51/491] Compiling C object subprojects/berkeley-testfloat-3/libtestfloat.a.p/source_test_az_f128.c.o [52/491] Compiling C object subprojects/berkeley-testfloat-3/libtestfloat.a.p/source_test_abz_f128.c.o [53/491] Compiling C object subprojects/berkeley-testfloat-3/libtestfloat.a.p/source_test_abcz_f128.c.o [54/491] Compiling C object subprojects/berkeley-testfloat-3/libtestfloat.a.p/source_test_ab_f128_z_bool.c.o [55/491] Linking target qemu-system-x86_64 FAILED: qemu-system-x86_64 clang++ -m64 -mcx16 @qemu-system-x86_64.rsp /usr/bin/ld: cannot find libchardev.fa: Too many open files /usr/bin/ld: cannot find libqmp.fa: Too many open files /usr/bin/ld: cannot find libpage-vary-common.a: Too many open files /usr/bin/ld: cannot find libqemuutil.a: Too many open files /usr/bin/ld: cannot find subprojects/libvhost-user/libvhost-user-glib.a: Too many open files /usr/bin/ld: cannot find subprojects/libvhost-user/libvhost-user.a: Too many open files /usr/bin/ld: cannot find tcg/libtcg_softmmu.fa: Too many open files /usr/bin/ld: cannot find libmigration.fa: Too many open files /usr/bin/ld: cannot find libhwcore.fa: Too many open files /usr/bin/ld: cannot find libqom.fa: Too many open files /usr/bin/ld: cannot find gdbstub/libgdb_softmmu.fa: Too many open files /usr/bin/ld: cannot find libio.fa: Too many open files /usr/bin/ld: cannot find libcrypto.fa: Too many open files /usr/bin/ld: cannot find libauthz.fa: Too many open files /usr/bin/ld: cannot find libblockdev.fa: Too many open files /usr/bin/ld: cannot find libblock.fa: Too many open files /usr/bin/ld: cannot find libchardev.fa: Too many open files /usr/bin/ld: cannot find libqmp.fa: Too many open files /usr/bin/ld: cannot find /usr/lib64/libpixman-1.so: Too many open files /usr/bin/ld: cannot find /usr/lib64/libepoxy.so: Too many open files /usr/bin/ld: cannot find /usr/lib64/libxenctrl.so: Too many open files /usr/bin/ld: cannot find /usr/lib64/libxenstore.so: Too many open files /usr/bin/ld: cannot find /usr/lib64/libxenforeignmemory.so: Too many open files /usr/bin/ld: cannot find /usr/lib64/libxengnttab.so: Too many open files /usr/bin/ld: cannot find /usr/lib64/libxenevtchn.so: Too many open files Confirmed, today is going to be a great day. No check-cfi<anything> target for me. /me investigates what is going on. Found this and retries. AR=llvm-ar CC=clang CXX=clang++ /mnt/code/qemu/full/configure --enable-cfi --target-list=x86_64-softmmu Gives the same error. After a while of desesperation trying to disable features, etc, etc Just doing a plain ulimit -n 4096 fixed the problem. Here we go. Later, Juan.
