Re: [petsc-users] Confusion/failures about the tests involved in including Hypre

2023-07-20 Thread Barry Smith 


  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 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  
>>> 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 
>>> 
>>> 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 
>>> 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

Re: [petsc-users] Confusion/failures about the tests involved in including Hypre

2023-07-20 Thread Satish Balay via petsc-users 
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"
> #include "conffix.h"
> /* Override any gcc2 internal prototype to avoid an error. */
> char HYPRE_IJMatrixCreate();
> static void _check_HYPRE_IJMatrixCreate() { HYPRE_IJMatrixCreate(); }
> 
> int main() {
> _check_HYPRE_IJMatrixCreate();;
>   return 0;
> }
> 
> Executing: [linker command]
> 
> stdout:
> LINK : warning LNK4098: defaultlib 'msvcrtd.lib' conflicts with use of
> other libs; use /NODEFAULTLIB:library
> LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in
> 'libucrt.lib(output.obj)' is imported by 'HYPRE.lib(dtrmm.c.obj)'

This error comes up when building different objfiles [or libraries] that go 
into a single binary with different compiler options - for ex: one with /MD - 
the other with /MT [each option sets and links with a different default 
compiler library - resulting in such conflicts]

https://learn.microsoft.com/en-us/cpp/build/reference/md-mt-ld-use-run-time-library?view=msvc-170

so the usual fix is to make sure all libraries, objfiles are compiled with the 
same compiler options

Satish

> LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in
> 'libucrt.lib(output.obj)' is imported by 'HYPRE.lib(dtrmv.c.obj)'
> LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in
> 'libucrt.lib(output.obj)' is imported by 'HYPRE.lib(lsame.c.obj)'
> LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in
> 'libucrt.lib(output.obj)' is imported by 'HYPRE.lib(xerbla.c.obj)'
> LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in
> 'libucrt.lib(output.obj)' is imported by 'HYPRE.lib(lsame.c.obj)'
> LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in
> 'libucrt.lib(output.obj)' is imported by 'HYPRE.lib(dtrti2.c.obj)'
> [etc...]
> HYPRE.lib(par_vector.c.obj) : error LNK2019: unresolved external symbol
> __imp__wassert referenced in function hypre_ParVectorDestroy
> HYPRE.lib(vector.c.obj) : error LNK2001: unresolved external symbol
> __imp__wassert
> HYPRE.lib(par_csr_matop.c.obj) : error LNK2001: unresolved external symbol
> __imp__wassert
> HYPRE.lib(par_csr_communication.c.obj) : error LNK2001: unresolved external
> symbol __imp__wassert
> HYPRE.lib(csr_matop.c.obj) : error LNK2001: unresolved external symbol
> __imp__wassert
> HYPRE.lib(merge_sort.c.obj) : error LNK2001: unresolved external symbol
> __imp__wassert
> HYPRE.lib(memory.c.obj) : error LNK2001: unresolved external symbol
> __imp__wassert
> HYPRE.lib(IJMatrix_parcsr.c.obj) : error LNK2001: unresolved external
> symbol __imp__wassert
> HYPRE.lib(par_csr_matrix.c.obj) : error LNK2001: unresolved external symbol
> __imp__wassert
> HYPRE.lib(csr_matrix.c.obj) : error LNK2001: unresolved external symbol
> __imp__wassert
> HYPRE.lib(memory.c.obj) : error LNK2019: unresolved external symbol
> __imp_realloc referenced in function hypre_ReAlloc
> HYPRE.lib(par_vector.c.obj) : error LNK2001: unresolved external symbol
> __imp_fopen
> HYPRE.lib(vector.c.obj) : error LNK2001: unresolved external symbol
> __imp_fopen
> HYPRE.lib(IJMatrix.c.obj) : error LNK2001: unresolved external symbol
> __imp_fopen
> HYPRE.lib(par_csr_matrix.c.obj) : error LNK2001: unresolved external symbol
> __imp_fopen
> HYPRE.lib(csr_matrix.c.obj) : error LNK2001: unresolved external symbol
> __imp_fopen
> HYPRE.lib(new_commpkg.c.obj) : error LNK2001: unresolved external symbol
> __imp_fopen
> HYPRE.lib(printf.c.obj) : error LNK2019: unresolved external symbol
> __imp___stdio_common_vfscanf referenced in function _vfscanf_l
> HYPRE.lib(printf.c.obj) : error LNK2019: unresolved external symbol
> __imp___stdio_common_vsscanf referenced in function _vsscanf_l
> HYPRE.lib(mmio.c.obj) : error LNK2001: unresolved external symbol
> __imp___stdio_common_vsscanf
> HYPRE.lib(mmio.c.obj) : error LNK2019: unresolved external symbol
> __imp_fgets referenced in function hypre_mm_read_banner
> HYPRE.lib(mmio.c.obj) : error LNK2019: unresolved external symbol
> __imp_tolower referenced in function hypre_mm_read_banner
> C:\cygwin64\tmp\PE0681~1\CONFIG~1.LIB\conftest.exe : fatal error LNK1120: 7
> unresolved externals
> icx: error: linker command failed with exit code 1120 (use -v to see
> invocation)
> Possible ERROR while running linker: exit code 96
> [more warnings etc]
> 
> 
> -
> 
> I've looked at the oneapi compiler documentation, and it seems like
> "nodefaultlib", "nostdlib", etc, options only work for linux versions of
> the compiler,
> so I'm not sure what to do about the first warning. From the errors, it
> looks like some core c or c++ library that hypre depends on isn't visible.
> I had some similar
> issues with ptscotch - but in that case I didn't have the warnings, and the

