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