You are not logged in.
Pages: 1
Hello everyone, I'm new to this forum and as many newbies I've come with an issue related to Arch Linux. I've been using Arch for the past 2 and half years running a 64bit install of Arch. What I am interested now is why gcc package, the 64bit version, comes with a lib32 directory that's populated by some files:
┌(kagaroth)─(Shouryuu)─(4.14.12-1-ARCH)
└─(download)─(11 files, 5,0GB)─ $ la /usr/lib32/
total 4,7M
drwxr-xr-x 2 root root 4,0K 09.01.2018 14:03 ./
drwxr-xr-x 9 root root 4,0K 09.01.2018 14:03 ../
-rw-r--r-- 1 root root 7,9K 07.01.2018 21:44 libasan_preinit.o
-rw-r--r-- 1 root root 173 07.01.2018 21:44 libcilkrts.spec
-rw-r--r-- 1 root root 169 07.01.2018 21:44 libgomp.spec
-rw-r--r-- 1 root root 162 07.01.2018 21:44 libitm.spec
-rw-r--r-- 1 root root 156 07.01.2018 21:44 libmpx.spec
-rw-r--r-- 1 root root 320 07.01.2018 21:44 libsanitizer.spec
-rw-r--r-- 1 root root 3,8M 07.01.2018 21:44 libstdc++.a
-rw-r--r-- 1 root root 554K 07.01.2018 21:44 libstdc++fs.a
-rw-r--r-- 1 root root 301K 07.01.2018 21:44 libsupc++.aSeems like this appeared in gcc with version 7.x as in 6.3.1 there's no lib32 directory. Now is this okay? If I'm not mistaken .spec files are used to generate rpm packages so is this something that the devs forgot to remove from the package content?
I've checked ALA and gcc-6.3.1-2-x86_64.pkg.tar.xz have only the /usr/lib directory which is normal for a 64bit install.
┌(kagaroth)─(Shouryuu)─(4.14.12-1-ARCH)
└─(download)─(11 files, 5,0GB)─ $ sudo pacman -Qilp gcc-* | grep -iE "^name|^version|/lib32"
Name : gcc
Version : 6.3.1-2
Name : gcc
Version : 7.2.1-2
gcc /usr/lib32/
gcc /usr/lib32/libasan_preinit.o
gcc /usr/lib32/libcilkrts.spec
gcc /usr/lib32/libgomp.spec
gcc /usr/lib32/libitm.spec
gcc /usr/lib32/libmpx.spec
gcc /usr/lib32/libsanitizer.spec
gcc /usr/lib32/libstdc++.a
gcc /usr/lib32/libstdc++fs.a
gcc /usr/lib32/libsupc++.a
Name : gcc
Version : 7.2.1-3
gcc /usr/lib32/
gcc /usr/lib32/libasan_preinit.o
gcc /usr/lib32/libcilkrts.spec
gcc /usr/lib32/libgomp.spec
gcc /usr/lib32/libitm.spec
gcc /usr/lib32/libmpx.spec
gcc /usr/lib32/libsanitizer.spec
gcc /usr/lib32/libstdc++.a
gcc /usr/lib32/libstdc++fs.a
gcc /usr/lib32/libsupc++.a┌(kagaroth)─(Shouryuu)─(4.14.12-1-ARCH)
└─(download)─(11 files, 5,0GB)─ $ sudo pacman -Qilp /var/cache/pacman/pkg/gcc-7* | grep -iE "^name|^version|/lib32"
Name : gcc
Version : 7.2.1+20171224-1
gcc /usr/lib32/
gcc /usr/lib32/libasan_preinit.o
gcc /usr/lib32/libcilkrts.spec
gcc /usr/lib32/libgomp.spec
gcc /usr/lib32/libitm.spec
gcc /usr/lib32/libmpx.spec
gcc /usr/lib32/libsanitizer.spec
gcc /usr/lib32/libstdc++.a
gcc /usr/lib32/libstdc++fs.a
gcc /usr/lib32/libsupc++.a
Name : gcc
Version : 7.2.1+20171224-2
gcc /usr/lib32/
gcc /usr/lib32/libasan_preinit.o
gcc /usr/lib32/libcilkrts.spec
gcc /usr/lib32/libgomp.spec
gcc /usr/lib32/libitm.spec
gcc /usr/lib32/libmpx.spec
gcc /usr/lib32/libsanitizer.spec
gcc /usr/lib32/libstdc++.a
gcc /usr/lib32/libstdc++fs.a
gcc /usr/lib32/libsupc++.a
Name : gcc
Version : 7.2.1-2
gcc /usr/lib32/
gcc /usr/lib32/libasan_preinit.o
gcc /usr/lib32/libcilkrts.spec
gcc /usr/lib32/libgomp.spec
gcc /usr/lib32/libitm.spec
gcc /usr/lib32/libmpx.spec
gcc /usr/lib32/libsanitizer.spec
gcc /usr/lib32/libstdc++.a
gcc /usr/lib32/libstdc++fs.a
gcc /usr/lib32/libsupc++.a/usr/lib32/ is not a simlink to /usr/lib as is /usr/lib64/ but is a real directory residing on the filesystem.
Sorry I've looked around but saw no other topic related to this so called issue and also I'm not quite sure if this is the right place to post it.
Offline
This is a recent change following on from the dropping of 32-bit support. See https://lists.archlinux.org/pipermail/a … 29034.html
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
I'd guess that it has something to do with the recent merge of gcc-multilib into the gcc package.
Offline
Thank you very much. I saw the news about dropping 32bit support in 2017 but never thought the devs would merge gcc-multilib into gcc package.
PS: Should I mark this as solved as you have already answered my question by assing [Solved] to the title?
Offline
Pages: 1