Re: [petsc-users] Failing PETSc 3.19.2 compile using ICPC

2023-07-20 Thread Jacob Faibussowitsch 
Robert,

Try this branch jacobf/2023-07-20/icpc-compressed-pair-workaround/release and 
let me know if that worked.

Best regards,

Jacob Faibussowitsch
(Jacob Fai - booss - oh - vitch)

> On Jul 20, 2023, at 10:44, Barry Smith  wrote:
> 
> 
>  Suitesparse provides good efficient sequential (non-MPI) sparse direct 
> solvers. Probably a bit more efficient than the sequential sparse direct 
> solvers built into PETSc. So it really depends on how you use PETSc to solve 
> your linear systems, if you use iterative methods, such as algebraic 
> multigrid then it doesn't matter. 
> 
> 
> 
>> On Jul 20, 2023, at 10:27 AM, robert.crock...@lamresearch.com wrote:
>> 
>> Satish,
>> Unfortunately, --with-cxx-dialect=11 did not fix the problem.
>> 
>> Can you or others on the list tell me the effect on solving large sparse 
>> real symmetric and unsymmetric problems, if --with-cxx=0 and suitesparse is 
>> not downloaded?
>> Thanks,
>> Robert
>> 
>> 
>> Confidential – Limited Access and Use
>> -Original Message-
>> From: Satish Balay 
>> Sent: Wednesday, July 19, 2023 5:07 PM
>> To: Barry Smith 
>> Cc: Crockett, Robert ; 
>> petsc-users@mcs.anl.gov
>> Subject: Re: [petsc-users] Failing PETSc 3.19.2 compile using ICPC
>> 
>> 
>> you can try --with-cxx-dialect=11 and see if that works.
>> 
>> with -with-cxx=0 - --download-suitesparse [and other pkgs that require cxx] 
>> won't work - and would need to be installed separately
>> 
>> Jacob,
>> 
>> One more use case for --with-cxx-bindings=0
>> 
>> Satish
>> 
>> On Wed, 19 Jul 2023, Barry Smith wrote:
>> 
>>> 
>>> Do you need C++, you can configure --with-cxx=0 if you do not need it.
>>> 
>>> You can also try the main branch of PETSc or slightly different versions of 
>>> the compiler.
>>> 
>>> Barry
>>> 
>>> 
>>> 
 On Jul 19, 2023, at 4:31 PM, Robert Crockett via petsc-users 
  wrote:
 
 Hello,
 I am attempting to build PETSc using the 2018.5.274 Intel compiler suite 
 on CentOS7. I get the below error messages.
 See the attached for more information.
 The file petscbuild.sh is the script used to configure and build The
 file configure.log is output by PETSc The file log.petscbuild is the
 output of the config & build script.
 
 Can you please help find a work-around?
 Best,
 Robert
 
 PS. Some related links I found in searching on this issue.
 The first references a related compiler bug ticket opened with Intel, 
 though I cannot tell if it was closed or if it applied to my compiler.
 https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fco
 mmunity.intel.com%2Ft5%2FIntel-C-Compiler%2FDefault-constructor-of-v
 ariant-is-deleted%2Fm-p%2F1156212%3Fprofile.language%3Den=05%7C
 01%7CRobert.Crockett%40lamresearch.com%7C616797c1562a4487ab5008db889
 c18bc%7C918079dbc9024e29b22c9764410d0375%7C0%7C0%7C63825397626768035
 8%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
 I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=aLTeNz0m6xZ4df8AyndNe
 38vqD16gbTfWuKHGw735%2BY%3D=0
 https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fme
 diatum.ub.tum.de%2Fdoc%2F1555265%2F1555265.pdf=05%7C01%7CRobert
 .Crockett%40lamresearch.com%7C616797c1562a4487ab5008db889c18bc%7C918
 079dbc9024e29b22c9764410d0375%7C0%7C0%7C638253976267680358%7CUnknown
 %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
 CJXVCI6Mn0%3D%7C3000%7C%7C%7C=KfN8V%2BPnJs5kr5itDINRXfrFUOpRX3
 Kok9OtAC4k1pg%3D=0
 
 Robert Crockett
 Plasma Simulation Engineer | OCTO - Computational Products
 P: 617.648.8349  M: 415.205.4567
 
 LAM RESEARCH
 4650 Cushing Pkwy, Fremont CA 94538 USA lamresearch.com
  
 
 -
 Using C compile: /usr/local/petsc/r/bin/mpicc -o .o -c -wd1572
 -Wno-unknown-pragmas -O3 -mtune=generic mpicc -show: icc -fPIC
 -wd1572 -O3 -mtune=generic -I/usr/local/petsc/r/include
 -L/usr/local/petsc/r/lib -Wl,-rpath -Wl,/usr/local/petsc/r/lib
 -Wl,--enable-new-dtags -lmpi C compiler version: icc (ICC) 18.0.5
 20180823 Using C++ compile: /usr/local/petsc/r/bin/mpicxx -o .o -c
 -wd1572 -O3 -mtune=generic  -std=c++14
 -I/usr/local/share/petsc/src/include
 -I/usr/local/share/petsc/src/arch-linux-c-opt/include
 -I/usr/local/petsc/r/include mpicxx -show: icpc -wd1572 -O3
 -mtune=generic -std=c++14 -fPIC -I/usr/local/petsc/r/include
 -L/usr/local/petsc/r/lib -lmpicxx -Wl,-rpath
 -Wl,/usr/local/petsc/r/lib -Wl,--enable-new-dtags -lmpi
 C++ compiler version: icpc (ICC) 18.0.5 20180823
 Using Fortran compile: /usr/local/petsc/r/bin/mpif90 -o .o -c -Wall 
 -ffree-line-length-none -ffree-line-length-0 -Wno-lto-type-mismatch 
 -Wno-unused-dummy-argument -O3 -mtune=generic   
 -I/usr/local/share/petsc/src/include 
 -I/usr/local/share/petsc/src/arch-linux-c-opt/include

