Hi! There is a new release of ACML library - version 3.5.0. Thus, I recommend bumping the ebuild as well. I renamed acml-3.1.0.ebuild to acml-3.5.0.ebuild and it seems to be enough to have an updated version. BTW, the gcc-4.1.1 is now unmasked in portage, so a new ebuild, which uses acml-VERSION-gfortran-{32,64}bit.tgz sources would be preferable. However, I do not know if it is possible to decide which package to download based on the installed compiler. Now the selection of SRC_URI is only done according to architecture, which is not enough. I hope you have some ideas how to solve the second issue from this bug report. Best regards, /ediap
Created attachment 95219 [details] acml-3.5.0-r1.ebuild which uses eselect
One more comment regarding the acml in Gentoo and eselect.cblas: I think that /usr/include/cblas.h shouldn't be linked to /usr/include/acml/acml.h, because ACML's CBLAS header file is not compatible with cblas.h from cblas-reference and blas-atlas packages. ACML library does not use "cblas_" prefix for function names, but also changes the types of functin parameters, e.g. uses local complex and doublecomplex type definitions instead of void pointers. BR, /ediap
(In reply to comment #2) > One more comment regarding the acml in Gentoo and eselect.cblas: > I think that /usr/include/cblas.h shouldn't be linked to > /usr/include/acml/acml.h, because ACML's CBLAS header file is not compatible > with cblas.h from cblas-reference and blas-atlas packages. > > ACML library does not use "cblas_" prefix for function names, but also changes > the types of functin parameters, e.g. uses local complex and doublecomplex type > definitions instead of void pointers. I've committed this change.
another interesting issue with acml and C99, c99 has it's own "complex" type, and acml will undef it. This make it hard to maintain while mixing c99, fftw3, acml together. fftw3 is faster for non power of 2 fft than acml, but acml has other good functions... What would people think if we would make the header c99 compatible instead of mixing everything ? basically changing: complex -> complex float complexdouble -> complex double
Created attachment 99771 [details] acml-3.5.0-r2.ebuild I tried the function tc-getF77 and tc-getFORTRAN from toolchain-funcs.eclass to determine the fortran complier of system. The function tc-getF77 returns "f77" by default, while the GNU f77 complier is called "g77". But it's not the case for tc-getFORTRAN, which returns "gfortran" by default, and unfortunately, "gfortran" IS the name of GNU fortran complier. As a result, only the tc-getF77 is used, which is not the accurate way. Maybe functions from fortran.eclass could help? Also, I have only tested the ebuild with gfortran and acml-3-5-0-gfortran-64bit.tgz because I don't have gcc 3.4.* installed. Hope somebody could test more:) Sorry for my poor English:p
You don't need to do all that testing, FORTRAN is the full allowed list of compilers, not a single compiler.
(In reply to comment #6) > You don't need to do all that testing, FORTRAN is the full allowed list of > compilers, not a single compiler. > The problem is that AMD complied acml-VERSION-gnu-{32,64}bit.tgz with g77(from gcc-3.*) and acml-VERSION-gfortran-{32,64}bit.tgz with gfortran(from gcc-4.*). The two versions require different FORTRAN to C library, i.e. libg2c shipped with gcc-3.* for g77 version, libgfortran shipped with gcc-4.* for gfortran version. The acml-3.5.0-r1.ebuild or the 3.1.0 ebuild in portage always installs the acml-VERSION-gnu-{32,64}bit.tgz. If I try to build a program with acml, there are many unresolved references which are parts of libg2c, while I don't have libg2c. As a result, we need to select the SRC_URI not only according to architecture, but also the fortran complier version (g77/gfortran). The committed ebuild works well for me. Hope it will works for gcc-3.4.* as well. Regards
bumping severity to normal because only the 3.5 sources are visible from the homepage leaving current stable and testing ebuilds without anything to work on
(In reply to comment #8) > bumping severity to normal because only the 3.5 sources are visible from the > homepage leaving current stable and testing ebuilds without anything to work on That's not true. There is still access to all previous releases. Just use the following ling: http://developer.amd.com/acmlarchive.jsp Anyway, the "enchancement" to "normal" change is OK, since all stable ebuild can not be used with >=gcc-4.0.0, which was described in my initial post and comment #7. BR, /ediap
Just a reminder... ACML 3.6.0 is already released, but this bug is still not solved, which means that stable sci-libs/acml does not work with the default stable compiler in Gentoo (gcc-4.1.1). BR, /ediap
Sorry for the bump, but is someone working on this bug? acml-3.6.1 is out, and the acml version in portage is still 3.1.0, because the problems with newer versions are still there since a year ago.
Created attachment 120450 [details] acml-3.6.1.ebuild The different acml buildings are nothing but a mess! The ebuild provides two ways to determine which version to be installed: USE flags, or automatic fortran comiler detection. You could just ebuild acml-3.6.1.ebuild digest && emerge acml. Also you could do USE="gfortran int64" ebuild acml-3.6.1.ebuild digest USE="gfortran int64 -openmp" emerge acml
I have some problems when emerging: 1.- The first problem was when doing ebuild acml-3.6.1.ebuild digest, I got this error: * Please download the ACML from: * http://developer.amd.com/acml.jsp * and place it in /usr/portage/distfiles * The previous version could be found at * http://developer.amd.com/acmlarchive.jsp !!! File acml-3-6-0--64bit.tgz doesn't exist, can't update Manifest I "solved" this by changing the name of the package I downloaded, acml-3-6-0-gnu-64bit.tgz to the requested name. It seems that the variable that defines the compiler doesn't work (I don't know the name, I haven't readed the ebuild in detail). Strange thing that it requested this package instead acml-3-6-1-gfortran--64bit.tgz. I don't know why, since 3-6-1 version is the actual one and gfortran is the default fortran compiler now. 2.- When emerging after this "fix", I had this error when emerging: >>> Unpacking acml-3-6-0--64bit.tgz to /var/tmp/portage/sci-libs/acml-3.6.1/work >>> Unpacking contents-acml-3-6-0--64bit.tgz to /var/tmp/portage/sci-libs/acml-3.6.1/work !!! ERROR: sci-libs/acml-3.6.1 failed. Call stack: ebuild.sh, line 1615: Called dyn_unpack ebuild.sh, line 752: Called qa_call 'src_unpack' ebuild.sh, line 44: Called src_unpack acml-3.6.1.ebuild, line 61: Called unpack 'contents-acml-3-6-0--64bit.tgz' ebuild.sh, line 404: Called die !!! contents-acml-3-6-0--64bit.tgz does not exist !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/var/tmp/portage/sci-libs/acml-3.6.1/temp/build.log'. !!! This ebuild is from an overlay: '/usr/local/portage' I haven't found anything similar to contents-acml-3-6-0--64bit.tgz (the package requested by the ebuild) in the acml webpage, and I can't remebmer anything similar in older ebuilds, so I don't know what package I must donwloand (if any). Also I find odd that the ebuild doesn't request any 3-6-1 package in the 3-6-1 version ebuild, even when I tried to emerge it with gfortran USE-flag, which is the version of acml that is in the 3-6-1 version (according to the ACML webpage, the versions for g77, Intel Fortran and friends are 3-6-0). Anyway, I think that the ebuild is quite good, maybe thanks to the eselect stuff (the old ones were very confusing someones used fortran, some others C, etc). AFAIK, fortran is essential in acml, and since gfortran is the default compiler in the stable gcc compiler, I think that gfortran should be selected by default (something like sci-mathematics/maxima, you have USEflags to select which Lisp compiler you want use, gcl, clisp or sbcl, but if you don't set any, gcl is used). Well, sorry for my huge comment. That's all, folks.
(In reply to comment #13) > I have some problems when emerging: > > 1.- The first problem was when doing ebuild acml-3.6.1.ebuild digest, I got > this error: > > * Please download the ACML from: > * http://developer.amd.com/acml.jsp > * and place it in /usr/portage/distfiles > * The previous version could be found at > * http://developer.amd.com/acmlarchive.jsp > !!! File acml-3-6-0--64bit.tgz doesn't exist, can't update Manifest > Which FORTRAN compiler do you use? It seems that the ebuild couldn't detect a fortran compiler (currently only support gfortran(GCC4), g77(GCC3), and ifc). If you are sure you have one of these, please specify it by a USE flag, USE="gfortran" ebuild ... digest # this USE flag MUST be here; the one in make.conf doesn't affect USE="gfrotran" emerge acml # of course this one could be in make.conf > ebuild in detail). Strange thing that it requested this package instead > acml-3-6-1-gfortran--64bit.tgz. The correct name (as AMD) is acml-3.6.1-gfortran-64bit.tgz > 2.- When emerging after this "fix", I had this error when emerging: > > >>> Unpacking acml-3-6-0--64bit.tgz to /var/tmp/portage/sci-libs/acml-3.6.1/work > >>> Unpacking contents-acml-3-6-0--64bit.tgz to /var/tmp/portage/sci-libs/acml-3.6.1/work > > !!! ERROR: sci-libs/acml-3.6.1 failed. > Call stack: > ebuild.sh, line 1615: Called dyn_unpack > ebuild.sh, line 752: Called qa_call 'src_unpack' > ebuild.sh, line 44: Called src_unpack > acml-3.6.1.ebuild, line 61: Called unpack 'contents-acml-3-6-0--64bit.tgz' > ebuild.sh, line 404: Called die > > !!! contents-acml-3-6-0--64bit.tgz does not exist > !!! If you need support, post the topmost build error, and the call stack if > relevant. > !!! A complete build log is located at > '/var/tmp/portage/sci-libs/acml-3.6.1/temp/build.log'. > > !!! This ebuild is from an overlay: '/usr/local/portage' > The same problem: this ebuild could not detect the fortran compiler you have, and I forgot to give a message when this happens. (Now I added it). > Also I find odd that the ebuild doesn't request any 3-6-1 package in the 3-6-1 > version ebuild, even when I tried to emerge it with gfortran USE-flag, which is > the version of acml that is in the 3-6-1 version (according to the ACML > webpage, the versions for g77, Intel Fortran and friends are 3-6-0). Yes, actually the 3-6-1 version is only availible for gfortran; the rest is still 3-6-0. > Anyway, I think that the ebuild is quite good, maybe thanks to the eselect > stuff (the old ones were very confusing someones used fortran, some others C, > etc). AFAIK, fortran is essential in acml, and since gfortran is the default > compiler in the stable gcc compiler, I think that gfortran should be selected > by default (something like sci-mathematics/maxima, you have USEflags to select > which Lisp compiler you want use, gcl, clisp or sbcl, but if you don't set any, > gcl is used). Thanks. I think making gfortran a default selection is a good idea.
(In reply to comment #14) > (In reply to comment #13) > > I have some problems when emerging: > > > > 1.- The first problem was when doing ebuild acml-3.6.1.ebuild digest, I got > > this error: > > > > * Please download the ACML from: > > * http://developer.amd.com/acml.jsp > > * and place it in /usr/portage/distfiles > > * The previous version could be found at > > * http://developer.amd.com/acmlarchive.jsp > > !!! File acml-3-6-0--64bit.tgz doesn't exist, can't update Manifest > > > > Which FORTRAN compiler do you use? It seems that the ebuild couldn't detect a > fortran compiler (currently only support gfortran(GCC4), g77(GCC3), and ifc). > > If you are sure you have one of these, please specify it by a USE flag, > USE="gfortran" ebuild ... digest # this USE flag MUST be here; the one > in make.conf doesn't affect > USE="gfrotran" emerge acml # of course this one could be in make.conf I have gfortran, the gcc4 fortran compiler. However, none of those solutions works, it's still requesting an non-existent acml-3-6-0--64bit.tgz, no matter which fortran compiler I set. Even when I use USE="gfortran" ebuild ... digest, the requested package is a 3-6-0, not a 3-6-1. > > ebuild in detail). Strange thing that it requested this package instead > > acml-3-6-1-gfortran--64bit.tgz. > > The correct name (as AMD) is acml-3.6.1-gfortran-64bit.tgz It was a typo, I was trying to say that the requested package was not acml-3.6.1-gfortran-64bit.tgz, the good package. > > 2.- When emerging after this "fix", I had this error when emerging: > > > > >>> Unpacking acml-3-6-0--64bit.tgz to /var/tmp/portage/sci-libs/acml-3.6.1/work > > >>> Unpacking contents-acml-3-6-0--64bit.tgz to /var/tmp/portage/sci-libs/acml-3.6.1/work > > > > !!! ERROR: sci-libs/acml-3.6.1 failed. > > Call stack: > > ebuild.sh, line 1615: Called dyn_unpack > > ebuild.sh, line 752: Called qa_call 'src_unpack' > > ebuild.sh, line 44: Called src_unpack > > acml-3.6.1.ebuild, line 61: Called unpack 'contents-acml-3-6-0--64bit.tgz' > > ebuild.sh, line 404: Called die > > > > !!! contents-acml-3-6-0--64bit.tgz does not exist > > !!! If you need support, post the topmost build error, and the call stack if > > relevant. > > !!! A complete build log is located at > > '/var/tmp/portage/sci-libs/acml-3.6.1/temp/build.log'. > > > > !!! This ebuild is from an overlay: '/usr/local/portage' > > > > The same problem: this ebuild could not detect the fortran compiler you have, > and I forgot to give a message when this happens. (Now I added it). Probably, but you forgot to attach it :P But what about this contents-acml-3-6-0 package? > > Also I find odd that the ebuild doesn't request any 3-6-1 package in the 3-6-1 > > version ebuild, even when I tried to emerge it with gfortran USE-flag, which is > > the version of acml that is in the 3-6-1 version (according to the ACML > > webpage, the versions for g77, Intel Fortran and friends are 3-6-0). > > Yes, actually the 3-6-1 version is only availible for gfortran; the rest is > still 3-6-0. But I said the problem before, it doesn't mind that you digest and emerge it with USE="gfortran", the ebuild stills keeping requesting a 3-6-0 package. > > Anyway, I think that the ebuild is quite good, maybe thanks to the eselect > > stuff (the old ones were very confusing someones used fortran, some others C, > > etc). AFAIK, fortran is essential in acml, and since gfortran is the default > > compiler in the stable gcc compiler, I think that gfortran should be selected > > by default (something like sci-mathematics/maxima, you have USEflags to select > > which Lisp compiler you want use, gcl, clisp or sbcl, but if you don't set any, > > gcl is used). > > Thanks. I think making gfortran a default selection is a good idea. > I have no time right now to work on this, I'm in an exam period, but I can try to help with the ebuild later.
> I have gfortran, the gcc4 fortran compiler. However, none of those solutions > works, it's still requesting an non-existent acml-3-6-0--64bit.tgz, no matter > which fortran compiler I set. Even when I use USE="gfortran" ebuild ... digest, > the requested package is a 3-6-0, not a 3-6-1. That's strange. I use fortran_pkg_setup from fortran.eclass to generate $FORTRANC. In your case, it should be $FORTRANC == gfortran (which is also my case). Then it is merged into the package name. Oh, wait. I did remember sth, but not very clearly. I experienced similar problems yesterday. After a digest that requested 3-6-0, I changed to gfortran but it still asked for 3-6-0. Then I removed all the digest files, waited for a moment, ran a gfortran digest and it worked! I guess that the ebuild digesting may have something like env cache? > Probably, but you forgot to attach it :P But what about this > contents-acml-3-6-0 package? It also depends on $FORTRANC, which is not correctly set in your case. I don't know why... > I have no time right now to work on this, I'm in an exam period, but I can try > to help with the ebuild later. I will attach a kind of 'fixed' version. You could try it on. Many thanks.
Created attachment 120516 [details] acml-3.6.1.ebuild The ebuild will try to select correct acml version. First, a FORTRAN compiler check will be done. If you don't have any FORTRAN compiler, it fails. Then the ebuild tries to set $FORT according to the FORTRAN related USE flags: gfortran g77 ifc. If only one of those flags is enabled, $FORT will be set. No additional check will be done (you have only gfortran, but you could emerge acml with USE="g77 -ifc -gfortran", the resulting library is not usable). If none or more than one of those flags are enabled, $FORT will be set to the first available FORTRAN compiler in gfortran, g77, and ifc. Hope it works.
Great, it works now, except for a thing (which makes it unusable): I got those errors: !!! Error: Installing /usr/local/portage/sci-libs/acml/files/eselect.blas as /var/tmp/portage/sci-libs/acml-3.6.1/image//etc/env.d/blas/lib64/acml failed! /usr/local/portage/sci-libs/acml/acml-3.6.1.ebuild: line 84: 19698 Terminado (killed) eselect blas add $(get_libdir) ${FILESDIR}/eselect.blas acml cp: no se puede efectuar `stat' sobre «/usr/local/portage/sci-libs/acml/files/eselect.cblas»: No existe el fichero o el directorio !!! Error: Installing /usr/local/portage/sci-libs/acml/files/eselect.cblas as /var/tmp/portage/sci-libs/acml-3.6.1/image//etc/env.d/cblas/lib64/acml failed! /usr/local/portage/sci-libs/acml/acml-3.6.1.ebuild: line 84: 19711 Terminado (killed) eselect cblas add $(get_libdir) ${FILESDIR}/eselect.cblas acml cp: no se puede efectuar `stat' sobre «/usr/local/portage/sci-libs/acml/files/eselect.lapack»: No existe el fichero o el directorio !!! Error: Installing /usr/local/portage/sci-libs/acml/files/eselect.lapack as /var/tmp/portage/sci-libs/acml-3.6.1/image//etc/env.d/lapack/lib64/acml failed! /usr/local/portage/sci-libs/acml/acml-3.6.1.ebuild: line 84: 19724 Terminado (killed) eselect lapack add $(get_libdir) ${FILESDIR}/eselect.lapack acml The errors are obvious: ebuild doesn't install the necessary eselect files for blas, cblas and lapack. It install everything else, the libraries and all, but not the eselect files. According to the ebuild, it gets the files from ${FILESDIR}/eselect.lapack (or.cblas or .blas, of course). blas-atlas and lapack-atlas (the libraries that I'm using now) have some files in the files directory of the ebuild. I suposse that we must make some similar files, but with the acml libraries.
Do you have all the eselect files on ${OVERLAY}/sci-libs/acml/files/ ? cp or symlink from /usr/portage/sci-libs/acml/files/
(In reply to comment #19) > Do you have all the eselect files on ${OVERLAY}/sci-libs/acml/files/ ? > > cp or symlink from /usr/portage/sci-libs/acml/files/ > Oops, I haven't do that, I didn't know that old acml ebuild used the new eselect stuff. Now I copied them and it works. Two things more: acml libraries are selected when I install acml, but if I try to select them again with eselect cblas set acml (or cblas or lapack), I get this error: Implementation "acml" already active for library directory "lib64"! Failed to switch to implementation "acml" for library directory "lib64"! !!! Error: One or more actions have failed! Terminado (killed) I did it before I checked with "eselect blas list" that acml libraries were selected. It doesn't seems important, and it seems like a problem about eselect, not about acml, but maybe it should be fixed. The other thing is that the digest stuff must be fixed, I don't think that having to digest the ebuild with using USE="xxx" is correct, specially if this package is going to get to the official portage tree. Except for this couple of bugs, the ebuild looks great. Let's hope that the gentoo-science people pay attention on this bug, acml is important enough.
Created attachment 120535 [details] sci-libs/acml-3.6.1.ebuild This is a fixed ebuild. The only change is that I added those lines after RDEPEND: PROVIDE="virtual/blas virtual/lapack" Without this, packages that need blas and/or lapack will pull virtual/blas and/or virtual/lapack as a dependency, but those virtual packages won't recongnize acml as a blas and lapack provider, so they will pull another packages like blas-atlas and lapack-atlas. Adding this lines fix that. I have compiled dev-lang/R, sci-mathematics/octave and sci-mathematics/octave-forge,with blas and lapack support with acml as the only blas and lapack implementation available and it works: they doesn't pull any other package and they compile and run without problems. So IMHO the only problems remaining are the ones that I described in my previous comment.
> I did it before I checked with "eselect blas list" that acml libraries were > selected. It doesn't seems important, and it seems like a problem about > eselect, not about acml, but maybe it should be fixed. eselect has not only this problem, in my experience. > The other thing is that the digest stuff must be fixed, I don't think that > having to digest the ebuild with using USE="xxx" is correct, specially if this > package is going to get to the official portage tree. Agree. To avoid digesting, one possible 'solution' is adding digests of all the possible packages to the Manifest file. But if you change your FORTRAN selection, the portage cache (/var/cache/edb/*/acml-3.6.1) will bother you as it may cache the wrong SRC_URI. You need delete portage cache if you want to change FORTRAN selection. Another way is just pull everything to SRC_URI. You don't need to care about the cache thing but, you have to have all the files that SRC_URI mentions in your DISTDIR. None of above seems perfect. Any other ways?
(In reply to comment #20) > Two things more: acml libraries are selected when I install acml, but if I try > to select them again with eselect cblas set acml (or cblas or lapack), I get > this error: > > Implementation "acml" already active for library directory "lib64"! > Failed to switch to implementation "acml" for library directory "lib64"! > !!! Error: One or more actions have failed! > Terminado (killed) > > I did it before I checked with "eselect blas list" that acml libraries were > selected. It doesn't seems important, and it seems like a problem about > eselect, not about acml, but maybe it should be fixed. Not sure I understand why you would want this to be a legal action in eselect?
(In reply to comment #22) > > I did it before I checked with "eselect blas list" that acml libraries were > > selected. It doesn't seems important, and it seems like a problem about > > eselect, not about acml, but maybe it should be fixed. > > eselect has not only this problem, in my experience. Then please file bugs for whatever problems you're encountering. They won't get fixed if nobody knows about them.
Hi I bumped acml to 3.6.0 (for ifc and g77) and 3.6.1 (for gfortran). Right now, only acm-3.6.0 ebuild supports openmp with ifc, gcc-4.2, with openmp support, only hit after I was working on the ebuild and is still hard masked. I recomand using the acml-3.6.1 anyway unless you build all your packages with blas/cblas/lapack dependencies with another compiler. Closing the year old bug for now, re-open if any of you have problem installing. Sébastien
