This still isn't working, and it looks like the md/mt distinciton might be
the culprit.
I use the Ninja generator with cmake, on the intel oneapi command line
(i.e. windows command line but with the pathing and other things sorted out
for the new intel compilers).
Looking at the build.ninja file
On the hypre versioning - aha. For this project I locked the petsc version
a little while ago (3.19.1), but I've been using a fresh clone of hypre, so
clearly
it's too modern a version. Using the appropriate version of hypre (2.28.0,
according to hypre.py) might fix some things.
I may have other
hypre_Error was changed from an integer to a struct in hypre. PETSc code was
changed in main to work with that struct and not work if hypre_Error is an int.
This means main cannot work with previous hypre versions (where hypre_Error is
an int). Sure, instead of changing the minimum version
We don't have a good way to verify if the changes continue to work
with the minver of the pkg [and if minor fixes can get this working -
without increasing this requirement - sure without access to the new
features provided by the new version]
Having a single version dependency between pkgs makes
Satish,
I think hypre.py in main needs minversion = 2.29 instead of 2.14
> On Jul 20, 2023, at 11:05 AM, Satish Balay wrote:
>
> Can check config/BuildSystem/config/packages/hypre.py
>
> petsc-3.19 (or release branch) is compatible with hypre 2.28.0, petsc 'main'
> branch with
On Thu, 20 Jul 2023, Daniel Stone wrote:
> Ok, so the test does exhibit different errors when run through the config
> script, compared to my attempts to isolate it:
>
>
>
> Executing: [compilation command]
>
> successful compile:
> Source:
> #include "confdefs.h"
Can check config/BuildSystem/config/packages/hypre.py
petsc-3.19 (or release branch) is compatible with hypre 2.28.0, petsc 'main'
branch with 2.29.0
Satish
On Thu, 20 Jul 2023, Barry Smith via petsc-users wrote:
>
> You cannot use this version of PETSc, 3.19, with the version of hypre you
You cannot use this version of PETSc, 3.19, with the version of hypre you
installed. In hypre they recently changed hypre_Error from an integer to a
struct which completely breaks compatibility with previous versions of hypre
(and hence previous versions of PETSc). You must use the main git
Ok, so the test does exhibit different errors when run through the config
script, compared to my attempts to isolate it:
Executing: [compilation command]
successful compile:
Source:
#include "confdefs.h"
#include "conffix.h"
/* Override any gcc2 internal prototype
Hi All,
Many thanks for the detailed explainations and ideas!
I tried skipping the test. When it came time to do the build itself (make
$PETSC_DIR... all) I get some failures, unsurprisingly:
FC arch-mswin-c-opt/obj/dm/f90-mod/petscdmplexmod.o
I think it should work with static libraries and 64bit compilers.
That's how I think --download-f2cblaslapack [etc] work.
Also it works with MS-MPI - even-though its a dll install, the library stub
provides this symbol somehow..
balay@ps5 /cygdrive/c/Program Files (x86)/Microsoft
Satish,
So it will always fail on Windows with Windows compilers (both with static
and shared libraries)? Is this true for all PETSc external packages? If so, why
does the installation documentation say that some external packages can work
with Windows compilers? (Presumably PETSc
BTW: Some explanation of configure:
It attempts the following on linux:
>>
Source:
#include "confdefs.h"
#include "conffix.h"
/* Override any gcc2 internal prototype to avoid an error. */
char HYPRE_IJMatrixCreate();
static void _check_HYPRE_IJMatrixCreate() { HYPRE_IJMatrixCreate(); }
int
You could try skipping this test [and assume --with-hypre-include and
--with-hypre-lib options are correct] - and see if this works.
diff --git a/config/BuildSystem/config/packages/hypre.py
b/config/BuildSystem/config/packages/hypre.py
index 5bc88322aa2..2d6c7932e17 100644
---
You don't indicate what type of libraries you built hypre with; static or
shared. My guess is you ended up with shared
I think the answer to your difficulty is hidden in __cdecl (Satish will know
much better than me). When you are looking for symbols in Windows shared
libraries you have
15 matches
Mail list logo