Re: [petsc-users] Confusion/failures about the tests involved in including Hypre

2023-07-20 Thread Satish Balay via petsc-users 
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  
> > 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 
> > 
> > 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 
> > 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: T MPI_Init
> >> msmpi.lib:msmpi.dll: T MPI_Init_thread
> >>

Re: [petsc-users] Failing PETSc 3.19.2 compile using ICPC

2023-07-20 Thread Barry Smith 


  Suitesparse provides good efficient sequential (non-MPI) sparse direct 
solvers. Probably a bit more efficient than the sequential sparse direct 
solvers built into PETSc. So it really depends on how you use PETSc to solve 
your linear systems, if you use iterative methods, such as algebraic multigrid 
then it doesn't matter. 

  

> On Jul 20, 2023, at 10:27 AM, robert.crock...@lamresearch.com wrote:
> 
> Satish,
> Unfortunately, --with-cxx-dialect=11 did not fix the problem.
> 
> Can you or others on the list tell me the effect on solving large sparse real 
> symmetric and unsymmetric problems, if --with-cxx=0 and suitesparse is not 
> downloaded?
> Thanks,
> Robert
> 
> 
> Confidential – Limited Access and Use
> -Original Message-
> From: Satish Balay 
> Sent: Wednesday, July 19, 2023 5:07 PM
> To: Barry Smith 
> Cc: Crockett, Robert ; 
> petsc-users@mcs.anl.gov
> Subject: Re: [petsc-users] Failing PETSc 3.19.2 compile using ICPC
> 
> 
> you can try --with-cxx-dialect=11 and see if that works.
> 
> with -with-cxx=0 - --download-suitesparse [and other pkgs that require cxx] 
> won't work - and would need to be installed separately
> 
> Jacob,
> 
> One more use case for --with-cxx-bindings=0
> 
> Satish
> 
> On Wed, 19 Jul 2023, Barry Smith wrote:
> 
>> 
>>  Do you need C++, you can configure --with-cxx=0 if you do not need it.
>> 
>>  You can also try the main branch of PETSc or slightly different versions of 
>> the compiler.
>> 
>>  Barry
>> 
>> 
>> 
>>> On Jul 19, 2023, at 4:31 PM, Robert Crockett via petsc-users 
>>>  wrote:
>>> 
>>> Hello,
>>> I am attempting to build PETSc using the 2018.5.274 Intel compiler suite on 
>>> CentOS7. I get the below error messages.
>>> See the attached for more information.
>>> The file petscbuild.sh is the script used to configure and build The
>>> file configure.log is output by PETSc The file log.petscbuild is the
>>> output of the config & build script.
>>> 
>>> Can you please help find a work-around?
>>> Best,
>>> Robert
>>> 
>>> PS. Some related links I found in searching on this issue.
>>> The first references a related compiler bug ticket opened with Intel, 
>>> though I cannot tell if it was closed or if it applied to my compiler.
>>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fco
>>> mmunity.intel.com%2Ft5%2FIntel-C-Compiler%2FDefault-constructor-of-v
>>> ariant-is-deleted%2Fm-p%2F1156212%3Fprofile.language%3Den=05%7C
>>> 01%7CRobert.Crockett%40lamresearch.com%7C616797c1562a4487ab5008db889
>>> c18bc%7C918079dbc9024e29b22c9764410d0375%7C0%7C0%7C63825397626768035
>>> 8%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
>>> I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=aLTeNz0m6xZ4df8AyndNe
>>> 38vqD16gbTfWuKHGw735%2BY%3D=0
>>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fme
>>> diatum.ub.tum.de%2Fdoc%2F1555265%2F1555265.pdf=05%7C01%7CRobert
>>> .Crockett%40lamresearch.com%7C616797c1562a4487ab5008db889c18bc%7C918
>>> 079dbc9024e29b22c9764410d0375%7C0%7C0%7C638253976267680358%7CUnknown
>>> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
>>> CJXVCI6Mn0%3D%7C3000%7C%7C%7C=KfN8V%2BPnJs5kr5itDINRXfrFUOpRX3
>>> Kok9OtAC4k1pg%3D=0
>>> 
>>> Robert Crockett
>>> Plasma Simulation Engineer | OCTO - Computational Products
>>> P: 617.648.8349  M: 415.205.4567
>>> 
>>> LAM RESEARCH
>>> 4650 Cushing Pkwy, Fremont CA 94538 USA lamresearch.com
>>>  
>>> 
>>> -
>>> Using C compile: /usr/local/petsc/r/bin/mpicc -o .o -c -wd1572
>>> -Wno-unknown-pragmas -O3 -mtune=generic mpicc -show: icc -fPIC
>>> -wd1572 -O3 -mtune=generic -I/usr/local/petsc/r/include
>>> -L/usr/local/petsc/r/lib -Wl,-rpath -Wl,/usr/local/petsc/r/lib
>>> -Wl,--enable-new-dtags -lmpi C compiler version: icc (ICC) 18.0.5
>>> 20180823 Using C++ compile: /usr/local/petsc/r/bin/mpicxx -o .o -c
>>> -wd1572 -O3 -mtune=generic  -std=c++14
>>> -I/usr/local/share/petsc/src/include
>>> -I/usr/local/share/petsc/src/arch-linux-c-opt/include
>>> -I/usr/local/petsc/r/include mpicxx -show: icpc -wd1572 -O3
>>> -mtune=generic -std=c++14 -fPIC -I/usr/local/petsc/r/include
>>> -L/usr/local/petsc/r/lib -lmpicxx -Wl,-rpath
>>> -Wl,/usr/local/petsc/r/lib -Wl,--enable-new-dtags -lmpi
>>> C++ compiler version: icpc (ICC) 18.0.5 20180823
>>> Using Fortran compile: /usr/local/petsc/r/bin/mpif90 -o .o -c -Wall 
>>> -ffree-line-length-none -ffree-line-length-0 -Wno-lto-type-mismatch 
>>> -Wno-unused-dummy-argument -O3 -mtune=generic   
>>> -I/usr/local/share/petsc/src/include 
>>> -I/usr/local/share/petsc/src/arch-linux-c-opt/include 
>>> -I/usr/local/petsc/r/include
>>> mpif90 -show: gfortran -fPIC -ffree-line-length-none
>>> -ffree-line-length-0 -Wno-lto-type-mismatch -O3 -mtune=generic
>>> -I/usr/local/petsc/r/include -I/usr/local/petsc/r/include
>>> -L/usr/local/petsc/r/lib -lmpifort -Wl,-rpath
>>> -Wl,/usr/local/petsc/r/lib -Wl,--enable-new-dtags -lmpi Fortran
>>> compiler

