gcc: x86_64-pc-linux-gnu >= i686-pc-linux-gnu ? - Page 1
Forum section: electronics / general

author: DiTBho
author_rank: Super Contributor
timestamp: April 11, 2024, 11:53:58 am
content: x86/64bit: x86_64-pc-linux-gnux86/32bit: { i486-pc-linux-gnu, i586-pc-linux-gnu, i686-pc-linux-gnu }host: x86_64-pc-linux-gnutarget: i686-pc-linux-gnuCode:do_crossdev_2024_v3 buildbuilding i686-pc-linux-gnu ...* Refusing to create a cross-compiler using the same* target name as your host_utils.but host_utils are x86_64-pc-linux-gnu!I'm a bit perplexed by this, also because it suggests using a wrapperCode:sys-devel/multilib-gcc-wrapper ...i686-pc-linux-gnu-cppi686-pc-linux-gnu-cci686-pc-linux-gnu-gcci686-pc-linux-gnu-c++i686-pc-linux-gnu-g++i686-pc-linux-gnu-gfortranCode:/usr/bin/i686-pc-linux-gnu-gccCOLLECT_GCC=x86_64-pc-linux-gnu-gccCOLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/12/lto-wrapperTarget: x86_64-pc-linux-gnuCode:/usr/bin/x86_64-pc-linux-gnu-gccCOLLECT_GCC=/usr/bin/x86_64-pc-linux-gnu-gccCOLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/12/lto-wrapperTarget: x86_64-pc-linux-gnuIs this how it works? it's correct? or did I mess up too much?

