emulators/qemu-devel fails if sysutils/dtc is installed: ===> Registering installation for qemu-devel-8.2.0.20231031 as automatic Installing qemu-devel-8.2.0.20231031... pkg-static: qemu-devel-8.2.0.20231031 conflicts with dtc-1.6.0 (installs files into the same place). Problematic file: /usr/local/include/fdt.h After the recent update to qemu-devel, it appears to be building against a copy of dtc extracted in WRKDIR. Is it important that qemu-devel use THAT particular version of the upstream repo (https://git.kernel.org/pub/scm/utils/dtc/dtc.git)? Or could the qemu-devel build be convinced to use sysutils/dtc? If it is considered required or desirable to build against an imported version of libfdt, perhaps qemu-devel should not install that imported version into PREFIX/{lib,include}. In that case, maybe don't install libfdt & fdt.h at all - and statically link to libfdt. Or install libfdt to a private directory (and use rpath during linking) - for instance, install libftd.so to PREFIX/qemu/lib.
@bofh, Why in ports e6a3abc3c8260427f41eb4e50d57cc1bceb891f7, do you escape the " in CONFIGURE_ARGS (like: --extra-ldflags=-L\"${LOCALBASE}/lib\" )? It seems to get passed to meson, and ultimately to cc, and the quotes actually are interpreted as part of the path string. I made a change to test --enable-fdt=system, and got this error from meson (in build/meson-logs/meson-log.txt): =========== Command line: `/usr/bin/cc -m64 -mcx16 '-L"/usr/lib"' '-L"/usr/local/lib"' -I/z1/local/users/jhein/.nobak/wd/usr/ports/emulators/qemu-devel/work/qemu-6c9ae1ce82b65faa3f266fd103729878cf11e07e -I/usr/local/include -I/usr/local/include/capstone /z1/local/users/jhein/.nobak/wd/usr/ports/emulators/qemu-devel/work/qemu-6c9ae1ce82b65faa3f266fd103729878cf11e07e/build/meson-private/tmpdriw8mlm/testfile.c -o /z1/local/users/jhein/.nobak/wd/usr/ports/emulators/qemu-devel/work/qemu-6c9ae1ce82b65faa3f266fd103729878cf11e07e/build/meson-private/tmpdriw8mlm/output.exe -O2 -pipe -fstack-protector-strong -fno-strict-aliasing '-DPREFIX=\""/usr/local\""' -D_FILE_OFFSET_BITS=64 -O0 -Werror=implicit-function-declaration -Wl,--start-group -lfdt -Wl,--end-group -Wl,--allow-shlib-undefined -Wl,-rpath=/usr/local/lib` -> 1 stderr: ld: error: unable to find library -lfdt cc: error: linker command failed with exit code 1 (use -v to see invocation) =========== Notice that there are literal " marks in -L"/usr/lib" and -L"/usr/local/lib" in the meson log. That is causing the search for libfdt to fail since the quote characters are literally included in the path name. When I remove the \ (i.e., change \" to just ") in emulators/qemu-devel/Makefile, then the -L/usr/local/lib search works (and cc can find -lfdt). I'm just wondering what was the reason behind adding the backslash escaped quoting in -L\"/usr/local/lib\" (and -L\"/usr/lib\" as well). It is a bit unusual to see that, so there must have been something specific that drove the addition of the backslash escapes. Maybe it is to address potential spaces in LOCALBASE (admittedly that would be tricky to support and get the right quoting passed through all the layers in play here: the Makefile, configure shell script, and meson python), but that would not explain the quoting around the literal /usr/lib.
Lots of questions :P but I will try to answer: Before any discussion soon we will no longer accept bug reports when you are using ports with the exceptions like the following where there are conflicts. (In reply to John Hein from comment #0) I think in qemu-devel it was always like this. And it is important. I can't recollect the bug number but it had runtime failures with the system dtc. I will look into the possibilities but I am heavily stuck with other works in the ports tree and might not comeup with a solution to make your expectations. If you have times and want to contribute feel free to submit a patch. (In reply to John Hein from comment #1) :/ In previous it used autotools and not meson and at that time this was necessary. I haven't recently checked this. But then again in previous we also used to use qemu-devel in the cluster for the CI but when I created the nox11 flavor we moved back to emulators/qemu@nox11. So although I still maintain and update this port I/we do not use it as extensively as it was used before hence there might be glitches. But then again I might not be look into it with sharp eyes before the next quarter. And if you have any patches feel free to submit a git formatted patch.
Created attachment 246313 [details] [patch] deconflict qemu-devel & dtc Deconflict qemu-devel with libfdt in sysutils/dtc. Update link/compile flags. - Don't install conflicting libfdt & fdt.h, and use libfdt from systuils/dtc. - Let qemu use dtc from sysutils/dtc. - Fix broken quoting in --extra-ldflags [1]. - Remove unnecessary cflags (no longer needed now - they were added years ago for a much older version of qemu). - Remove unnecessary -L/usr/lib (which forces /lib/libncurses.so even if NCURSES_PORT is on). - While here sort CONFIGURE_ARGS (a minimal change as suggested by portfmt). The only actual changes to CONFIGURE_ARGS are --extra-ldflags and --extra-cflags and --enable-fdt. [1] The escaped quoting in --extra-ldflags breaks meson which gets the quote chars as is (so meson cannot find anything in the path string literally spelled with quote characters). Some of these updates (cflags/ldflags cleanup) can likely be applied to other emulators/qemu* ports. I also updated sysutils/dtc to 1.7.0 locally and had build success (with both 1.6.0 and 1.7.0).
I don't think I will actually go with the dtc change as this might break anytime. In fact in previous it has so far I remember. I will commit the rest in an upcoming update at the end of the month. And also add a CONFLICT with system dtc.
(In reply to John Hein from comment #3) By the way, this was tested in poudriere builds with each of NCURSES_DEFAULT, NCURSES_BASE, NCURSES_PORTS. Before this patch, it was not linking with the correct ncurses libs for PORTS - mostly because of the bad ldflags. The build was not finding libs in /usr/local/lib - and not just ncurses, but also libiconv and others.
(In reply to John Hein from comment #5) Noted. I will fix that in the upcoming days. My comment was not about this but dtc only.
(In reply to Muhammad Moinur Rahman from comment #4) If you don't want to pull in a dep on sysutils/dtc (although other qemu ports have one), then please consider doing a deconflict by installing the internal fdt lib & headers that qemu-devel uses in a private directory (or do a static link and don't install the fdt lib at all). If you can find a reference to the breakage you mentioned, please cite it - now I'm curious about the nature of the failure.
(In reply to John Hein from comment #7) > If you don't want to pull in a dep on sysutils/dtc (although other qemu ports have one), then please consider doing a deconflict by installing the internal fdt lib & headers that qemu-devel uses in a private directory (or do a static link and don't install the fdt lib at all). Okiz. This is doable I think. > If you can find a reference to the breakage you mentioned, please cite it - now I'm curious about the nature of the failure. The qemu project always works on the devel version of dtc and based on their requirements and final tests for a release merge/upstream the devel version to dtc. So right now you are able to build qemu-devel with system dtc doesnt't mean you will always be able to do that. This sort of breakage often happens right after a fresh release when they start adding more stuffs into it. Try running qemu with capstone. I can't recollect the exact bug report but what happened is I switched to the system DTC and then maybe in less than 1-2 months I had to switch back. :'( It has been more than 8 years I am maintaining these and you know FreeBSD is a place where things keep happening.
(In reply to Muhammad Moinur Rahman from comment #8) Yep, I understand your reasoning for using the head of the dtc project with the head of the qemu-devel project. Keeping that version of dtc/libfdt private to qemu-devel (instead of installing it to LOCALBASE/lib) sounds like the best plan.
On a second thought I am just trying to find out the reason on why is it even installed. find /usr/local/bin/ -name 'qemu*' -exec ldd {} \+ | grep fdt doesn't give me a good reason for those fdt* files at all. :/
Comment on attachment 246313 [details] [patch] deconflict qemu-devel & dtc We will handle the fdt issue in a different manner.
Created attachment 246329 [details] Remove fdt Can you please test this patch? I have removed the entire fdt part as those are actually used during build times only. But let's check it first. I don't have a running x host now to check the changes. But if you can test it that would be really great.