Adding the following configuration to the default local.conf file: MACHINE = "qemumips64" MULTILIBS ?= "multilib:lib32 multilib:lib64" DEFAULTTUNE = "mips64-n32" DEFAULTTUNE_virtclass-multilib-lib32 ?= "mips32r2" DEFAULTTUNE_virtclass-multilib-lib64 ?= "mips64" IMAGE_INSTALL_append = " lib64-bash lib32-bash bash" will produce a working image. However, if you add the following to select a specific 'preferred' package (see the comments), rpm4 is not able to distinguish between MIPS64 and MIPS64 n32. # Set RPM_PREFER_ELF_ARCH to configure preferred ABI when using rpm packaging # backend to generate a rootfs, choices are: # 1: ELF32 wins # 2: ELF64 wins # 4: ELF64 N32 wins (for mips64 or mips64el only) RPM_PREFER_ELF_ARCH ?= "1" When added this results in: ... Install 429 Packages Total size: 36 M Installed size: 94 M Running transaction check Transaction check succeeded. Running transaction test Error: Transaction check error: file /sbin/ldconfig conflicts between attempted installs of lib64-libc6-2.25-r0.mips64 and libc6-2.25-r0.mips64_n32 file /bin/bash.bash conflicts between attempted installs of bash-4.3.30-r0.mips64_n32 and lib64-bash-4.3.30-r0.mips64 Error Summary ------------- ERROR: core-image-base-1.0-r0 do_rootfs: Function failed: do_rootfs
We should be able to use rpm5's model of processing MIPS64 n32, and the necessary changes to the ELF resolution processing (make it 3-way not 2-way). rpm.org headers already have the MIPS64_n32 'file color' defined, but the rest of the system is lacking in the processing for this. The same processing is likely needed for IA32 x32 ABI as well. Since this is a deficiency in rpm4, the code should be created and submitted back to that organization as part of this work.
Can you find the code in rpm5 source tree where this is happening?
Also note that rpm4 people arent't particularly fond even of two-way ELF resolution (from lib/transaction.c): /* * Elf files can be "colored", and if enabled in the transaction, the * color can be used to resolve conflicts between elf-64bit and elf-32bit * files to the hosts preferred type, by default 64bit. The non-preferred * type is overwritten or never installed at all and thus the conflict * magically disappears. This is infamously nasty "rpm magic" and entirely * unnecessary with careful packaging. */ They may have a point. Why do you want to install three bash packages even though only one actual executable binary will be available?
> Can you find the code in rpm5 source tree where this is happening? yes, I will try to track these down > Why do you want to install three bash packages even though only one actual executable binary will be available? bash is just an example to illustrate the problem. The more typical case is with something like python. The typical case is you have the need for a large database on your RISC based system. So you want the main system to be 32-bit (or in a MIPS64 case, MIPS64-n32) while having the database and the associated programs that use the database as being 64-bit. By choosing the 64-bit DB, you've now introduced dependencies on 64-bit glibc and other components as well. Some of these components will most often include both executables and libraries. The libraries by their nature will not conflict by filename, however standard binaries (such as ldconfig) very well may. (Often the database engine comes with libraries as well, as you may need both the 32-bit and 64-bit installed at the same time.) In addition, you often need to define the system so that a particular class of binaries, when requested, take precedence or you run into the situation where things might not even work. (again, take ldconfig as an example -- the 64-bit version is capable of parsing both 64-bit and 32-bit. However the 32-bit version usually can not parse the 64-bit libraries.) Add to this the complication that MIPS64 has (depending on how you look at it) two 32-bit ELF ABIs or two 64-bit ELF ABIs. (In this case, RPM4 is treating MIPS64-n32 and MIPS64 as both 64-bit.) The other complication on MIPS (and even CISC architectures like arm and ia), they often was their primary binaries to be 64-bit for performance, but may need 32-bit binaries for compatibility sake. So in the MIPS case, you can end up with a valid system that has: MIPS64 64-bit select binaries/libraries MIPS64 32-bit primary use on the system MIPS32 32-bit select binaries/libraries for compatibility with old software
The code in the transaction.c is currently two state either new file or old file matches the preferred color. However in the tri-lib system there is a third state that neither the old nor new match the preferred color. In that case RPM 5 simply installs both files and rpm ignores the conflict itself. I will try to implement this behavior on rpm4.
The code supports dual-arch, but tri-arch is not working. This issue is open in the rpm.org issue tracker: https://github.com/rpm-software-management/rpm/issues/193 Unfortunately we do not yet have a solution to the issue, and I am no longer working on it. I've been unable to resolve the problem in a consistent way. I've asked for help from the upstream, but so far they have not been interested in this issue.
No further progress to report on this issue. I've not been able to determine the flow to implement a tri-lib resolution.
MIPS support is deprecate and is no longer being tested.