author: DiTBho
author_rank: Super Contributor
timestamp: April 11, 2024, 12:08:26 pm
content: (I'm planning a multi-library stage1-4some 32bit and some 64bitI need two toolchains, at least apparentlythe new kernel will be 64bit onlyas I need to address 8Gbyte of RAM)

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 12, 2024, 04:51:07 am
content: I'm not completely sure I got your issue here. But if you're wondering about which gcc supports what, historically the x86_64 targets well, AMD64 and i686, 32-bit x86 CPUs.But I think you can use just a x86_64 gcc and generate 32-bit code with it using the -m32 option flag. (Unless possibly 32-bit support has been disabled when building it, which is possible.)

author: DiTBho
author_rank: Super Contributor
timestamp: April 12, 2024, 09:23:27 am
content: Quote from: SiliconWizard on April 12, 2024, 04:51:07 amI have written several builders that, for different reasons, need to work with a specific toolchain for an architecture/bit, so I treat them *like if* they were completely different architecturesARMaarch64-unknown-linux-gnu-12armv5tel-softfloat-linux-gnueabi-12armv7a-unknown-linux-gnueabihf-12HPPAhppa-unknown-linux-gnu-12hppa64-unknown-linux-gnu-12x86i686-pc-linux-gnu-11,12x86_64-pc-linux-gnu-12MIPSloongarch64-unknown-linux-gnu (actually, this is not MIPS64 compatibile at the binary level)mips-unknown-linux-gnumips64-unknown-linux-gnumipsel-unknown-linux-gnu ("el" means little endian, this compiles for the SONY Playstation1, as well as for MK routers)mips64el-unknown-linux-gnumips5p-myc (this compiles for MIPS5++, it's my compiler, myc forced to "c/89" compatibility, which is 90%)PPCpowerpc-unknown-linux-gnu-13powerpc64-unknown-linux-gnu-13RISCVriscv-unknown-linux-gnu-13riscv64-unknown-linux-gnu-13Quote from: SiliconWizard on April 12, 2024, 04:51:07 amYup, preciselycrossdevwas written byVapier(Gentoo dev), I'm trying to understand a bit of his motivations.Given that on x86_32 stage4 (like in the exable above, taken from my old macmini 2009 with 2GB of ram, running both 32bit kernel and 32bit userland)crossdevhas no problems keeping separatei686-pc-linux-gnu-11 * <------------ host compilerx86_64-pc-linux-gnu-12 * <----------- crosscompilerWhile on x86_64 stage4 (on my new mac-mini 2009 with 8GB of ram)crossdevsuggests using gcc_x86_64 also for { i486, i586, i686 }, which is ... a bit weird for mex86_64-pc-linux-gnu-12 * <----------- host compileri686-pc-linux-gnu-11 * <------------ should be *THE* cross compiler, butcrossdevrefuses to emerge, suggests templates to the host compiler...and I wonder... if this is okay.Quote from: SiliconWizard on April 12, 2024, 04:51:07 amfrom the standard profile, it has been configured:Quoteummm

author: Nominal Animal
author_rank: Super Contributor
timestamp: April 12, 2024, 02:51:53 pm
content: For what it is worth, here is how I'd investigate the issue.The error message is generated incrossdevBash script, wheneverHCHOST == CTARGET.My first step would be to add a debugecho "HCHOST='${HCHOST}' == CTARGET='${CTARGET}'"before theexit, and rerun.HCHOSTis a copy ofCHOST, only set in thesetup_portage_vars()function, viaportageq envvar -v CHOST. That is, its value is set by Portage, per/var/db/repos/gentoo/profiles/info_vars.CTARGETis parsed from the command line (-t TARGET), with the optionalcross-orcross_llvm-prefix omitted. I do believe this isi686-pc-linux-gnu.Ibelievethe added debug echo would outputHCHOST='i686-pc-linux-gnu' == CTARGET='i686-pc-linux-gnu'which would indicate that for whatever reason, your Portage CHOST is misconfigured toi686-pc-linux-gnuinstead of thex86_64-pc-linux-gnuone would expect; i.e. that the problem is Portage configuration in/var/db/repos/gentoo/profiles/info_varsnot matching the hardware.Assuming this is the case, I'd investigate why that would be the case, and if there is no overriding reason, change it (tox86_64-pc-linux-gnu) and rerun.

author: DiTBho
author_rank: Super Contributor
timestamp: April 12, 2024, 04:14:26 pm
content: Quote from: Nominal Animal on April 12, 2024, 02:51:53 pmI will.Indeed, it sounds weird.I mean, in the list above I didn't forget to mention PowerPC/LE, because all the IBM POWER9 machines were forced BE, but note that the POWER9 is a PPC64/BE and I have emerged a PPC/BE compiler to compile for the PowerMac-G4powerpc-unknown-linux-gnu-13 <----------- cross compilerpowerpc64-unknown-linux-gnu-13 <----------- host compilerSo, we will see for x86

author: DiTBho
author_rank: Super Contributor
timestamp: April 12, 2024, 04:49:36 pm
content: Code:...if [[ ${HCHOST} == "${CTARGET}" ]] ; theneerror "Refusing to create a cross-compiler using the same target name as your host utils."echo "tp1: suppa debug:"echo " HCHOST='${HCHOST}'"echo " CTARGET='${CTARGET}'"echo " HCHOST='${HCHOST}' == CTARGET='${CTARGET}'"exit 1fifor hchost in "${HCHOSTS[@]}"; doif [[ ${hchost} == "${CTARGET}" ]] ; theneerror "Refusing to create a cross-compiler using the same target name as your host utils."eerror "Consider using sys-devel/multilib-gcc-wrapper package."echo "tp2: suppa debug:"echo " HCHOST='${HCHOST}'"echo " CTARGET='${CTARGET}'"echo " hchost='${hchost}'"echo " HCHOST='${HCHOST}' == CTARGET='${CTARGET}'"echo " hchost='${hchost}' == CTARGET='${CTARGET}'"exit 1fi...(/usr/bin/crossdev)Code:do_crossdev_2024_v3 buildbuilding i686-pc-linux-gnu ...* Refusing to create a cross-compiler using the same target name as your host utils.* Consider using sys-devel/multilib-gcc-wrapper package.tp2: suppa debug:HCHOST='x86_64-pc-linux-gnu'CTARGET='i686-pc-linux-gnu'hchost='i686-pc-linux-gnu'HCHOST='x86_64-pc-linux-gnu' == CTARGET='i686-pc-linux-gnu'hchost='i686-pc-linux-gnu' == CTARGET='i686-pc-linux-gnu'

author: DiTBho
author_rank: Super Contributor
timestamp: April 12, 2024, 04:50:26 pm
content: hchost='i686-pc-linux-gnu'this is wrong!

author: Nominal Animal
author_rank: Super Contributor
timestamp: April 12, 2024, 05:47:22 pm
content: Right, so it isHCHOSTSincrossdevthat contains thei686-pc-linux-gnu. This is obtained from Portage in two steps, by looking up all ABI names usingportageq envvar ABI MULTILIB_ABIS DEFAULT_ABIand then adding each architecture obtained usingportageq envvar CHOST_ABItoHCHOSTS.Could you run and show the output ofCode:for evar in ABI MULTILIB_ABIS DEFAULT_ABI; doprintf 'portageq envvar %s = "%s"\n' "$evar" "$(portageq envvar $evar)" ; dofor abi in $(portageq envvar $evar); doprintf 'portageq envvar CHOST_%s = "%s"\n' "$abi" "$(portageq envvar "CHOST_$abi")"donedoneAlso, runninggrep -e i686-pc-linux-gnu /var/db/repos/gentoo/profiles/info_varswould be informative.I believe that the core issue is that because the host x86_64 GCC supports 32-bit x86 targets via the-m32option, the Portage environment variables are configured to listi686_pc_linux_gnuas one of the multilib targets supported (via MULTILIB_ABIS).However, because this is a dedicated compatibility gcc option and not an actual direct target, I do believe simply editing out the compatibility arch from the portage config, or simply omitting this check incrossdev, should allow the script to generate a proper cross compiler. I could be wrong, though, because I haven't tried to create a gcc cross compiler with i686 target from x86-64 host myself.

author: DiTBho
author_rank: Super Contributor
timestamp: April 12, 2024, 08:44:42 pm
content: Code:portageq envvar ABI = "amd64"portageq envvar CHOST_amd64 = "x86_64-pc-linux-gnu"portageq envvar MULTILIB_ABIS = "amd64 x86"portageq envvar CHOST_amd64 = "x86_64-pc-linux-gnu"portageq envvar CHOST_x86 = "i686-pc-linux-gnu"portageq envvar DEFAULT_ABI = "amd64"portageq envvar CHOST_amd64 = "x86_64-pc-linux-gnu"Code:grep -e i686-pc-linux-gnu /usr/portage/profiles/info_vars<--- no result

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 12, 2024, 09:40:08 pm
content: Quote from: DiTBho on April 12, 2024, 09:23:27 amFrom what I can tell, it has been configured to support both 32-bit & 64-bit (--enable-multilib --with-multilib-list=m32,m64), so it should be usable to generate both 32-bit and 64-bit objects/executables.

author: DiTBho
author_rank: Super Contributor
timestamp: April 13, 2024, 08:59:24 am
content: Quote from: SiliconWizard on April 12, 2024, 09:40:08 pmyup, Thanks for confirming that it can technically be doneit took only 20 hours to complete on my two nodes mac-mini intel cluster, thanks to distcc + MPI.This morning I got a new stage3, this time with separate toolchainsCode: i686-pc-linux-gnu-13 <----------- it only generates 32bit (cross-compiler) x86_64-pc-linux-gnu-13 <----------- it only generates 64bit (host-compiler)(Host Portage ARCH: amd64)Now I wonder:A) keep it and make it stage4B) use the default (gentoo) one, and make it stage4that's the question

