Hi everyone, Recently, with David, we have introduced FAT library support on AIX to enable 64bit as default target (called gcc64 here). Currently, 32bit is the default (gcc32) and 64bit is just a multilib linked to -maix64 option. These FAT libraries are archives including both 32 and 64bit shared objects. To create them, we are retrieving the shared object of the missing architecture from its multilib directory (ppc32 for 32bit or ppc64 for 64bit) and adding it to the default library/archive. Here is, for example, the code for libatomic: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libatomic/config/t-aix;h=08607727574f3c376a43e9460c81ae6fbee0fc5f;hb=HEAD. The aims of these FAT libraries is to make programs created by gcc32 being able to run on the gcc64's runtime and vice versa. For example, "ppc32" directory is not present in gcc32, thus a 32bit program built with gcc64 (ie with -maix32 and the use of ppc32 directory) must be able to fallback on the toplevel FAT libraries.
By default, gcc is almost doing it already. The directories searched for libraries with a gcc64 32bit programs will have "/usr/lib/gcc/$target/$version/ppc32:/usr/lib/gcc/$target/$version/." or something similar. Thus, it will fallback on the FAT libraries under "/." if "/ppc32" isn't there. However, as AIX needs special handlers for threaded programs, we have two sets of FAT libraries, one in the toplevel directory "/." and one in the thread multilib directory "/pthread". The problem is that a gcc64 program compiled with both -pthread -maix32 will have a library path similar to "/pthread/ppc32:/.". Thus, the fallback is made on the toplevel FAT library and not the pthread one. We have tried several solutions in order to avoid this problem. First (and it's still the case in master), we have set "MUTLILIB_MATCHES = .=ppc32" for gcc64. That way, we are forcing 32bit programs to use the fallback directly instead of using its ppc32 directory. However, it creates too much problems as the toplevel directory is 64bit. The includes taken are sometimes wrong, the tests aren't using the right stuff, etc. I've also tried "MULTILIB_REUSE = pthread/ppc32=pthread", as "Target Fragment" doc page says "And for some targets it is better to reuse an existing multilib than to fall back to default multilib when there is no corresponding multilib. This can be done by adding reuse rules to MULTILIB_REUSE.". But it's not changing the search path as excepted. Thus, I'm wondering if there is a way to create a multilib hierarchy with several layers. Currently, there is only two layers: "use mutlilib directory then use default directory". What we would like is at least a 3-level layer: "use multilib directory then use another multilib directory then use default one". If it's not possible, I've several ideas about how it can be introduced and which part of gcc driver will need to be modified. But I want to be sure I'm not miss-using MULTILIB_REUSE first. Sincerely, Clément Chigot
