Honza Macháček wrote:
>   I have just manually compiled Quantum ESPRESSO on my Athlon 2500+.
> Since I have little experience in making ebuilds and not much time for
> trying, I'm not sure if I can produce anything usable for Bugzilla.
> Therefore I at least rely, what I did:

Great!

> 1. Tried playing with the ebuild from Spyderous overlay, thoug I don't
> have ifc. All my attempts only crippled the ebuild and failed miserably.

In theory my ebuild should work at least up through src_compile(), I
think src_install() is still broken. It's a work in progress.

> 2. Tried manual compilation of the sources from
> http://www.pwscf.org/download.htm using gfortran of gcc-4.1.1
> (F90=gfortran ./configure && make all). Died of internal compiler error.

Yep. I've filed a gcc bug for this --
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27889 -- although I think
there is another ICE in the same file.

> 3. Looked at g95 (http://www.g95.org/src.shtml). Ugly source structure,
> queer building sequence and essentially no version numbering. May be
> best installed as an option of gcc (g95 USE flag?).

Nah, needs to be a separate package since it's distributed separately
and so forth, like gnat. I wouldn't mind having an ebuild for this, though.

> 4. Looked at the gcc-4.1.1 ebuild. Heavy reading due to heavy use of the
> toolchain eclass. Gave up ebuild adaptation.
> 
> 5. Tried manual compilation of g95 with gcc-4.1.1 sources. Failed.
> 
> 6. Tried manual compilation of g95 with gcc-4.0.3 sources, that
> according to the webpage should work. Success. Installed in /usr/local
> and added /usr/local/bin/g95 symlink to i686-pc-linux-gnu-g95.
> Standalone ebuild for g95 would be probably better than merging it with
> gcc after all, and easier to create too, yet still likely beyond my ability.

Agreed, standalone is the way to go. Surprised it's broken on gcc 4.1.


> 7. Tried manual compilation of ESPRESSO (./configure && make all).
> Mostly worked, only tools crashed due to metadyn_pp referencing
> undefined pgopen_.
> 
> 8. Found on the web that pgopen should be found in the pgplot package.
> Tried to emerge that, but failed for the lack of g77.
> 
> 9. Mangled pgplot ebuild to recognize g95 and tried emerging again. g95
> was not accepted by the ebuild.

You need to edit fortran.eclass to recognize g95. There are three places
in there where you need to add a g95 bit -- two case statements and one
OR list of all the compilers like "g95|g77|gfortran|icc|ifort" or so.

> 10. Mangled pgplot ebuild to recognize gfortran and tried emerging
> again. Failed due to syntax errors in arguments supplied to GRGI0[1-6]
> functions.

pgplot can't work with gfortran now because gfortran doesn't recognize
%VAL -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23060. I've got a
pgplot patch that deals with most of the rest of the issues, but waiting
on that.

> 11. Turned again to g95. Mangled fortran.eclass to recognize that (and
> prioritize over gfortran, althoug not stating gfortran in the ebuild
> might neutralize its default priority as well). Emerged pgplot. g95
> shouted warnings of ``Inconsistent types (INTEGER(4)/INTEGER(1)) in
> actual argument lists'' in GRGI0[1-6] functions, but compiled the code.

Ah, see you figured out the eclass here..

> 12. Tried manual compilation of ESPRESSO (./configure && make all).
> Mostly worked, only tools crashed due to metadyn_pp referencing
> undefined pgopen_.
> 
> 13. Grepped the ESPRESSO source tree for pgopen_, found nothing. Grepped
> for pgplot. Found libraries configuration mentioned in
> pwtools/metadyn_pp.f90, but nowhere in makefiles or the configure script.

Try 'grep -i pgopen -r .' in the espresso source. The underscore isn't
in the Fortran, that's added by the compiler/linker.

> 14. Edited make.sys, added -D__PGPLOT to DFLAGS and ``-lm -lc -lpgplot
> -lX11'' to LIBS. Compiled successfuly.
> 
>   Now I have to first learn using ESPRESSO to test, wheather my build
> actually works. If I manage to sum up my compilation steps into ebuilds
> and patches, I'll put them on Bugzilla, but I'm affraid I cannot promise
> that.

I just don't think we can add it to the tree until a few more gfortran
bugs get fixed.

Thanks,
Donnie