author: DiTBho
author_rank: Super Contributor
timestamp: April 13, 2024, 09:05:13 am
content: ummm, look hereCode:# ls -l binbin -> usr/bin# ls -l sbinsbin -> usr/bin# ls -l liblib -> usr/lib# ls -l lib64lib64 -> usr/lib64I hadn't noticed it before{ bin, sbin, lib, lib64 } are links to usr/*

author: Nominal Animal
author_rank: Super Contributor
timestamp: April 13, 2024, 09:12:39 am
content: Quote from: SiliconWizard on April 12, 2024, 09:40:08 pmFully agreed. In Portage, this shows up asMULTILIB_ABIS="amd64x86", withCHOST_x86="i686_pc_linux_gnu"tellingcrossdevno cross compiler is needed for that target.In practice, it means that when you use the-m32gcc option, it will look for dynamic libraries under e.g./lib/i?86-linux-gnu/instead of/lib/x86_64-linux-gnu/.I see two workable solutions for this dilemma.One is to recompile the host gcc as non-multilib.The other is to ensure-m32 -march=i686 -mtune=i686or equivalent is passed to the host compiler when compiling for 32-bit targets. Unfortunately, while you already have a wrapper script that does this, it does not change thegcc -vorgcc -dumpmachineoutputs.Edit: Ninja'd by DiTBho himself! Yes, I'd use the non-multilib gcc x86_64/amd64 host, and cross-compiler for i686, that you just got compiled, and proceed forwards with those. The 32/64-bit multilib is useful when you have precompiled 32-bit binaries or object files you want to run or link on the host; when you do not have such, you do not need a multilib compiler either. (It is notable that the Linux kernel itself uses different mechanisms for x86 and amd64/x86_64 syscalls, so there is no "switch": both 32-bit and 64-bit intel/amd kernel syscall interfaces are available all the time for userspace applications. You can verify this yourself if you want to, by writing a small inline extended assembly wrapper for saywritesyscall, using both x86 and amd64 syscall ABIs.)

