guests/lcitool | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
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
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2024 Red Hat, Inc.