Message ID | 20190614072432.820-1-philmd@redhat.com (mailing list archive) |
---|---|
Headers | show |
Series | configure: Try to fix --static linking | expand |
On 6/14/19 9:24 AM, Philippe Mathieu-Daudé wrote: > Hi, > > Apparently QEMU static linking is slowly bitroting. Obviously it > depends the libraries an user has installed, anyway it seems there > are not much testing done. > > This series fixes few issues, enough to build QEMU on a Ubuntu > aarch64 host, but not yet on a x86_64 host: > > LINK x86_64-softmmu/qemu-system-x86_64 > /usr/bin/ld: cannot find -lgtk-3 > /usr/bin/ld: cannot find -latk-bridge-2.0 > /usr/bin/ld: cannot find -latspi > /usr/bin/ld: cannot find -lsystemd > /usr/bin/ld: cannot find -lgdk-3 > /usr/bin/ld: cannot find -lwayland-egl > /usr/bin/ld: cannot find -lmirclient > /usr/bin/ld: cannot find -lmircore > /usr/bin/ld: cannot find -lmircookie > /usr/bin/ld: cannot find -lepoxy > /usr/bin/ld: cannot find -latk-1.0 > /usr/bin/ld: cannot find -lgdk_pixbuf-2.0 > /usr/bin/ld: cannot find -lselinux > /usr/bin/ld: cannot find -lgtk-3 > /usr/bin/ld: cannot find -latk-bridge-2.0 > /usr/bin/ld: cannot find -latspi > /usr/bin/ld: cannot find -lsystemd > /usr/bin/ld: cannot find -lgdk-3 > /usr/bin/ld: cannot find -lwayland-egl > /usr/bin/ld: cannot find -lmirclient > /usr/bin/ld: cannot find -lmircore > /usr/bin/ld: cannot find -lmircookie > /usr/bin/ld: cannot find -lepoxy > /usr/bin/ld: cannot find -latk-1.0 > /usr/bin/ld: cannot find -lgdk_pixbuf-2.0 > /usr/bin/ld: cannot find -lselinux > /usr/bin/ld: attempted static link of dynamic object `/usr/lib/x86_64-linux-gnu/libz.so' > collect2: error: ld returned 1 exit status This one is funny, when installing libvte on Ubuntu 18.04: LINK x86_64-softmmu/qemu-system-x86_64 c++: error: /usr/lib/x86_64-linux-gnu/libunistring.so: No such file or directory c++: error: /usr/lib/x86_64-linux-gnu/libunistring.so: No such file or directory c++: error: /usr/lib/x86_64-linux-gnu/libunistring.so: No such file or directory c++: error: /usr/lib/x86_64-linux-gnu/libunistring.so: No such file or directory $ pkg-config --libs --static vte-2.91 -lvte-2.91 -lgtk-3 -latk-bridge-2.0 -latspi -ldbus-1 -lpthread -lsystemd -lgdk-3 -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lXfixes -lxkbcommon -lwayland-cursor -lwayland-egl -lwayland-client -lepoxy -ldl -lpangocairo-1.0 -lpangoft2-1.0 -lharfbuzz -lm -lgraphite2 -lpango-1.0 -lm -latk-1.0 -lcairo-gobject -lcairo -lz -lpixman-1 -lfontconfig -lexpat -lfreetype -lexpat -lfreetype -lpng16 -lm -lz -lm -lxcb-shm -lxcb-render -lXrender -lXext -lX11 -lpthread -lxcb -lXau -lXdmcp -lgdk_pixbuf-2.0 -lm -lpng16 -lm -lz -lm -lgio-2.0 -lz -lresolv -lselinux -lmount -lgmodule-2.0 -pthread -ldl -lgobject-2.0 -lffi -lglib-2.0 -pthread -lpcre -pthread -lgnutls -lgmp /usr/lib/x86_64-linux-gnu/libunistring.so -lidn2 -lhogweed -lgmp -lnettle -ltasn1 -lp11-kit -lz $ ls -ld /usr/lib/x86_64-linux-gnu/libunistring.so ls: cannot access '/usr/lib/x86_64-linux-gnu/libunistring.so': No such file or directory $ ls -ld /usr/lib/x86_64-linux-gnu/libunistring.so* lrwxrwxrwx. 1 root root 21 Mar 3 2018 /usr/lib/x86_64-linux-gnu/libunistring.so.2 -> libunistring.so.2.1.0 -rw-r--r--. 1 root root 1562664 Mar 3 2018 /usr/lib/x86_64-linux-gnu/libunistring.so.2.1.0 The fix is probably "sudo ln -s libunistring.so.2 /usr/lib/x86_64-linux-gnu/libunistring.so".
On Fri, 14 Jun 2019 at 08:27, Philippe Mathieu-Daudé <philmd@redhat.com> wrote: > Apparently QEMU static linking is slowly bitroting. Obviously it > depends the libraries an user has installed, anyway it seems there > are not much testing done. The main reason for supporting static linking is so we can build the user-mode emulators. Almost always the problems with static linking the softmmu binaries and the tools are issues with the distro's packaging of the static libraries (pkg-config files which specify things that don't work for static is a common one). So we could put in a lot of checking of "is what pkg-config tells us broken". Or we could just say "we don't support static linking for anything except the usermode binaries". We should probably phase in deprecation of that because it's possible somebody's using it seriously, but it seems like a fairly weird thing to do to me. thanks -- PMM
Peter Maydell <peter.maydell@linaro.org> writes: > On Fri, 14 Jun 2019 at 08:27, Philippe Mathieu-Daudé <philmd@redhat.com> wrote: >> Apparently QEMU static linking is slowly bitroting. Obviously it >> depends the libraries an user has installed, anyway it seems there >> are not much testing done. > > The main reason for supporting static linking is so we can build > the user-mode emulators. Almost always the problems with > static linking the softmmu binaries and the tools are > issues with the distro's packaging of the static libraries > (pkg-config files which specify things that don't work for > static is a common one). > > So we could put in a lot of checking of "is what pkg-config > tells us broken". Or we could just say "we don't support static > linking for anything except the usermode binaries". We > should probably phase in deprecation of that because it's > possible somebody's using it seriously, but it seems like > a fairly weird thing to do to me. It would be nice to have a --static-user config flag and deprecate the --static flag. I don't think there is a decent use case for system emulation targets. The Gentoo ebuild currently jumps through hoops to build QEMU by doing the build twice, first for softmmu targets and then for user targets. I suspect all of that is mostly to handle the reasonable "static-user" use case which is what people really want*. *I'm guessing -- Alex Bennée
On Fri, 14 Jun 2019 at 14:58, Alex Bennée <alex.bennee@linaro.org> wrote: > It would be nice to have a --static-user config flag and deprecate the > --static flag. I don't think there is a decent use case for system > emulation targets. It would be really tricky to build half with static and half without: our configure and build system really assumes that fundamental stuff like "what libraries" and "what compiler flags" are the same across the whole of the build. Is --static-user really much better than: * allow --static --disable-system --disable-tools * forbid --static without --disable-system --disable-tools * require users to build the static usermode binaries separately from the system/tools build (which is in practice what we have now) ? Debian wants both static usermode and non-static usermode binaries, so they'd still need to build multiple times anyway. thanks -- PMM
On 6/14/19 4:30 PM, Peter Maydell wrote: > On Fri, 14 Jun 2019 at 14:58, Alex Bennée <alex.bennee@linaro.org> wrote: > >> It would be nice to have a --static-user config flag and deprecate the >> --static flag. I don't think there is a decent use case for system >> emulation targets. > > It would be really tricky to build half with static and half > without: our configure and build system really assumes that > fundamental stuff like "what libraries" and "what compiler flags" > are the same across the whole of the build. > > Is --static-user really much better than: > * allow --static --disable-system --disable-tools > * forbid --static without --disable-system --disable-tools > * require users to build the static usermode binaries separately > from the system/tools build > > (which is in practice what we have now) ? > > Debian wants both static usermode and non-static usermode > binaries, so they'd still need to build multiple times anyway. Glad to read, so the v2 of this series is worthful.