author: DiTBho
author_rank: Super Contributor
timestamp: April 13, 2024, 01:28:59 pm
content: @Nominal Animaldo you use Gentoo, too?

author: Nominal Animal
author_rank: Super Contributor
timestamp: April 13, 2024, 02:04:20 pm
content: Quote from: DiTBho on April 13, 2024, 01:28:59 pmNope.I believe I did a test install well over a decade ago, but decided it wasn't for me; haven't used Gentoo since.

author: DiTBho
author_rank: Super Contributor
timestamp: April 13, 2024, 02:55:34 pm
content: I've been using Gentoo since pre-beta in 2004, for 20 yearsMany things have changed, now this crazy idea of throwing all the bin and sbin files into /usr ... bah ...Code:macmini2-intel /mnt/disk3/src/machine/platform/x86/net5501/kernel/kernel-5.15.093-x86-net5501 # ./mybuild-2024 2 compilingkernel-5.15.093(x86/net5501)| experimental, vanilla + { my, OpenWRT } patchestoolchain(i686-pc-linux-gnu:2.39.0/13.2.0)-----------------------------------------------checking myhost as qualified_host ... (speculative) successchecking .config ... successchecking blobs ... success-----------------------------------------------gadget_to_do(build) ... kernel/buildcleaning .............. donegadget_to_do(clean) ... kernel/cleanbuilding kernel ...This is the practical reason why it is so important on the new stage4 amd64The kernels and the various firmwares are compiled by a builder, which manages everything by profiles.Therefore which machine can compile, with which toolchain, and C/as compiler version.And this is used to keep track of the various work environments (toolchain and ecosystem) which have thus produced working results.Working with several virtual machines and chroots, I've had bad surprises in the past and this is the only clean way to proceedSo, I have a variable in /etc/ that takes into account the new stage4 just produced, it will have a unique ID, which, if good, will be trusted as "qualified host".For now I have just speculatively assumed that it "can produce" a working kernel (i.e. that both the compilers work and ecosystem { perl, python, ...} ).Then I will verify the matter, and if it passes I will definitively add the new stage4 to the list of Qualified Hosts!Although it uses an AMD Geode i686-compatible CPU, so although it's an x86 machine, I really like that net5501 router

author: DiTBho
author_rank: Super Contributor
timestamp: April 13, 2024, 03:03:45 pm
content: the new 64bit versionCode:# myhostmacmini2-intel/v19.5-2024-04-amd64(will stay in a chroot until it is mature enough)the old 32bit versionCode:# myhostmacmini2-intel/v17.0-2020-08-i686(will be replaced and archived)