[arch-general] packages installed to /usr/x86_64-unknown-linux-gnu and x86_64-unknown-uclibc -- broken??
Guys, Picking though /usr/ (because I've nothing better to do...) I ran across two directories that look like they do not belong where they are. The directories are: 02:19 alchemy:/usr> find x86_64-unknown-linux-gnu/ -type d x86_64-unknown-linux-gnu/ x86_64-unknown-linux-gnu/arm-elf x86_64-unknown-linux-gnu/arm-elf/lib x86_64-unknown-linux-gnu/arm-elf/include x86_64-unknown-linux-gnu/i486-mingw32 x86_64-unknown-linux-gnu/i486-mingw32/lib x86_64-unknown-linux-gnu/i486-mingw32/include 02:20 alchemy:/usr> find x86_64-unknown-linux-uclibc/ -type d x86_64-unknown-linux-uclibc/ x86_64-unknown-linux-uclibc/lib x86_64-unknown-linux-uclibc/lib/ldscripts x86_64-unknown-linux-uclibc/bin x86_64-unknown-linux-uclibc/include x86_64-unknown-linux-uclibc/include/net x86_64-unknown-linux-uclibc/include/sys x86_64-unknown-linux-uclibc/include/neteconet x86_64-unknown-linux-uclibc/include/bits x86_64-unknown-linux-uclibc/include/arpa x86_64-unknown-linux-uclibc/include/netinet x86_64-unknown-linux-uclibc/include/netipx x86_64-unknown-linux-uclibc/include/netpacket x86_64-unknown-linux-uclibc/include/rpc x86_64-unknown-linux-uclibc/include/scsi x86_64-unknown-linux-uclibc/include/netax25 x86_64-unknown-linux-uclibc/include/protocols I have an understanding of the files in x86_64-unknown-linux-gnu, but I don't know what the uclibc files are specifically (I mean I know libc, just not the uc part). There are a large number of files here: 02:20 alchemy:/usr> find x86_64-unknown-linux-uclibc/ -type f | wc -l 367 Full file list at: http://www.3111skyline.com/download/Archlinux/bugs/usr-x86-64-unknown.txt The file dates on the files are November 5th. These directories look like they should be somewhere else, so I'm putting it to the brain-trust, bug or feature?? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Does "pacman -Qo <some of this weird files>" return anything? On Tue, Dec 1, 2009 at 6:28 AM, David C. Rankin < drankinatty@suddenlinkmail.com> wrote:
Guys,
Picking though /usr/ (because I've nothing better to do...) I ran across two directories that look like they do not belong where they are. The directories are:
02:19 alchemy:/usr> find x86_64-unknown-linux-gnu/ -type d x86_64-unknown-linux-gnu/ x86_64-unknown-linux-gnu/arm-elf x86_64-unknown-linux-gnu/arm-elf/lib x86_64-unknown-linux-gnu/arm-elf/include x86_64-unknown-linux-gnu/i486-mingw32 x86_64-unknown-linux-gnu/i486-mingw32/lib x86_64-unknown-linux-gnu/i486-mingw32/include
02:20 alchemy:/usr> find x86_64-unknown-linux-uclibc/ -type d x86_64-unknown-linux-uclibc/ x86_64-unknown-linux-uclibc/lib x86_64-unknown-linux-uclibc/lib/ldscripts x86_64-unknown-linux-uclibc/bin x86_64-unknown-linux-uclibc/include x86_64-unknown-linux-uclibc/include/net x86_64-unknown-linux-uclibc/include/sys x86_64-unknown-linux-uclibc/include/neteconet x86_64-unknown-linux-uclibc/include/bits x86_64-unknown-linux-uclibc/include/arpa x86_64-unknown-linux-uclibc/include/netinet x86_64-unknown-linux-uclibc/include/netipx x86_64-unknown-linux-uclibc/include/netpacket x86_64-unknown-linux-uclibc/include/rpc x86_64-unknown-linux-uclibc/include/scsi x86_64-unknown-linux-uclibc/include/netax25 x86_64-unknown-linux-uclibc/include/protocols
I have an understanding of the files in x86_64-unknown-linux-gnu, but I don't know what the uclibc files are specifically (I mean I know libc, just not the uc part). There are a large number of files here:
02:20 alchemy:/usr> find x86_64-unknown-linux-uclibc/ -type f | wc -l 367
Full file list at:
http://www.3111skyline.com/download/Archlinux/bugs/usr-x86-64-unknown.txt
The file dates on the files are November 5th.
These directories look like they should be somewhere else, so I'm putting it to the brain-trust, bug or feature??
-- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
-- Flávio Coutinho da Costa
On Tuesday 01 December 2009 07:33:17 and regarding:
Does "pacman -Qo <some of this weird files>" return anything?
Flavio, Strangely, yes: 13:49 alchemy:/usr/x86_64-unknown-linux-uclibc/bin> for i in $(ls); do pacman -Qo $i; done ar is owned by binutils-uclibc 2.19.1-2 as is owned by binutils-uclibc 2.19.1-2 ld is owned by binutils-uclibc 2.19.1-2 nm is owned by binutils-uclibc 2.19.1-2 objcopy is owned by binutils-uclibc 2.19.1-2 objdump is owned by binutils-uclibc 2.19.1-2 ranlib is owned by binutils-uclibc 2.19.1-2 strip is owned by binutils-uclibc 2.19.1-2 13:51 alchemy:/usr/x86_64-unknown-linux-gnu/arm-elf/lib> for i in $(ls); do [[ ! -h $i ]] && pacman -Qo $i; done libbfd-2.20.so is owned by cross-arm-elf-binutils 2.20-1 libbfd.a is owned by cross-arm-elf-binutils 2.20-1 libopcodes-2.20.so is owned by cross-arm-elf-binutils 2.20-1 libopcodes.a is owned by cross-arm-elf-binutils 2.20-1 It looks like all the binutils files are unknown for some reason? Do you want me to post anything else? I guess I'll uninstall and try to reinstall these packages and see if it happens again. Strange. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Tue, Dec 1, 2009 at 1:54 PM, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
On Tuesday 01 December 2009 07:33:17 and regarding:
Does "pacman -Qo <some of this weird files>" return anything?
Flavio,
Strangely, yes:
13:49 alchemy:/usr/x86_64-unknown-linux-uclibc/bin> for i in $(ls); do pacman -Qo $i; done ar is owned by binutils-uclibc 2.19.1-2 as is owned by binutils-uclibc 2.19.1-2 ld is owned by binutils-uclibc 2.19.1-2 nm is owned by binutils-uclibc 2.19.1-2 objcopy is owned by binutils-uclibc 2.19.1-2 objdump is owned by binutils-uclibc 2.19.1-2 ranlib is owned by binutils-uclibc 2.19.1-2 strip is owned by binutils-uclibc 2.19.1-2
13:51 alchemy:/usr/x86_64-unknown-linux-gnu/arm-elf/lib> for i in $(ls); do [[ ! -h $i ]] && pacman -Qo $i; done libbfd-2.20.so is owned by cross-arm-elf-binutils 2.20-1 libbfd.a is owned by cross-arm-elf-binutils 2.20-1 libopcodes-2.20.so is owned by cross-arm-elf-binutils 2.20-1 libopcodes.a is owned by cross-arm-elf-binutils 2.20-1
It looks like all the binutils files are unknown for some reason?
Do you want me to post anything else? I guess I'll uninstall and try to reinstall these packages and see if it happens again. Strange.
Those packages are not essential to your system. binutils-uclibc and cross-arm-elf-binutils are primarily developer tools.
On Tuesday 01 December 2009 14:10:20 and regarding:
Those packages are not essential to your system. binutils-uclibc and cross-arm-elf-binutils are primarily developer tools.
Yes, I loaded them because there are a couple of apps that I want to try and cross compile. I guess they are fine where they are, but shouldn't the install packages have put them somewhere else? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Tue, Dec 1, 2009 at 2:27 PM, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
On Tuesday 01 December 2009 14:10:20 and regarding:
Those packages are not essential to your system. binutils-uclibc and cross-arm-elf-binutils are primarily developer tools.
Yes,
I loaded them because there are a couple of apps that I want to try and cross compile. I guess they are fine where they are, but shouldn't the install packages have put them somewhere else?
I don't think so. It's common practice to put cross compilation tools in non-standard places, so you don't accidentally end up compiling something on your x86 system for an arm processor.
Aaron Griffin wrote:
On Tue, Dec 1, 2009 at 2:27 PM, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
On Tuesday 01 December 2009 14:10:20 and regarding:
Those packages are not essential to your system. binutils-uclibc and cross-arm-elf-binutils are primarily developer tools.
Yes,
I loaded them because there are a couple of apps that I want to try and cross compile. I guess they are fine where they are, but shouldn't the install packages have put them somewhere else?
I don't think so. It's common practice to put cross compilation tools in non-standard places, so you don't accidentally end up compiling something on your x86 system for an arm processor.
A while back, there was some discussion about cross-compliers and trying to be more FHS compliant. The suggestion was to put them in /usr/lib/cross-<target>. See: http://wiki.archlinux.org/index.php/Cross_Compiling_Tools_Package_Guidelines... I posted a set of PKGBUILDs for the mingw32 cross compiler. Allan
participants (4)
-
Aaron Griffin
-
Allan McRae
-
David C. Rankin
-
Flavio Costa