Created attachment 456014 [details, diff] arm64 profiles patch Patch attached bellow * switches arm64 profiles to 64bit-native parent (from multilib parent) fixing: - split lib/lib64 dirs (without lib symlink) * Set default CHOST and folks (earlier it wasnt set at all) fixing: - #600590 and all simmilar problems All of arm64 profiles are all singlelib profiles without any multilib support. Implementing multilib for arm64 will require changes to toolchain.eclass and folks to support "multibuilding" gcc (separately compiling gcc for each abi target and packaging it together) or support some form of sloting ala crossdev since gcc cant do biarch for aarch64linux* and armelf*_linux_eabi. If in doubt check /usr/portage/eclass/multilib.eclass:305: "Not possible to do multilib with aarch64 and a single toolchain." Note: dont confuse armelf*_linux_eabi with aarch64linux32* arch aka aarch64*-ilp32 (-mabi=ilp32) which is artificial linaro propsed architecture somewhat simmilar to x32 on x86 but since armv7 doesnt have register starvation problems it doesnt give any noticable performance differences. This ABI is not compatible with armv7 nor isnt finished/agreed on and is missing kernel/glibc support. Source: https://wiki.linaro.org/Platform/arm64-ilp32 Note2: Add eselect news informing users to perfom by hand transition to symlinked lib: busybox ash -c "mv -n /lib/* /lib64; rm -rf /lib; ln -s lib64 /lib" busybox ash -c "mv -n /usr/lib/* /usr/lib64; rm -rf /usr/lib; ln -s lib64 /usr/lib" emerge -v1 baselayout
the current profiles already do not enable symlinking of /lib dirs, nor do we want to do that. your change would break that and change /lib to a symlink to /lib64. we also don't want to change the parent so arm64 always uses little endian. that should be structured differently in the downstream profiles (e.g. linux/arm64/).
about current state of arm64 profile: # ls -la /lib total 40 drwxr-xr-x 7 root root 4096 Mar 24 2016 . drwxr-xr-x 20 root root 4096 Feb 17 2016 .. -rwxr-xr-x 1 root root 10272 Mar 24 2016 cpp drwxr-xr-x 2 root root 4096 Mar 24 2016 gentoo lrwxrwxrwx 1 root root 30 Mar 24 2016 ld-linux-aarch64.so.1 -> ../lib64/ld-linux-aarch64.so.1 drwxr-xr-x 2 root root 4096 Mar 24 2016 modprobe.d drwxr-xr-x 4 root root 4096 Mar 24 2016 netifrc drwxr-xr-x 3 root root 4096 Mar 24 2016 systemd drwxr-xr-x 4 root root 4096 Mar 24 2016 udev # ls -la /lib64 total 5876 drwxr-xr-x 5 root root 4096 Mar 24 2016 . drwxr-xr-x 20 root root 4096 Feb 17 2016 .. -rwxr-xr-x 1 root root 120160 Mar 24 2016 ld-2.21.so lrwxrwxrwx 1 root root 10 Mar 24 2016 ld-linux-aarch64.so.1 -> ld-2.21.so -rwxr-xr-x 1 root root 5872 Mar 24 2016 libBrokenLocale-2.21.so lrwxrwxrwx 1 root root 23 Mar 24 2016 libBrokenLocale.so.1 -> libBrokenLocale-2.21.so -rwxr-xr-x 1 root root 10104 Mar 24 2016 libSegFault.so ... (simmilar in /usr/lib vs /usr/lib64) Is this as intended? lib vs lib64 split on singlelib profile (other way we could change it is to migrate lib64 -> lib by just removing ../../features/multilib from profiles/arch/arm64/parent that way there wouldnt be any lib symlink but neither /lib64) As for big endian stuff we could just make default/linux/arm64_be/13.0 or default/linux/arm64/big-endian/13.0 and parent default/linux/arm64 (even if it includes little-endian) + profiles/arch/arm64/big-endian so it overrides. But we would have set as something default CHOST_arm64 in all cases.
(In reply to torindel from comment #2) yes, that output of /lib and /lib64 is correct and what we want. /lib is for arm32 code since the kernel/hardware can support both simultaneously. we use the correct paths all the time regardless of # of multilibs you intend on using. it's the same for amd64 -- /lib64 is for x86_64 code and /lib is for x86 32-bit code even if you don't have any 32-bit code.
(In reply to SpanKY from comment #3) > (In reply to torindel from comment #2) > > we use the correct paths all the time regardless of # of multilibs you > intend on using. it's the same for amd64 -- /lib64 is for x86_64 code and > /lib is for x86 32-bit code even if you don't have any 32-bit code. on amd64 /lib64 is for x86_64 and /lib32 is for x86 32-bit code while /lib is symlink to /lib64 on non multilib amd64 profiles situation is the same in regard to /lib and it is symlink to /lib64 while all x86_64 code goes to /lib64 So its not the same as for amd64. The patch i am proposing is to make situation simmilar to nomultilib amd64. Plus dont forget that if you use any multilib like parent - regardles is it features/multilib or features/64bit-native you must set value for CHOST_arm64 in profile as eclasses require it to be set. # eselect profile list Available profile symlink targets: [1] default/linux/amd64/13.0 * [2] default/linux/amd64/13.0/selinux ... # ls -lad /lib* lrwxrwxrwx 1 root root 5 Dec 4 17:08 /lib -> lib64 drwxr-xr-x 2 root root 4096 Dec 4 17:08 /lib32 drwxr-xr-x 15 root root 12288 Dec 16 01:37 /lib64 (stage3-amd64-nomultilib-20161215.tar.bz2 stage:) # eselect profile list Available profile symlink targets: ... [10] default/linux/amd64/13.0/developer [11] default/linux/amd64/13.0/no-multilib * [12] default/linux/amd64/13.0/systemd ... # ls -lad /lib* lrwxrwxrwx 1 root root 5 Dec 15 09:38 /lib -> lib64 drwxr-xr-x 9 root root 4096 Dec 15 10:51 /lib64
(In reply to torindel from comment #4) > (In reply to SpanKY from comment #3) > > (In reply to torindel from comment #2) > > > > we use the correct paths all the time regardless of # of multilibs you > > intend on using. it's the same for amd64 -- /lib64 is for x86_64 code and > > /lib is for x86 32-bit code even if you don't have any 32-bit code. > > on amd64 /lib64 is for x86_64 and /lib32 is for x86 32-bit code while /lib > is symlink to /lib64 > on non multilib amd64 profiles situation is the same in regard to /lib and > it is symlink to /lib64 while all x86_64 code goes to /lib64 > So its not the same as for amd64. The patch i am proposing is to make > situation simmilar to nomultilib amd64. The libdirs you are citing are wrong and deprecated for this purpose. The only reason we're still using them on amd64 is that we haven't prepared a proper migration path yet. > Plus dont forget that if you use any multilib like parent - regardles is it > features/multilib or features/64bit-native you must set value for > CHOST_arm64 in profile as eclasses require it to be set. That's a separate bug, I'm going to fix it as #600590.
