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 <balay@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.stone@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
> >>>
> >>>
> >>
> >
>