Created attachment 318504 [details] emerge --info for blas-atlas I am getting multiple errors in emerging sci-libs/blas-atlas from http://packages.gentoo.org/package/sci-libs/blas-atlas I am pasting the errors from the emerge and also attaching the results from emerge --info FlagCheck.c:1:0: error: bad value (ultrasparc) for -mtune= switch FlagCheck.c:1:0: error: bad value (ultrasparc) for -mtune= switch FlagCheck.c:1:0: error: bad value (ultrasparc) for -mtune= switch FlagCheck.c:1:0: error: bad value (ultrasparc) for -mtune= switch cc1: error: unrecognized command line option "-mips4" FlagCheck.c:1:0: error: bad value (ultrasparc) for -mtune= switch cc1: error: unrecognized command line option "-maltivec" FlagCheck.c:1:0: error: unknown ABI (altivec) for -mabi= switch FlagCheck.c:1:0: error: bad value (ultrasparc) for -mtune= switch FlagCheck.c:1:0: error: bad value (ultrasparc) for -mtune= switch FlagCheck.c:1:0: error: bad value (ultrasparc) for -mtune= switch FlagCheck.c:1:0: error: bad value (970) for -mtune= switch cc1: error: unrecognized command line option "-mips4" cc1: error: unrecognized command line option "-mips4" cc1: error: unrecognized command line option "-mips4" cc1: error: unrecognized command line option "-mips4" FlagCheck.c:1:0: error: bad value (ultrasparc) for -mtune= switch FlagCheck.c:1:0: error: bad value (ultrasparc) for -mtune= switch FlagCheck.c:1:0: error: bad value (ultrasparc) for -mtune= switch FlagCheck.c:1:0: error: bad value (ultrasparc) for -mtune= switch cc1: error: unrecognized command line option "-mips4" FlagCheck.c:1:0: error: bad value (ultrasparc) for -mtune= switch cc1: error: unrecognized command line option "-maltivec" FlagCheck.c:1:0: error: unknown ABI (altivec) for -mabi= switch FlagCheck.c:1:0: error: bad value (ultrasparc) for -mtune= switch FlagCheck.c:1:0: error: bad value (ultrasparc) for -mtune= switch FlagCheck.c:1:0: error: bad value (ultrasparc) for -mtune= switch FlagCheck.c:1:0: error: bad value (970) for -mtune= switch cc1: error: unrecognized command line option "-mips4" cc1: error: unrecognized command line option "-mips4" cc1: error: unrecognized command line option "-mips4" cc1: error: unrecognized command line option "-mips4" ATL_dgemvN.c:3:5: error: #error "This kernel requires gas x86-32 assembler!" ATL_dgemvT.c:3:5: error: #error "This kernel requires gas x86-32 assembler!" ATL_dgemvT.c:38:5: error: #error "This kernel requires gas x86-32 assembler!" ATL_dgemvN.c:3:5: error: #error "This kernel requires gas x86-32 assembler!" ATL_sgemvN.c:3:5: error: #error "This kernel requires gas x86-32 assembler!" ATL_sgemvT.c:3:5: error: #error "This kernel requires gas x86-32 assembler!" ATL_sgemvT.c:38:5: error: #error "This kernel requires gas x86-32 assembler!" ATL_sgemvN.c:3:5: error: #error "This kernel requires gas x86-32 assembler!" ATL_zgemvN.c:3:5: error: #error "This kernel requires gas x86-32 assembler!" ATL_zgemvT.c:3:5: error: #error "This kernel requires gas x86-32 assembler!" ATL_zgemvT.c:38:5: error: #error "This kernel requires gas x86-32 assembler!" ATL_zgemvN.c:3:5: error: #error "This kernel requires gas x86-32 assembler!" ATL_cgemvN.c:3:5: error: #error "This kernel requires gas x86-32 assembler!" ATL_cgemvT.c:3:5: error: #error "This kernel requires gas x86-32 assembler!" ATL_cgemvT.c:38:5: error: #error "This kernel requires gas x86-32 assembler!" ATL_cgemvN.c:3:5: error: #error "This kernel requires gas x86-32 assembler!" /bin/sh: -c: line 2: syntax error near unexpected token `fi' /bin/sh: -c: line 2: syntax error near unexpected token `fi'
Please attach the entire build log to this bug report.
Created attachment 318650 [details] build log This is the complete build log.
(In reply to comment #2) > Created attachment 318650 [details] > build log > > This is the complete build log. Looks like something/someone sent a SIGINT: Exiting on signal 2 sandbox:stop caught signal 2 in pid 4896 sandbox:stop signal already caught and busy still cleaning up! Also, the errors you pasted in comment #0 are not present in the build log. Also, they look like harmless configure checks.
Sorry about this. I did run the build again and got the errors in Comment #0. However, I cannot attach the output of the file right now as when I rebooted the system I cannot access eth0. I am trying to get back eth0. It was there in my rc-update show default but it did not load up on reboot http://forums.gentoo.org/viewtopic-t-923310-start-0.html Trying to use this to fix this mess up. Basically my /etc/runlevels/sysinit shows udev in red
I got the new build file, but I Cannot upload it because it is 10000 KB. Can I email you the file or what should I do? That file contains the errors in comment #0.
(In reply to comment #5) > I got the new build file, but I Cannot upload it because it is 10000 KB. Can > I email you the file or what should I do? That file contains the errors in > comment #0. Compress the file using xz or bzip2. Then attach it.
Created attachment 319102 [details] build log zip file This is the build log zip file.
They are still harmless checks. Also, the build succeeds and installs libraries and other files.
(In reply to comment #8) > They are still harmless checks. > > Also, the build succeeds and installs libraries and other files. The errors in comment #0 are there though. How to fix these harmless checks on the assembler?
i strongly suggest to go for sci-libs/atlas in the science overlay. this main portage tree build is getting non compatible with a lot of packages.
(In reply to comment #10) > i strongly suggest to go for sci-libs/atlas in the science overlay. > > this main portage tree build is getting non compatible with a lot of > packages. I have seen blas-atlas has a ton of opened bugs affecting its multiple versions in the tree, wouldn't be possible to move sci-libs/atlas to main tree? If it's not possible, maybe we could lastrite this broken package and point people to use sci overlay instead
How is the status of the alternatives.eclass? Legally? It depends an that. Current ebuild as well as eclass are working fine. So we could move in principle.
(In reply to comment #12) > How is the status of the alternatives.eclass? Legally? It depends an that. > Current ebuild as well as eclass are working fine. So we could move in > principle. As far as I know, it's still legal, we use it in gnome packages without problems and I haven't seen any deprecating comment into it. I think it won't be a problem to get it moved.
Oh, I meant alternatives-2.eclass. That one comes from exherbo and uses a patch version of eselect to make different implementations or so available. It is copyrighted by some of their devs, so we need to figure out whether it can be simply imported. Plus we need to get the eselect patch approved.
I guess a mail to suggest that in gentoo-dev ML will be needed then, no? :/ I am already crossing my fingers
(In reply to comment #15) > I guess a mail to suggest that in gentoo-dev ML will be needed then, no? :/ > I am already crossing my fingers Any updates on this?
(In reply to comment #16) > (In reply to comment #15) > > I guess a mail to suggest that in gentoo-dev ML will be needed then, no? :/ > > I am already crossing my fingers > > Any updates on this? We are working on this but there is real progress I am aware of. @bicatali What about dropping lapack/blas-atlas from the tree now? We need to drop anyways later?
(In reply to comment #17) > @bicatali > What about dropping lapack/blas-atlas from the tree now? We need to drop > anyways later? yes, lets drop blas-atlas and lapack-atlas, too fragile
Dropped all atlas packages from tree. Please use sci-libs/atlas from sci overlay. If problem still exist with that package, please reopen the bug or file a new one.
