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