[petsc-users] Confusion/failures about the tests involved in including Hypre
Satish Balay
balay at mcs.anl.gov
Thu Jul 20 10:13:23 CDT 2023
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 at 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 at 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 at 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 at 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 at pj01 petsc]$ cat conftest.c
> > > > char HYPRE_IJMatrixCreate();
> > > > static void _check_HYPRE_IJMatrixCreate() { HYPRE_IJMatrixCreate(); }
> > > >
> > > > int main(void) {
> > > > _check_HYPRE_IJMatrixCreate();
> > > > return 0;
> > > > }
> > > > [balay at pj01 petsc]$ gcc -c conftest.c
> > > > [balay at pj01 petsc]$ nm -Ao conftest.o |grep HYPRE_IJMatrixCreate
> > > > conftest.o:0000000000000000 t _check_HYPRE_IJMatrixCreate
> > > > conftest.o: U HYPRE_IJMatrixCreate
> > > > [balay at 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 at 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 at pj01 petsc]$ gcc -o conftest conftest.o
> > arch-linux-c-debug/lib/libHYPRE.so
> > > > [balay at 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 at 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
> > > >>>
> > > >>>
> > > >>
> > > >
> > >
> >
> >
>
More information about the petsc-users
mailing list