Products > Computers

gcc: x86_64-pc-linux-gnu >= i686-pc-linux-gnu ?

(1/4) > >>

DiTBho:
x86/64bit: x86_64-pc-linux-gnu
x86/32bit: { i486-pc-linux-gnu, i586-pc-linux-gnu, i686-pc-linux-gnu }

host: x86_64-pc-linux-gnu
target: i686-pc-linux-gnu


--- Code: ---do_crossdev_2024_v3 build
building i686-pc-linux-gnu ...
 * Refusing to create a cross-compiler using the same
 * target name as your host_utils.

--- End code ---

but host_utils are x86_64-pc-linux-gnu!

I'm a bit perplexed by this, also because it suggests using a wrapper

--- Code: ---sys-devel/multilib-gcc-wrapper ...
      i686-pc-linux-gnu-cpp
      i686-pc-linux-gnu-cc
      i686-pc-linux-gnu-gcc
      i686-pc-linux-gnu-c++
      i686-pc-linux-gnu-g++
      i686-pc-linux-gnu-gfortran

--- End code ---


--- Code: --- /usr/bin/i686-pc-linux-gnu-gcc
COLLECT_GCC=x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/12/lto-wrapper
Target: x86_64-pc-linux-gnu

--- End code ---


--- Code: ---/usr/bin/x86_64-pc-linux-gnu-gcc
COLLECT_GCC=/usr/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/12/lto-wrapper
Target: x86_64-pc-linux-gnu

--- End code ---

Is this how it works? it's correct? or did I mess up too much? :-//

DiTBho:
(
I'm planning a multi-library stage1-4
some 32bit and some 64bit
I need two toolchains, at least apparently

the new kernel will be 64bit only
as I need to address 8Gbyte of RAM
)

SiliconWizard:
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.)

DiTBho:

--- Quote from: SiliconWizard on April 12, 2024, 04:51:07 am ---I'm not completely sure I got your issue here.

--- End quote ---

I 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 architectures

ARM
aarch64-unknown-linux-gnu-12
armv5tel-softfloat-linux-gnueabi-12
armv7a-unknown-linux-gnueabihf-12

HPPA
hppa-unknown-linux-gnu-12
hppa64-unknown-linux-gnu-12

x86
i686-pc-linux-gnu-11,12
x86_64-pc-linux-gnu-12

MIPS
loongarch64-unknown-linux-gnu (actually, this is not MIPS64 compatibile at the binary level)
mips-unknown-linux-gnu
mips64-unknown-linux-gnu
mipsel-unknown-linux-gnu ("el" means little endian, this compiles for the SONY Playstation1, as well as for MK routers)
mips64el-unknown-linux-gnu
mips5p-myc (this compiles for MIPS5++, it's my compiler, myc forced to "c/89" compatibility, which is 90%)

PPC
powerpc-unknown-linux-gnu-13
powerpc64-unknown-linux-gnu-13

RISCV
riscv-unknown-linux-gnu-13
riscv64-unknown-linux-gnu-13



--- Quote from: SiliconWizard on April 12, 2024, 04:51:07 am ---But if you're wondering about which gcc supports what, historically the x86_64 targets well, AMD64 and i686, 32-bit x86 CPUs.

--- End quote ---

Yup, precisely  :D

crossdev was written by Vapier (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) crossdev has no problems keeping separate

i686-pc-linux-gnu-11 * <------------ host compiler
x86_64-pc-linux-gnu-12 * <----------- crosscompiler

While on x86_64 stage4 (on my new mac-mini 2009 with 8GB of ram) crossdev suggests using gcc_x86_64 also for { i486, i586, i686 }, which is ... a bit weird for me  :-//

x86_64-pc-linux-gnu-12 * <----------- host compiler
i686-pc-linux-gnu-11 * <------------ should be *THE* cross compiler, but crossdev refuses 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 am ---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.)

--- End quote ---

from the standard profile, it has been configured:

--- Quote ---/var/tmp/portage/sys-devel/gcc-12.2.1_p20230121-r1/work/gcc-12-20230121/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/12 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/12/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/12 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/12/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/12/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/12/include/g++-v12 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/12/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 12.2.1_p20230121-r1 p10' --with-gcc-major-version-only --disable-esp --enable-libstdcxx-time --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp --disable-libada --disable-cet --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --without-zstd --enable-lto --without-isl --enable-default-pie --enable-default-ssp

--- End quote ---

ummm  :o

Nominal Animal:
For what it is worth, here is how I'd investigate the issue.
* The error message is generated in crossdev Bash script, whenever HCHOST == CTARGET.

My first step would be to add a debug echo "HCHOST='${HCHOST}' == CTARGET='${CTARGET}'" before the exit, and rerun.
 
* HCHOST is a copy of CHOST, only set in the setup_portage_vars() function, via portageq envvar -v CHOST.  That is, its value is set by Portage, per /var/db/repos/gentoo/profiles/info_vars.
 
* CTARGET is parsed from the command line (-t TARGET), with the optional cross- or cross_llvm- prefix omitted.  I do believe this is i686-pc-linux-gnu.I believe the added debug echo would output
    HCHOST='i686-pc-linux-gnu' == CTARGET='i686-pc-linux-gnu'
which would indicate that for whatever reason, your Portage CHOST is misconfigured to i686-pc-linux-gnu instead of the x86_64-pc-linux-gnu one would expect; i.e. that the problem is Portage configuration in /var/db/repos/gentoo/profiles/info_vars not 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 (to x86_64-pc-linux-gnu) and rerun.

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod