[libvirt] [jenkins-ci PATCH] lcitool: add special case for Debian i386/i686 mixup
Although the toolchain binaries for 32-bit x86 are using the ABI i686-linux-gnu, the library install directory is strangely named with the different i386-linux-gnu. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- guests/lcitool | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/guests/lcitool b/guests/lcitool index 76b2dc7..0f60704 100755 --- a/guests/lcitool +++ b/guests/lcitool @@ -101,6 +101,13 @@ class Util: raise Exception("Unsupported architecture {}".format(native_arch)) return archmap[native_arch] + @staticmethod + def native_arch_to_lib(native_arch): + arch = Util.native_arch_to_abi(native_arch) + if arch == "i686-linux-gnu": + arch = "i386-linux-gnu" + return arch + @staticmethod def native_arch_to_deb_arch(native_arch): archmap = { @@ -640,12 +647,14 @@ class Application: if args.cross_arch: deb_arch = Util.native_arch_to_deb_arch(args.cross_arch) abi = Util.native_arch_to_abi(args.cross_arch) + lib = Util.native_arch_to_lib(args.cross_arch) gcc = "gcc-" + abi varmap["cross_arch"] = deb_arch pkg_names = [p + ":" + deb_arch for p in cross_pkgs.values()] pkg_names.append(gcc) varmap["cross_pkgs"] = " \\\n ".join(sorted(set(pkg_names))) varmap["cross_abi"] = abi + varmap["cross_lib"] = lib sys.stdout.write(textwrap.dedent(""" RUN export DEBIAN_FRONTEND=noninteractive && \\ @@ -673,7 +682,7 @@ class Application: ENV ABI "{cross_abi}" ENV CONFIGURE_OPTS "--host={cross_abi} \\ --target={cross_abi}" - ENV PKG_CONFIG_LIBDIR "/usr/lib/{cross_abi}/pkgconfig" + ENV PKG_CONFIG_LIBDIR "/usr/lib/{cross_lib}/pkgconfig" """).format(**varmap)) elif package_format == "rpm": if os_name == "Fedora" and os_version == "Rawhide": -- 2.20.1
On Thu, Mar 14, 2019 at 05:52:17PM +0000, Daniel P. Berrangé wrote:
Although the toolchain binaries for 32-bit x86 are using the ABI i686-linux-gnu, the library install directory is strangely named with the different i386-linux-gnu.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> ---
so the patch looks good to me, so I can give you my: Reviewed-by: Erik Skultety <eskultet@redhat.com> However, I wasn't able to find anything explaining this to help me understand, apart from: https://wiki.debian.org/Multiarch/Tuples but there's essentially no mention of i686. Erik
On Fri, Mar 15, 2019 at 11:27:48AM +0100, Erik Skultety wrote:
On Thu, Mar 14, 2019 at 05:52:17PM +0000, Daniel P. Berrangé wrote:
Although the toolchain binaries for 32-bit x86 are using the ABI i686-linux-gnu, the library install directory is strangely named with the different i386-linux-gnu.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> ---
so the patch looks good to me, so I can give you my: Reviewed-by: Erik Skultety <eskultet@redhat.com>
However, I wasn't able to find anything explaining this to help me understand, apart from: https://wiki.debian.org/Multiarch/Tuples
but there's essentially no mention of i686.
Yep, I've absolutely no clue why this mis-match exists. I just put it down as a historical accident they can't change. Whatever the cause, we have to live with it. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Fri, 2019-03-15 at 11:27 +0100, Erik Skultety wrote:
On Thu, Mar 14, 2019 at 05:52:17PM +0000, Daniel P. Berrangé wrote:
Although the toolchain binaries for 32-bit x86 are using the ABI i686-linux-gnu, the library install directory is strangely named with the different i386-linux-gnu.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> ---
so the patch looks good to me, so I can give you my: Reviewed-by: Erik Skultety <eskultet@redhat.com>
Agreed: Reviewed-by: Andrea Bolognani <abologna@redhat.com>
However, I wasn't able to find anything explaining this to help me understand, apart from: https://wiki.debian.org/Multiarch/Tuples
but there's essentially no mention of i686.
Basically if you look at eg. https://packages.debian.org/sid/amd64/gcc-aarch64-linux-gnu/filelist https://packages.debian.org/sid/arm64/libvirt0/filelist you'll see that the name of the cross-compiler contains the ABI name, and so does the library path: /usr/bin/aarch64-linux-gnu-gcc /usr/lib/aarch64-linux-gnu/libvirt.so.0 This is consistent for all Debian architectures *except* i386, where as seen in https://packages.debian.org/sid/amd64/gcc-i686-linux-gnu/filelist https://packages.debian.org/sid/i386/libvirt0/filelist the name of the cross-compiler still contains the ABI name, but the library path uses a slightly different triplet instead: /usr/bin/i686-linux-gnu-gcc /usr/lib/i386-linux-gnu/libvirt.so.0 This is the reason why we need to special-case this architecture when generating a cross-compilation environment. -- Andrea Bolognani / Red Hat / Virtualization
On Fri, Mar 15, 2019 at 12:06:13PM +0100, Andrea Bolognani wrote:
On Fri, 2019-03-15 at 11:27 +0100, Erik Skultety wrote:
On Thu, Mar 14, 2019 at 05:52:17PM +0000, Daniel P. Berrangé wrote:
Although the toolchain binaries for 32-bit x86 are using the ABI i686-linux-gnu, the library install directory is strangely named with the different i386-linux-gnu.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> ---
so the patch looks good to me, so I can give you my: Reviewed-by: Erik Skultety <eskultet@redhat.com>
Agreed:
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
However, I wasn't able to find anything explaining this to help me understand, apart from: https://wiki.debian.org/Multiarch/Tuples
but there's essentially no mention of i686.
Basically if you look at eg.
https://packages.debian.org/sid/amd64/gcc-aarch64-linux-gnu/filelist https://packages.debian.org/sid/arm64/libvirt0/filelist
you'll see that the name of the cross-compiler contains the ABI name, and so does the library path:
/usr/bin/aarch64-linux-gnu-gcc /usr/lib/aarch64-linux-gnu/libvirt.so.0
This is consistent for all Debian architectures *except* i386, where as seen in
https://packages.debian.org/sid/amd64/gcc-i686-linux-gnu/filelist https://packages.debian.org/sid/i386/libvirt0/filelist
the name of the cross-compiler still contains the ABI name, but the library path uses a slightly different triplet instead:
/usr/bin/i686-linux-gnu-gcc /usr/lib/i386-linux-gnu/libvirt.so.0
This is the reason why we need to special-case this architecture when generating a cross-compilation environment.
Thinking some more, I expect what happened is that the Debian 32-bit x86 arch did indeed generate code compatible with i386 and thus this library path got set. These days no one cares about true i386 compat, so the compiler toolchain is built to generate i686 compatible instructions, hence the compiler got the different name, but the library directory path remainined for back compat. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Fri, 2019-03-15 at 11:12 +0000, Daniel P. Berrangé wrote:
Thinking some more, I expect what happened is that the Debian 32-bit x86 arch did indeed generate code compatible with i386 and thus this library path got set. These days no one cares about true i386 compat, so the compiler toolchain is built to generate i686 compatible instructions, hence the compiler got the different name, but the library directory path remainined for back compat.
That's probably how we got here, yes. Still pretty annoying that the directory structure hasn't been amended after the change... -- Andrea Bolognani / Red Hat / Virtualization
participants (3)
-
Andrea Bolognani -
Daniel P. Berrangé -
Erik Skultety