Re: [petsc-users] Failing PETSc 3.19.2 compile using ICPC

2023-07-20 Thread Robert Crockett via petsc-users 
Satish,
Unfortunately, --with-cxx-dialect=11 did not fix the problem.

Can you or others on the list tell me the effect on solving large sparse real 
symmetric and unsymmetric problems, if --with-cxx=0 and suitesparse is not 
downloaded?
Thanks,
Robert


Confidential – Limited Access and Use
-Original Message-
From: Satish Balay 
Sent: Wednesday, July 19, 2023 5:07 PM
To: Barry Smith 
Cc: Crockett, Robert ; petsc-users@mcs.anl.gov
Subject: Re: [petsc-users] Failing PETSc 3.19.2 compile using ICPC


you can try --with-cxx-dialect=11 and see if that works.

with -with-cxx=0 - --download-suitesparse [and other pkgs that require cxx] 
won't work - and would need to be installed separately

Jacob,

One more use case for --with-cxx-bindings=0

Satish

On Wed, 19 Jul 2023, Barry Smith wrote:

>
>   Do you need C++, you can configure --with-cxx=0 if you do not need it.
>
>   You can also try the main branch of PETSc or slightly different versions of 
> the compiler.
>
>   Barry
>
>
>
> > On Jul 19, 2023, at 4:31 PM, Robert Crockett via petsc-users 
> >  wrote:
> >
> > Hello,
> > I am attempting to build PETSc using the 2018.5.274 Intel compiler suite on 
> > CentOS7. I get the below error messages.
> > See the attached for more information.
> > The file petscbuild.sh is the script used to configure and build The
> > file configure.log is output by PETSc The file log.petscbuild is the
> > output of the config & build script.
> >
> > Can you please help find a work-around?
> > Best,
> > Robert
> >
> > PS. Some related links I found in searching on this issue.
> > The first references a related compiler bug ticket opened with Intel, 
> > though I cannot tell if it was closed or if it applied to my compiler.
> > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fco
> > mmunity.intel.com%2Ft5%2FIntel-C-Compiler%2FDefault-constructor-of-v
> > ariant-is-deleted%2Fm-p%2F1156212%3Fprofile.language%3Den=05%7C
> > 01%7CRobert.Crockett%40lamresearch.com%7C616797c1562a4487ab5008db889
> > c18bc%7C918079dbc9024e29b22c9764410d0375%7C0%7C0%7C63825397626768035
> > 8%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
> > I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=aLTeNz0m6xZ4df8AyndNe
> > 38vqD16gbTfWuKHGw735%2BY%3D=0
> > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fme
> > diatum.ub.tum.de%2Fdoc%2F1555265%2F1555265.pdf=05%7C01%7CRobert
> > .Crockett%40lamresearch.com%7C616797c1562a4487ab5008db889c18bc%7C918
> > 079dbc9024e29b22c9764410d0375%7C0%7C0%7C638253976267680358%7CUnknown
> > %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> > CJXVCI6Mn0%3D%7C3000%7C%7C%7C=KfN8V%2BPnJs5kr5itDINRXfrFUOpRX3
> > Kok9OtAC4k1pg%3D=0
> >
> > Robert Crockett
> > Plasma Simulation Engineer | OCTO - Computational Products
> > P: 617.648.8349  M: 415.205.4567
> >
> > LAM RESEARCH
> > 4650 Cushing Pkwy, Fremont CA 94538 USA lamresearch.com
> >  
> >
> > -
> > Using C compile: /usr/local/petsc/r/bin/mpicc -o .o -c -wd1572
> > -Wno-unknown-pragmas -O3 -mtune=generic mpicc -show: icc -fPIC
> > -wd1572 -O3 -mtune=generic -I/usr/local/petsc/r/include
> > -L/usr/local/petsc/r/lib -Wl,-rpath -Wl,/usr/local/petsc/r/lib
> > -Wl,--enable-new-dtags -lmpi C compiler version: icc (ICC) 18.0.5
> > 20180823 Using C++ compile: /usr/local/petsc/r/bin/mpicxx -o .o -c
> > -wd1572 -O3 -mtune=generic  -std=c++14
> > -I/usr/local/share/petsc/src/include
> > -I/usr/local/share/petsc/src/arch-linux-c-opt/include
> > -I/usr/local/petsc/r/include mpicxx -show: icpc -wd1572 -O3
> > -mtune=generic -std=c++14 -fPIC -I/usr/local/petsc/r/include
> > -L/usr/local/petsc/r/lib -lmpicxx -Wl,-rpath
> > -Wl,/usr/local/petsc/r/lib -Wl,--enable-new-dtags -lmpi
> > C++ compiler version: icpc (ICC) 18.0.5 20180823
> > Using Fortran compile: /usr/local/petsc/r/bin/mpif90 -o .o -c -Wall 
> > -ffree-line-length-none -ffree-line-length-0 -Wno-lto-type-mismatch 
> > -Wno-unused-dummy-argument -O3 -mtune=generic   
> > -I/usr/local/share/petsc/src/include 
> > -I/usr/local/share/petsc/src/arch-linux-c-opt/include 
> > -I/usr/local/petsc/r/include
> > mpif90 -show: gfortran -fPIC -ffree-line-length-none
> > -ffree-line-length-0 -Wno-lto-type-mismatch -O3 -mtune=generic
> > -I/usr/local/petsc/r/include -I/usr/local/petsc/r/include
> > -L/usr/local/petsc/r/lib -lmpifort -Wl,-rpath
> > -Wl,/usr/local/petsc/r/lib -Wl,--enable-new-dtags -lmpi Fortran
> > compiler version: GNU Fortran (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
> > -
> > Using C/C++ linker: /usr/local/petsc/r/bin/mpicc Using C/C++ flags:
> > -wd1572 -Wno-unknown-pragmas -O3 -mtune=generic Using Fortran
> > linker: /usr/local/petsc/r/bin/mpif90 Using Fortran flags: -Wall
> > -ffree-line-length-none -ffree-line-length-0 -Wno-lto-type-mismatch
> > -Wno-unused-dummy-argument -O3 -mtune=generic
> > -
> > Using system

Re: [petsc-users] Confusion/failures about the tests involved in including Hypre

2023-07-20 Thread Barry Smith via petsc-users 

  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  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 
> 
> 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 
> 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: T MPI_Init
>> msmpi.lib:msmpi.dll: T MPI_Init_thread
>> msmpi.lib:msmpi.dll: 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: I __imp_MatCreateSeqAIJWithArrays
>> libpetsc.lib:libpetsc.dll: T

Re: [petsc-users] Confusion/failures about the tests involved in including Hypre

2023-07-20 Thread Daniel Stone 
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 to avoid an error. */
char HYPRE_IJMatrixCreate();
static void _check_HYPRE_IJMatrixCreate() { HYPRE_IJMatrixCreate(); }

int main() {
_check_HYPRE_IJMatrixCreate();;
  return 0;
}

Executing: [linker command]

stdout:
LINK : warning LNK4098: defaultlib 'msvcrtd.lib' conflicts with use of
other libs; use /NODEFAULTLIB:library
LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in
'libucrt.lib(output.obj)' is imported by 'HYPRE.lib(dtrmm.c.obj)'
LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in
'libucrt.lib(output.obj)' is imported by 'HYPRE.lib(dtrmv.c.obj)'
LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in
'libucrt.lib(output.obj)' is imported by 'HYPRE.lib(lsame.c.obj)'
LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in
'libucrt.lib(output.obj)' is imported by 'HYPRE.lib(xerbla.c.obj)'
LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in
'libucrt.lib(output.obj)' is imported by 'HYPRE.lib(lsame.c.obj)'
LINK : warning LNK4286: symbol '__stdio_common_vsprintf' defined in
'libucrt.lib(output.obj)' is imported by 'HYPRE.lib(dtrti2.c.obj)'
[etc...]
HYPRE.lib(par_vector.c.obj) : error LNK2019: unresolved external symbol
__imp__wassert referenced in function hypre_ParVectorDestroy
HYPRE.lib(vector.c.obj) : error LNK2001: unresolved external symbol
__imp__wassert
HYPRE.lib(par_csr_matop.c.obj) : error LNK2001: unresolved external symbol
__imp__wassert
HYPRE.lib(par_csr_communication.c.obj) : error LNK2001: unresolved external
symbol __imp__wassert
HYPRE.lib(csr_matop.c.obj) : error LNK2001: unresolved external symbol
__imp__wassert
HYPRE.lib(merge_sort.c.obj) : error LNK2001: unresolved external symbol
__imp__wassert
HYPRE.lib(memory.c.obj) : error LNK2001: unresolved external symbol
__imp__wassert
HYPRE.lib(IJMatrix_parcsr.c.obj) : error LNK2001: unresolved external
symbol __imp__wassert
HYPRE.lib(par_csr_matrix.c.obj) : error LNK2001: unresolved external symbol
__imp__wassert
HYPRE.lib(csr_matrix.c.obj) : error LNK2001: unresolved external symbol
__imp__wassert
HYPRE.lib(memory.c.obj) : error LNK2019: unresolved external symbol
__imp_realloc referenced in function hypre_ReAlloc
HYPRE.lib(par_vector.c.obj) : error LNK2001: unresolved external symbol
__imp_fopen
HYPRE.lib(vector.c.obj) : error LNK2001: unresolved external symbol
__imp_fopen
HYPRE.lib(IJMatrix.c.obj) : error LNK2001: unresolved external symbol
__imp_fopen
HYPRE.lib(par_csr_matrix.c.obj) : error LNK2001: unresolved external symbol
__imp_fopen
HYPRE.lib(csr_matrix.c.obj) : error LNK2001: unresolved external symbol
__imp_fopen
HYPRE.lib(new_commpkg.c.obj) : error LNK2001: unresolved external symbol
__imp_fopen
HYPRE.lib(printf.c.obj) : error LNK2019: unresolved external symbol
__imp___stdio_common_vfscanf referenced in function _vfscanf_l
HYPRE.lib(printf.c.obj) : error LNK2019: unresolved external symbol
__imp___stdio_common_vsscanf referenced in function _vsscanf_l
HYPRE.lib(mmio.c.obj) : error LNK2001: unresolved external symbol
__imp___stdio_common_vsscanf
HYPRE.lib(mmio.c.obj) : error LNK2019: unresolved external symbol
__imp_fgets referenced in function hypre_mm_read_banner
HYPRE.lib(mmio.c.obj) : error LNK2019: unresolved external symbol
__imp_tolower referenced in function hypre_mm_read_banner
C:\cygwin64\tmp\PE0681~1\CONFIG~1.LIB\conftest.exe : fatal error LNK1120: 7
unresolved externals
icx: error: linker command failed with exit code 1120 (use -v to see
invocation)
Possible ERROR while running linker: exit code 96
[more warnings etc]


-

I've looked at the oneapi compiler documentation, and it seems like
"nodefaultlib", "nostdlib", etc, options only work for linux versions of
the compiler,
so I'm not sure what to do about the first warning. From the errors, it
looks like some core c or c++ library that hypre depends on isn't visible.
I had some similar
issues with ptscotch - but in that case I didn't have the warnings, and the
errors gave me the names of libraries that were missing, which I lilnked in
using the --cflags
option (maybe --cc-linker-flags would have been neater, but it worked. I've
tried both in order to try to get the above working).


I can go into detail about the compile and linker commands if needed; I'd
have to explain more about my choices for --cflags, etc too. I wonder if
any of the above output
shines any light on the hypre-is-shared-library hypothesis.


Thanks,

Daniel

On Wed, Jul 19, 2023 at 4:58 PM Satish Balay via petsc-users <
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

Re: [petsc-users] Confusion/failures about the tests involved in including Hypre

2023-07-20 Thread Daniel Stone 
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

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> 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: T MPI_Init
> msmpi.lib:msmpi.dll: T MPI_Init_thread
> msmpi.lib:msmpi.dll: 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: I
> __imp_MatCreateSeqAIJWithArrays
> libpetsc.lib:libpetsc.dll: 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  wrote:
> > >
> > > BTW: Some explanation of configure:
> > >
> > > It attempts the