New production version of abinit is out and seems to compile well.
Created attachment 173973 [details, diff] abinit-5.4.4-5.6.3.ebuild.diff Diff from abinit-5.4.4.ebuild to 5.6.3 version. Compiled with USE="netcdf -mpi" at an x86 machine (Athlon XP) and with USE="netcdf mpi" at three amd64 machines (Core2 Duo, Core2 Quad and dual quad-core Opteron). Parallel versions built against sys-cluster/openmpi-1.2.8. libtool-2.2 hack of 5.4.4 version apparently no longer needed, built well using sys-devel/libtool-2.2.6a (as well as 1.5.24).
Created attachment 174037 [details, diff] abinit-5.4.4-5.6.3.ebuild.diff The previous ebuild (diff) slightly modified not to polute the ebuild environment so dangerously. Setting FC and CC bit me when calling subsequently ebuild <ebuild> <function>.
Did you notice that the new version built against internal blas/lapack?
(In reply to comment #3) > Did you notice that the new version built against internal blas/lapack? > No, until you pointed that out. Then I realised that: 1) It builds many things internally, even downloading sources from http://www.abinit.org/plugins/?text=plugins on its own. 2) It uses different syntax of multiple configure options, so that half of those I've taken thoughtlessly from the old ebuild are actually ignored. 3) It really wants -lnetcdf while we have fortran bindings in -lnetcdff An attempt on the first few easiest corrections, including the netcdf problem, follows. I guess that in the end we should isolate all the internally build plugins, make ebuilds for those that are not in portage, and force abinit to build against those externally installed packages, if (and only if) triggered by the appropriate USE flags. I'm going to try a bit in this direction -- as much as my laziness and time schedule allow.
Created attachment 179333 [details, diff] abinit-5.4.4-5.6.3.ebuild.diff New, slightly corrected version. No longer tries to use obsolete configure options and calls the remaining ones, like the compiler options, by their currently proper names. Provides the package with blas and lapack locations to build against the system libraries. Provides the package with the location of netcdf and the proper name of the library (netcdff) in a way the configure script does not ignore.
Created attachment 179337 [details, diff] abinit-5.4.4-5.6.4.ebuild.diff The abinit developers released a new production version. Builds almost the same way as 5.6.3, only 5.2.3-fix-64bit-detection.patch has finally been incorporated upstream. I've tried to externalise one of the internally build packages, sci-libs/etsf_io -- see Bug 255998 -- others should probably follow.
Excellent, thanks for working on this! I've had enough time to begin investigating but not enough to finish fixing the problems. Yeah, I finally got them to add that patch.
Created attachment 184533 [details, diff] abinit-5.4.4-5.6.5.ebuild.diff The diff from the abinit-5.4.4.ebuild to an ebuild for the new 5.6.5 production version of Abinit. This version keeps the default compilation of all the Abinit plug-ins inside its own tree (except netcdf), even with their downloading during the build process; I hope to add the version separating them all soon -- as soon as I get it compiled. A patch is needed to pass -lnetcdff to etsf_io correctly -- will not be needed anymore once the etsf_io package is separated. I've finally read the documentation far enough to realise that no CC,FC jugling is needed to compile the parallel version of Abinit -- just calling `make multi` instead of `make` works well.
Created attachment 184535 [details, diff] 5.6.5-etsf_io-netcdf.patch The patch used in the abinit-5.6.5.ebuild above to pass -lnetcdff to the etsf_io build process correctly.
Created attachment 184536 [details, diff] abinit-5.4.4-5.6.3.ebuild.diff Handle parallel compilation correctly -- `(e)make multi`
Created attachment 184540 [details, diff] abinit-5.4.4-5.6.4.ebuild.diff Compile the parallel version correctly, no FC, CC juggling.
Just wanted to let you know I intend to get this into the tree this week. Thanks for your work and dedication so far!
I'm working on this in my overlay (layman -a dberkholz to follow along). So far I've made separate ebuilds for bigdft, fox, and wannier90 in addition to your etsf_io, and I also intend to make etsf_xc. I've additionally made some modifications to your posted ebuilds for etsf_io and abinit.
Created attachment 185073 [details] abinit-ebuilds.tar.bz2 My collection of ebuilds made so far. Probably should have mailed it directly, but impersonal use of bugzilla suits my psychopatic nature better. I am not sure if there is anything of interest; may be my patch for TeXing the wannier90 documentation. My mh ebuild modification is almost irrelevant, needed only before the fancyhdr path for the wannier90 doc, to replace texlive with tetex and preserve mh. libstring_f-9999.ebuild is probably doomed, it worked in February but does not anymore, current libxc has absorbed linstring_f inside. Abinit 5.6.5 does not compile against the current libxc, as well as bigdft, and I haven't attempted porting, just set its dependence on the versions in its own archive; even so, in the context of current libxc, my concept of libxc and libstring_f as separate packages is probably obsolete, and the abinit-archived libxc-0.9 should be compiled as one package.
Cool, thanks. You might want to try w/ abinit 5.7.3 instead, it's using current bigdft. I intend to just make a snapshot of etsf_xc so we don't need to depend on a live package.
Created attachment 185110 [details, diff] sci-physics/wannier90/files/1.1-doc-fancyhdr.patch An updated version of my above mentioned patch to the documentation of wannier90. I'm particularly bad in finishing things, especially once they work acceptably for me even unfinished, but at least this one was easy. (Unfinished it worked, but was ugly.)
One more thing I've left unfinished: The right location for the fortran modules. Rather general and perhaps without an unequivocaly right solution, if I understand threads like https://www.redhat.com/archives/fedora-packaging/2007-October/msg00006.html or http://gcc.gnu.org/ml/fortran/2007-10/msg00304.html well. NetCDF ebuild puts hapilly its modules into /usr/include -- as far as I understand, that is clearly wrong. I opted for /usr/lib/finclude or /usr/$(get_libdir)/finclude in my ebuilds, which is just marginally better, not mixinf fortran modules with C preprocessor input, but still not keeping track of the compiler used. Abinit team choose (for abinit itself as well as for their adapted versions of the plug-ins; I haven't even tried to change that in my ebuilds of their versions of libxc and bigdft) /usr/include/<compiler_kind> -- at least using gfortran it turned up to be /usr/include/gcc. I guess that using lib rather than include may be prettier, but the real problem is that the compiler identification still is not specific enough. I have experienced myself the incompatibility of fortran modules created by gfortran 4.3.2 with code being compiled by gfortran 4.2.4. I conclude that <libdir>/<compiler_specific_files>/finclude, like /usr/lib/gcc/i686-pc-linux-gnu/4.3.3/finclude/, might be the best, but I haven't even tried that in my ebuilds, because I've been in doubt how to determine that directory automagically in the ebuilds, and especially how to allow for non-gnu compilers. Moreover, some packages, like the abinit version of bigdft, apply their own automagic and may require patching to accept a different one. In the end, given the scope of the problem, as well as the current netcdf behaviour, the best location for fortran modules should probably be discussed and set for the whole distribution.
I spent a while thinking about the module location too, and I tend to agree with your ebuilds. /usr/${libdir}/finclude seems like a good place for a distribution to put them, given that a distribution will tend to focus on a single compiler and we tell people to rebuild stuff after a compiler upgrade anyway.
By the way, I've got abinit 5.7.3 in my overlay. I'd appreciate your testing (layman -a dberkholz).
(In reply to comment #19) So far I've tried your 5.7.3 ebuild at x86 with gcc-4.3.3 with moderate success. The package, as well as its dependencies, builds. Having portage set up to perform tests I've however failed with bigdft, its testing programs segfaults (runs once `PS_Check 57 48 63 0 F > PS_Check.ou`, then crashes called as `PS_Check 57 48 63 1 F >> PS_Check.out`). Abinit itself has perfomed its tests mostly successfully, reporting only for v3: Case_86 failed (too many erroneous lines : 2 , accepted 1 ) and for v5: Case_63 failed Case_68 failed I haven't properly examined the causes of those erors, seems case 86 of v3 may be just a small numerical difference after all, but 63 and 68 in the v5 group apparently crashed in an early stage. At the end the ebuild failed due to the nonexistence of the summary_tests.tar.gz file -- so far I haven't found anything like that in the build directory, neither the reason of its absence.
(In addition to comment #20) I've tried to downgrade back to 5.6.5, adapting my ebuild to go well with your overlay and to report test result the same way as your 5.7.3. In comparison, the above mentioned results look mostly positive, 5.6.5 has reported more problems: Parameters and unusual results for v3 tests Case_97 failed (too large absolute error : 0.00088693 , accepted 0.0 ) . . . Parameters and unusual results for v5 tests Case_16 failed (too large absolute error : 9.9999999999989e-05 , accepted 1.1e-5 ) Case_17 failed (too large absolute error : 5.5238197e-07 , accepted 3.0e-8 ) Case_66 failed (too large absolute error : 0.179999999999993 , accepted 1.1e-2 ) Case_69 failed (too many erroneous lines : 8 , accepted 6 ) Parameters and unusual results for v4 tests Case_68 failed (too large absolute error : 1.62415702e-05 , accepted 0.0 ) My ebuild for bigdft-1.1.9 does not reproduce the crash of the PS_Check utility only because it does not even build that utility; only the 1.0.1 version patch by the Abinit developers (required for abinit-5.6.5) tests itself successfully (apparently without using anything called PC_Check). I had to create a new ebuild for libxc-0.9-r1 to be able to install the old version with the old module names expected by abinit-5.6.5 while I have in my portage tree your ebuild for the newer version used by the newer abinit -- although the names of the modules (not to speak of less obvious things) have changed, the version number has not.
Created attachment 188127 [details] abinit-5.6.5-r2.ebuild The abinit-5.6.5 ebuild adapted to dberkholz overlay. Handles the tests the same way as the 5.7.3 ebuild from the overlay, tries adding the archiving of the tests results.
Created attachment 188132 [details] libxc-0.9-r1.ebuild The ebuild for the old libxc-0.9 to build when there is the ebuild for the new libxc-0.9 in the portage tree. If there is any use in having this and abinit-5.6.5 in the tree, along the new version and abinit-5.7.3, the lack of version numbering upsream will have to be replaced by the means of the distribution.
Created attachment 188212 [details] abinit-5.6.5-r2.ebuild A bit of evolution. Now it actually installs the summary of the tests, I hope.
Created attachment 188214 [details, diff] abinit-5.7.3-r1.ebuild.diff A patch to the abinit-5.7.3 ebuild to install the summary of the tests.
Created attachment 188310 [details, diff] abinit-5.7.3-r2.ebuild.diff Diff to another variant of abinit-5.7.3 ebuild. Actually compiles against FoX if requested by a USE flag (FoX support is disabled by default in abinit so it 1. must be enabled explicitely, and 2. probably really should be controled by a USE flag). Supports compilation against sci-libs/gsl and sci-libs/fftw (version 2 -- although examples inside the abinit source tree suggest the use of fftw3, the <function>_f77 functions used are from the version 2 API, fftw3 uses d<function> names). For fftw I had to create a patch; not sure if it's correct, but one of my computers has at least compiled abinit with it, and now is calculating the tests.
Created attachment 188311 [details, diff] 5.7.3-fftw.patch The fftw patch for the abinit-5.7.3-r2.ebuild. May be applicable to previous versions too, but I haven't tested that. Currently testing it with 5.7.3.
(In addition to comment #26) With gsl and fftw the build does not look much different. At my favourit experimental x86 box (Sempron 2600+ notebook) the concise test report says: Parameters and unusual results for v3 tests Case_97 failed (too many erroneous lines : 180 , accepted 171 ) Parameters and unusual results for fast tests Parameters and unusual results for v2 tests Parameters and unusual results for v1 tests Parameters and unusual results for v5 tests Case_63 failed Case_68 failed Parameters and unusual results for v4 tests So in th v3 tests, case 97 fails the comparison criteria instead of case 86. Because I think I've upgraded lapack-atlas (from 3.8.2 or something like that to 3.9.3) in the meantime, the use of gsl and fftw may not even be the cause of this difference. The v5 cases 63 and 68 (bcc hydrogen) are a constant problem, abinit fails silently when reporting the symmetries of the input geometry. At another x86 box (Athlon 2500+ PC) I've got slightly different problems: Parameters and unusual results for v1 tests Case_40 failed Case_40 failed Parameters and unusual results for v2 tests Parameters and unusual results for v3 tests Case_69 failed Parameters and unusual results for v4 tests Parameters and unusual results for v5 tests Case_63 failed Case_68 failed Parameters and unusual results for fast tests V5 cases 63 and 68 failed the same way, v1 case 40 and v3 case 69 crashed similar way now, only it happened immediately after the summary of the abinit buit parameters. No nummerical error this time. May be the causes of problems are somwhere deep in the libraries used or other part of the system. I haven't even tried debugging. My first amd64 build went better. I had to include my compiler juggling in the bigdft-1.2.0 ebuild to compile it with MPI support (and its test with PS_Check crashed at amd64 with openMPI just like at x86 without MPI), but then abinit-5.7.3 with gsl and fftw achieved almost clean test result: Parameters and unusual results for v1 tests Parameters and unusual results for v4 tests Parameters and unusual results for fast tests Parameters and unusual results for v2 tests Parameters and unusual results for v3 tests Parameters and unusual results for v5 tests Case_64 failed (too many erroneous lines : 18 , accepted 17 )
The abinit guys basically suggested using blas-reference instead of goto/atlas if stuff fails. What are you using?
(In reply to comment #29) I am using ATLAS. Now I am recompiling the packages at my laptop to try using blas-reference, cblas-reference (at least via gsl), and lapack-reference. By the way, looking for packages to recompile I've found that your wannier90 ebuild does not declare dependence on virtual/blas and virtual/lapack although the package uses the linear algebra libraries (and your ebuild sets the respective library flags). I am going to report the results, but I suspect the worst failing tests to fail again. I don't belive the linear algebra libraries are called at all as early as the problematic tests crash, in the process of reading the input. And I would expect just numerical prolems of the libraries anyway, not sudden death of the program, let alone a silent one.
(In addition to comment #30) The concise report of abinit-5.7.3 installed at my laptop using the reference linear algebra libraries (and gsl and fftw): Parameters and unusual results for v3 tests Case_97 failed (too many erroneous lines : 183 , accepted 171 ) Parameters and unusual results for fast tests Parameters and unusual results for v2 tests Parameters and unusual results for v1 tests Parameters and unusual results for v5 tests Case_63 failed Case_68 failed Parameters and unusual results for v4 tests As expected, what used to crash reading input with ATLAS did so with the reference libraries as well. Apparently the reference libraries had not achieved any numerical improvement either, the same case (97 of v3) reported too many erroneous lines, there only were three more than before. So ATLAS may be better than reference even in terms of accuracy, not only speed. Or all the sources of problems simply lie outside the linear algebra libraries. I have noticed segmentation fault reported when the two most problematic tests crashed, but haven't yet even tried debugging.
(In addition to comment #31) At my Athlon 2500+ PC switching to the reference libraries helped a bit more: The test report is the same as that at my Sempron 2600+ laptop, two previous crashes were eliminated. Which surprises me, I'll have to try switching to ATLAS libraries again and repeat the tests.
(In addition to comment #32) Switching back from the reference linear algebra libraries to ATLAS at my Athlon XP 2500+ PC made the case 97 of v3 tests succeed, everything tested clean this time except the cases 63 and 68 of v5 that crashed again.
Core 2 Quad PC 9650 with ATLAS and OpenMPI, gsl and fftw: Parameters and unusual results for v2 tests Parameters and unusual results for v3 tests Parameters and unusual results for v1 tests Parameters and unusual results for fast tests Parameters and unusual results for v5 tests Case_17 within 1.5 of tolerance (relative error : 0.00480532161368435 , accepted 4.0e-3 ) Case_64 failed (too many erroneous lines : 18 , accepted 17 ) Case_85 failed (too many erroneous lines : 4 , accepted 3 ) Parameters and unusual results for v4 tests Case_71 within 1.5 of tolerance (relative error : 9.6628563210215e-08 , accepted 8.0e-8 ) Case_84 failed (too many erroneous lines : 20 , accepted 16 ) Not as good as my first 64 bit test, let alone perfect, but does not look like all hope is lost. Especially when I am in the course of system upgrade. Another of my 64 bit machines (dual quad core Opteron 2352, software configuration basically the same), currently having the system upgraded, failed worse: Parameters and unusual results for fast tests Case_11 failed Case_12 failed Case_14 failed Case_16 failed Case_19 failed Case_20 failed Case_21 failed Case_23 failed Parameters and unusual results for v3 tests Case_59 failed Case_63 failed Case_64 failed Parameters and unusual results for v4 tests Case_39 failed Case_71 within 1.5 of tolerance (relative error : 9.6628563210215e-08 , accepted 8.0e-8 ) Parameters and unusual results for v1 tests Case_07 failed Parameters and unusual results for v5 tests Case_64 failed (too many erroneous lines : 18 , accepted 17 ) Parameters and unusual results for v2 tests I've noticed more gcc versions at the last machine so I hope into some progress after extensive recompilations. My impression is that Abinit itself is basically OK, but its build turns out to be quite sensitive to the state of uncertain big number of other packages.
(In addition to comment #34) My Core 2 Quad PC 9650 with reference linear algebra libraries (using gsl and fftw as before): Parameters and unusual results for v2 tests Parameters and unusual results for v3 tests Case_40 failed (too many erroneous lines : 11 , accepted 10 ) Case_97 failed (too many erroneous lines : 183 , accepted 171 ) Parameters and unusual results for v1 tests Parameters and unusual results for fast tests Parameters and unusual results for v5 tests Parameters and unusual results for v4 tests Case_71 failed (too large relative error : 1.59808787825231e-07 , accepted 8.0e-8 )
(In addition to comment #34) My 64 dual Opteron 2352 machine using the reference linear algebra libraries -- quite a progress this time: Parameters and unusual results for fast tests Parameters and unusual results for v3 tests Parameters and unusual results for v4 tests Case_71 failed (too large relative error : 1.59808787825231e-07 , accepted 8.0e-8 ) Parameters and unusual results for v1 tests Parameters and unusual results for v5 tests Parameters and unusual results for v2 tests I am going to try switching back to ATLAS again; the Core 2 Quad PC, switched back to ATLAS, repeated the previous ATLAS test results, but in this case I hope not to repeat the previous crashes. What I have not tried so far is changing the compiler flags (-march=opteron -O2 at the dual Opteron box, -mtune=core2 -O2 at the Core 2 Quad); gsl and fftw did not seem to ruin the results at x86, so I'm inclined to keep using them.
(In addition to comment #36) My 64 dual Opteron 2352 machine using ATLAS again -- as I've hoped, no crash this time; one more failed test due to numerical discrepancies, but case 71 of v4 actually slightly closer to success: Parameters and unusual results for fast tests Parameters and unusual results for v3 tests Parameters and unusual results for v4 tests Case_71 within 1.5 of tolerance (relative error : 9.6628563210215e-08 , accepted 8.0e-8 ) Parameters and unusual results for v1 tests Parameters and unusual results for v5 tests Case_64 failed (too many erroneous lines : 18 , accepted 17 ) Parameters and unusual results for v2 tests
New Core i7 965 machine, with ATLAS, OpenMPI, fftw and gsl, optimisation flags "-march=native -O2": Parameters and unusual results for fast tests Parameters and unusual results for v1 tests Case_56 failed (too many erroneous lines : 4 , accepted 3 ) Parameters and unusual results for v2 tests Parameters and unusual results for v3 tests Case_40 failed (too many erroneous lines : 11 , accepted 10 ) Parameters and unusual results for v4 tests Parameters and unusual results for v5 tests Case_64 failed (too many erroneous lines : 18 , accepted 17 )
Honza, have you had a chance to try bumping to 5.8.4? I just finished my Ph.D and hope to find time to bump this in the main tree soon.
Created attachment 202961 [details] abinit-overlay.tar.lzma The archive of my current abinit overlay I use to build abinit-5.8.4. Several ebuilds taken from the dberkholz to have them at one place, and ocasionaly mangled to my needs and likings. A few of ebuilds from the main tree adapted here too (should report bugs for them as soon as I collect enough time and will to do this the proper way). Looks like it builds at x86, as well as at x86_64. Tests went almost well, especially in the 64 bit version -- one crash of cut3d may have been due to gcc version changes in the chain of dependencies. For now, I've managed to remove the crash by recompilations using gcc-4.4.1, but abinit output files now contain some char(0) instead of a handfull of linefeeds, so I'm recompiling my whole systems. The abinit ebuild in the attached overlay depends on fftw:2.1, but I suspect abinit-5.8.4 to compile against fftw:3.0 as well -- I'm in the process of trying. In case of success I'll try making the ebuild to use the 3 series even in the presence of the 2 one, currently abinit seems to prefer fftw-2.x.
I'm trying to change the name of this bug to reflect the current abinit version.
(In reply to comment #40) > The abinit ebuild in the attached overlay depends on fftw:2.1, but I suspect > abinit-5.8.4 to compile against fftw:3.0 as well -- I'm in the process of > trying. In case of success I'll try making the ebuild to use the 3 series even > in the presence of the 2 one, currently abinit seems to prefer fftw-2.x. Once again I was talking some nonsense -- the abinit code is fftw-2.x style, I shouldn't have got carried astray by something called fftw3 being mentioned in some example configurations.
(In reply to comment #40) > ... For now, I've managed to remove > the crash by recompilations using gcc-4.4.1, but abinit output files now > contain some char(0) instead of a handfull of linefeeds, so I'm recompiling my > whole systems. Recompiling has not help. I still have null characters in the abinit output. May that be a gcc-4.4.1 gfortran bug/feature? It breakes the comparison of the test results with the reference ones, but it may be just a minor obstacle in actual use.
I can confirm that the problem is with the compiler. I have a reduced testcase reported to GCC bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43146 Wirawan
Bumped in tree. Please test and report.
(In reply to comment #45) > Bumped in tree. Please test and report. > Builds on the old, last in the tree ebuild, ignores most of the work done within this bug. Or all of it? I hate that ebuild. Especially the option "plugins", enabling or disabling all of them at a time and leaving to the Abinit code to download their sources itself during the build, is terrible. We've got rid of that a long time ago here, haven't we? Polishing my own step up in the sequence of this bug, reflecting the evolution of the Abinit code, and with proper ebuilds for all the plugins. Going to post it here and reopen the bug. Plus open bugs for all the plugins ebuild, of course.
Created attachment 239795 [details] sci-physics/abinit-6.0.4.ebuild Still not perfect (plus I have some failed tests), but at least does not download anything during compilation.
Created attachment 239797 [details, diff] 6.0.3-change-default-directories.patch A patch used by sci-physics/abinit-6.0.4.ebuild to better comply to the Gentoo Linux directory structure.
Created attachment 239799 [details, diff] 6.0.3-fftw.patch A patch used by sci-physics/abinit-6.0.4.ebuild to compile against sci-libs/fftw:2.1
Created attachment 239801 [details, diff] 6.0.3-libxc-flags.patch A patch not actually used by sci-physics/abinit-6.0.4.ebuild -- tested for compilation against the current libxc SVN head.
As I've promissed I'm reopening this bug. Should add the dependency on FoX too, but that is currently unused anyway.
Honza, Would you be interested in maintaining all these ebuilds in the science overlay, while Donnie finds the time to push them into the main tree? If yes, either email me with your ssh pub key or pop in irc #gentoo-science @Donnie: have you got time to look at Honza's work? Thanks,
Created attachment 242557 [details, diff] abinit-6.0.4.ebuild.patch Corrects a small stupid error I did in my abinit-6.0.4.ebuild (wrong type of parentheses).
Created attachment 242561 [details] sci-physics/abinit-6.2.2.ebuild I don't have any hardware capable of GPU acceleration, so I don't use it and cannot test it. Variation of options not tested. More USE flags should probably be supported and the configuration structured properly, for now I've mostly hardcoded the includes and libraries used into the respective configure options. Some rudiments of my work towards the new functional ebuild may be present, as well as various other ugliness.
Created attachment 242563 [details, diff] 6.2.2-change-default-directories.patch Almost all of the original default directories changes now made upstream.
Created attachment 242565 [details, diff] 6.2.2-configure-fortran-calls.patch Patch for the configure tests of various libraries to actually succeed when the libraries are present. Incorrect fortran calls in the test programs changed to the correct prototypes.
Created attachment 242567 [details, diff] 6.2.2-long-message.patch One long error message, originally suffering by line truncation and breaking thus the compilation, split to multiple lines.
Created attachment 242569 [details, diff] 6.2.2-non-plugin-libs.patch Abinit seems to be passing from plug-ins to a libraries usage. I don't know what it actually means, haven't studied the internals, but now there are new groups of configure options --enable-dft (libxc+bigdft+wannier90), --enable-trio (etsf_io+hdf5+netcdf+fox, currently without FoX support actually, hence without XML pseudopotentials support), and analogous --enable-math, --enable-linalg and --enable-fft, all of them using --with-<category>-flavor plus respective includes and libs options. After enabling the usual dependencies this way, the configure script announces Disabling <library> plugin. The plugin disabling results in its libraries lists set void in the makefiles, no matter if options like --with-netcdf-libs were still used. At the same time, the options supplied for trio and dft groups are not reflected in the makefiles, so that the final linking fails for unresolved symbols due to the libraries missing. Also the fft libraries and includes, while worked on in the configuration scripts, are apparently by mistake not set in the created makefiles. This patch tries to correct all that.
Now I could, at least temporarily, change the bug title again to version bump, but the quality of my ebuild is best characterised by the present form anyway.
Tests of one instance (Core2 Duo E6750, 64 bit) finished. Do not look well at all, too many failures. I'll probably have to improve my ebuild and try setting and unsetting options.
dropped