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 <ba...@mcs.anl.gov> 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 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 >> 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 branch of >> PETSc with the version of hypre you installed. >> >> Barry >> >> >>> On Jul 20, 2023, at 5:10 AM, Daniel Stone <daniel.st...@opengosim.com> >>> wrote: >>> >>> 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 >>> CC arch-mswin-c-opt/obj/ksp/pc/impls/hypre/ftn-custom/zhypref.o >>> CC arch-mswin-c-opt/obj/ksp/pc/impls/hypre/ftn-auto/hypref.o >>> CC arch-mswin-c-opt/obj/ksp/pc/impls/hypre/hypre.o >>> C:\cygwin64\home\DANIEL~1\PETSC_~1.1\src\ksp\pc\impls\hypre\hypre.c(444,29): >>> error: assigning to 'hypre_Error' from incompatible type 'int' >>> hypre__global_error = 0; >>> ^ ~ >>> C:\cygwin64\home\DANIEL~1\PETSC_~1.1\include\petscerror.h(1752,7): note: >>> expanded from macro 'PetscStackCallExternalVoid' >>> __VA_ARGS__; \ >>> ^~~~~~~~~~~ >>> C:\cygwin64\home\DANIEL~1\PETSC_~1.1\src\ksp\pc\impls\hypre\hypre.c(634,29): >>> error: assigning to 'hypre_Error' from incompatible type 'int' >>> hypre__global_error = 0; >>> ^ ~ >>> C:\cygwin64\home\DANIEL~1\PETSC_~1.1\include\petscerror.h(1752,7): note: >>> expanded from macro 'PetscStackCallExternalVoid' >>> __VA_ARGS__; \ >>> ^~~~~~~~~~~ >>> 2 errors generated. >>> make[3]: *** [gmakefile:195: >>> arch-mswin-c-opt/obj/ksp/pc/impls/hypre/hypre.o] Error 1 >>> make[3]: *** Waiting for unfinished jobs.... >>> FC arch-mswin-c-opt/obj/ksp/f90-mod/petsckspdefmod.o >>> CC arch-mswin-c-opt/obj/dm/impls/da/hypre/mhyp.o >>> CC arch-mswin-c-opt/obj/mat/impls/hypre/mhypre.o >>> make[3]: Leaving directory '/home/DanielOGS/petsc_ogs_3.19.1' >>> make[2]: *** [/home/DanielOGS/petsc_ogs_3.19.1/lib/petsc/conf/rules.doc:28: >>> libs] Error 2 >>> make[2]: Leaving directory '/home/DanielOGS/petsc_ogs_3.19.1' >>> **************************ERROR************************************* >>> Error during compile, check arch-mswin-c-opt/lib/petsc/conf/make.log >>> Send it and arch-mswin-c-opt/lib/petsc/conf/configure.log to >>> petsc-ma...@mcs.anl.gov <mailto:petsc-ma...@mcs.anl.gov> >>> ******************************************************************** >>> Finishing make run at Wed, 19 Jul 2023 17:07:00 +0100 >>> >>> ---------------------------------------- >>> >>> But wait - isn't this the compile stage, not the linking stage? This seems >>> to imply that I've made a hash of providing include file such that a >>> definition of "hypre_Error" >>> cannot be seen - unless I'm misinterpreting. Interesting note about Hypre >>> and include files - if built using configure and make, all the include >>> files are conviniently copied >>> into hypre/src/hypre/include. This is not done for a cmake build - I had to >>> do the copying myself. Maybe I missed one. >>> >>> >>> On shared vs. static - if there a clear way of telling which I've ended up >>> with? I've checked the cmakelists for hypre and this seems to imply that >>> not-shared is the default, >>> which I didn't change: >>> >>> # Configuration options >>> option(HYPRE_ENABLE_SHARED "Build a shared library" OFF) >>> option(HYPRE_ENABLE_BIGINT "Use long long int for HYPRE_Int" OFF) >>> option(HYPRE_ENABLE_MIXEDINT "Use long long int for HYPRE_BigInt, >>> int for HYPRE_INT" OFF) >>> [....] >>> >>> >>> checking again, I've noticed that the way that the stub-test fails is >>> different depending on whether it's called from the config script or used >>> in isolation - more details on that soon. >>> >>> >>> >>> Thanks again, >>> >>> Daniel >>> >>> >>> >>> On Wed, Jul 19, 2023 at 4:58 PM Satish Balay via petsc-users >>> <petsc-users@mcs.anl.gov <mailto:petsc-users@mcs.anl.gov>> wrote: >>>> 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 SDKs/MPI/Lib/x64 >>>> $ nm -Ao msmpi.lib |grep " MPI_Init" >>>> msmpi.lib:msmpi.dll:0000000000000000 T MPI_Init >>>> msmpi.lib:msmpi.dll:0000000000000000 T MPI_Init_thread >>>> msmpi.lib:msmpi.dll:0000000000000000 T MPI_Initialized >>>> >>>> However - if the library symbol is somehow mangled - this configure mode >>>> of checking library functions will fail. >>>> >>>> Checking PETSc dll build: >>>> >>>> balay@ps5 ~/petsc/arch-ci-mswin-uni/lib >>>> $ nm -Ao libpetsc.lib |grep MatCreateSeqAIJWithArrays >>>> libpetsc.lib:libpetsc.dll:0000000000000000 I >>>> __imp_MatCreateSeqAIJWithArrays >>>> libpetsc.lib:libpetsc.dll:0000000000000000 T MatCreateSeqAIJWithArrays >>>> >>>> It also has the unmangled symbol - so I guess this mode can work generally >>>> with dlls. >>>> >>>> Satish >>>> >>>> >>>> On Wed, 19 Jul 2023, Barry Smith wrote: >>>> >>>>> >>>>> 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 >>>>> cannot since the configure tests will fail). >>>>> >>>>> Barry >>>>> >>>>> >>>>>> On Jul 19, 2023, at 11:40 AM, Satish Balay <ba...@mcs.anl.gov >>>>>> <mailto:ba...@mcs.anl.gov>> wrote: >>>>>> >>>>>> 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 main(void) { >>>>>> _check_HYPRE_IJMatrixCreate(); >>>>>> return 0; >>>>>> } >>>>>> <<<<<<< >>>>>> >>>>>> Note - it does not include 'HYPRE.h' here - but redefines the prototype >>>>>> as 'char HYPRE_IJMatrixCreate(); >>>>>> >>>>>> Compiling it manually: >>>>>> >>>>>>>>>> >>>>>> [balay@pj01 petsc]$ cat conftest.c >>>>>> char HYPRE_IJMatrixCreate(); >>>>>> static void _check_HYPRE_IJMatrixCreate() { HYPRE_IJMatrixCreate(); } >>>>>> >>>>>> int main(void) { >>>>>> _check_HYPRE_IJMatrixCreate(); >>>>>> return 0; >>>>>> } >>>>>> [balay@pj01 petsc]$ gcc -c conftest.c >>>>>> [balay@pj01 petsc]$ nm -Ao conftest.o |grep HYPRE_IJMatrixCreate >>>>>> conftest.o:0000000000000000 t _check_HYPRE_IJMatrixCreate >>>>>> conftest.o: U HYPRE_IJMatrixCreate >>>>>> [balay@pj01 petsc]$ nm -Ao arch-linux-c-debug/lib/libHYPRE.so |grep >>>>>> HYPRE_IJMatrixCreate >>>>>> arch-linux-c-debug/lib/libHYPRE.so:000000000007f2c2 T >>>>>> HYPRE_IJMatrixCreate >>>>>> [balay@pj01 petsc]$ >>>>>> <<<< >>>>>> >>>>>> Here the "U HYPRE_IJMatrixCreate" in conftest.o matches "T >>>>>> HYPRE_IJMatrixCreate" in libHYPRE.so - so the "link" test in configure >>>>>> succeeds! >>>>>> >>>>>>>>>>>> >>>>>> [balay@pj01 petsc]$ gcc -o conftest conftest.o >>>>>> arch-linux-c-debug/lib/libHYPRE.so >>>>>> [balay@pj01 petsc]$ echo $? >>>>>> 0 >>>>>> <<<<< >>>>>> >>>>>> On windows - [due to name mangling by cdecl/stdcall, (/MT vs /MD) etc..] >>>>>> - this might not match - resulting in link failures. >>>>>> >>>>>> Satish >>>>>> >>>>>> >>>>>> On Wed, 19 Jul 2023, Satish Balay via petsc-users wrote: >>>>>> >>>>>>> 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 >>>>>>> --- a/config/BuildSystem/config/packages/hypre.py >>>>>>> +++ b/config/BuildSystem/config/packages/hypre.py >>>>>>> @@ -11,7 +11,7 @@ class Configure(config.package.GNUPackage): >>>>>>> self.requiresversion = 1 >>>>>>> self.gitcommit = 'v'+self.version >>>>>>> self.download = >>>>>>> ['git://https://github.com/hypre-space/hypre','https://github.com/hypre-space/hypre/archive/'+self.gitcommit+'.tar.gz'] >>>>>>> - self.functions = ['HYPRE_IJMatrixCreate'] >>>>>>> + self.functions = [] >>>>>>> self.includes = ['HYPRE.h'] >>>>>>> self.liblist = [['libHYPRE.a']] >>>>>>> self.buildLanguages = ['C','Cxx'] >>>>>>> >>>>>>> >>>>>>> Satish >>>>>>> >>>>>>> >>>>>>> On Wed, 19 Jul 2023, Barry Smith wrote: >>>>>>> >>>>>>>> >>>>>>>> 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 to prepend something to the function >>>>>>>> prototype to have it successfully found. For example the PETSc include >>>>>>>> files have these things __declspec(dllimport) The configure test fails >>>>>>>> because it does not provide the needed prototype. Likely you built >>>>>>>> PTScotch with static libraries so no problem. >>>>>>>> >>>>>>>> The simplest fix would be to build static hypre libraries. I think it >>>>>>>> is a major project to get PETSc configure and macro system to work >>>>>>>> properly with external packages that are in Windows shared libraries >>>>>>>> since more use of __declspec would be needed. >>>>>>>> >>>>>>>> Barry >>>>>>>> >>>>>>>> The PETSc installation instructions should probably say something >>>>>>>> about external packages with Windows shared libraries. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Jul 19, 2023, at 10:52 AM, Daniel Stone >>>>>>>>> <daniel.st...@opengosim.com <mailto:daniel.st...@opengosim.com>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I'm working on getting a petsc build running on windows. One >>>>>>>>> necessary package to include is Hypre. I've been able to build Hypre >>>>>>>>> seperately using cmake, and confirmed that the library works >>>>>>>>> by setting up a VS project to run some of the example programs. >>>>>>>>> >>>>>>>>> My attempted petsc build is being done through cygwin. I've been able >>>>>>>>> to (with varying degrees of difficulty), build a fairly plain petsc, >>>>>>>>> and one that downloads and builds ptscotch (after some modifications >>>>>>>>> to both ptscotch and the config script). I am now attempting to >>>>>>>>> include Hypre (using the --hypre-iclude and --hypre-lib flags, etc). >>>>>>>>> Note that the same compilers are being used for both Hypre and for >>>>>>>>> petsc >>>>>>>>> through cygwin - the new intel oneapi compilers (icx and ifx, after >>>>>>>>> again varying amounts of pain to work around their awkwardness with >>>>>>>>> the config script). >>>>>>>>> >>>>>>>>> I'm seeing a problem when the config script does some tests on the >>>>>>>>> included hypre lib. The source code looks like: >>>>>>>>> >>>>>>>>> #include "confdefs.h" >>>>>>>>> #include "conffix.h" >>>>>>>>> /* Override any gcc2 internal prototype to avoid an error. */ >>>>>>>>> >>>>>>>>> #include "HYPRE.h" >>>>>>>>> >>>>>>>>> char HYPRE_IJMatrixCreate(); >>>>>>>>> static void _check_HYPRE_IJMatrixCreate() { HYPRE_IJMatrixCreate(); } >>>>>>>>> >>>>>>>>> int main() { >>>>>>>>> _check_HYPRE_IJMatrixCreate();; >>>>>>>>> return 0; >>>>>>>>> } >>>>>>>>> >>>>>>>>> >>>>>>>>> As I understand this is a fairly standard type of stub program used >>>>>>>>> by the config script to check that it is able to link to certain >>>>>>>>> symbols in given libraries. Tests like this have succeeded in my >>>>>>>>> builds that >>>>>>>>> include PTScotch. >>>>>>>>> >>>>>>>>> I keep getting a linker error with the above test, including if I >>>>>>>>> seperate it out and try to build it seperately: >>>>>>>>> >>>>>>>>> unresolved external symbol "char __cdel HYPRE_IJMatrixCreate(void)" >>>>>>>>> .... >>>>>>>>> >>>>>>>>> Ok, it looks like a problem with either the library or linker >>>>>>>>> commands. But here's the interesting thing - If I transplant this >>>>>>>>> code into VS, with the same project setting that allows it to build >>>>>>>>> the much more >>>>>>>>> nontrivial Hypre example programs, I get the same error: >>>>>>>>> >>>>>>>>> Error LNK2001 unresolved external symbol "char __cdecl >>>>>>>>> HYPRE_IJMatrixCreate(void)" (?HYPRE_IJMatrixCreate@@YADXZ) hypretry1 >>>>>>>>> C:\Users\DanielOGS\source\repos\hypretry1\hypretry1\Source.obj 1 >>>>>>>>> >>>>>>>>> So it seems like there might be something about this type of stub >>>>>>>>> program that is not working with my Hypre library. I don't fully >>>>>>>>> understand this program - it's able to call the function with no >>>>>>>>> arguments, but >>>>>>>>> it also needs to be linked against a library containing the function, >>>>>>>>> apparently by wrapping it in a static void function? Not something >>>>>>>>> I've seen before. >>>>>>>>> >>>>>>>>> Does anyone have any insight into what might be going wrong - or >>>>>>>>> really just any explaination of how the stub program works so I can >>>>>>>>> figure out why it isn't in this case? >>>>>>>>> >>>>>>>>> Many thanks, >>>>>>>>> >>>>>>>>> Daniel >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> >>
