Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=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 an attachment (id=99771) [details]
Depends on your fortran complier to choose the appropriate acml version.

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 an attachment (id=120450) [details]
version bump, also some efforts

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 an attachment (id=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 an attachment (id=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