[Paraview-developers] Linker error building Fortran90FullExample
Andy Bauer
andy.bauer at kitware.com
Tue Nov 29 12:43:24 EST 2016
Hi Thomas,
Would you want to add a MR for your changes on gitlab?
Yes, Fortran and C/C++ loop through memory in multidimensional arrays
differently but in the end it's a flat memory layout so it can be managed.
I'm not sure what the error you're seeing is from. If you add a bug report
for that on gitlab I may be able to get to that as well.
Thanks,
Andy
On Sat, Nov 19, 2016 at 10:09 AM, <thomasblome at startmail.com> wrote:
> Hi Andy,
>
> I ran ctest from the windows cmd, but couldn't make sense of the output.
> Anyhow, I guess the segmentation fault was due to a wrong declaration of
> the rank 3 Fortran array of type complex in the procedure interface I
> provided for the C++ function addfield(). I changed it to be type(c_ptr) as
> the function expects a double pointer. Afterwards the test ran
> successfully.
>
> Nevertheless, it remains a mystery to me how the reference to the rank 3
> array is properly handled in addfield(), as Fortran and C++ use different
> memory layouts for multidimensional arrays; I guess it's still not correct,
> even though there is no segmentation fault shown.
>
> I set the input of EnableLiveVisualization() in coproc.py to True and
> tried to visualize the simulation, but its duration is too short - the test
> finishes already after a few seconds. Only once I could sneak a peak to the
> cube in Paraview, but I got following error message (in Paraview) right
> before the simulation stopped:
>
> ERROR: In C:\Kitware\ParaView-v5.1.2\VTK\Parallel\Core\vtkSocketCommunicator.cxx,
> line 809
> vtkSocketCommunicator (000001E68C21B360): Could not receive tag. 1
>
> Best,
> Thomas
>
>
>
> Am Sonntag, 13. November 2016 14:40 schrieb Andy Bauer <
> andy.bauer at kitware.com>:
>
>
> Hi Thomas,
>
> Can you run ctest -V to get verbose output out of the run? That may shed
> some light on what the issue is. My guess is that it's not finding the
> coproc.py script. Also, the verbose output for ctest will show you how you
> can run the test manually which may be useful.
>
> Cheers,
> Andy
>
> On Fri, Nov 11, 2016 at 2:50 PM, <thomasblome at startmail.com> wrote:
>
> To resolve the references inclusion of header files "CPythonAdaptorAPI.h"
> and "CAdaptorAPI.h" in FECxxAdaptor.cxx was required, as they declare the
> missing functions.
> Afterwards, I provided the corresponding procedure interfaces in the
> Fortran files and finally got through the static linking stage.
>
> Now, when I start the RUN_TESTS project, the Fortran90FullExampleTest
> fails due to a segmentation fault:
>
> 1/1 Test #1: Fortran90FullExampleTest .........***Exception: SegFault
> 8.48 sec
> 1>
> 1> 0% tests passed, 1 tests failed out of 1
> 1>
> 1> Label Time Summary:
> 1> CATALYST = 8.48 sec (1 test)
> 1> PARAVIEW = 8.48 sec (1 test)
> 1>
> 1> Total Test time (real) = 8.48 sec
> 1>
> 1> The following tests FAILED:
> 1> 1 - Fortran90FullExampleTest (SEGFAULT)
> 1> Errors while running CTest
> 1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\
> v4.0\V140\Microsoft.CppCommon.targets(133,5): error MSB3073: The command
> "setlocal
> 1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\
> v4.0\V140\Microsoft.CppCommon.targets(133,5): error MSB3073:
> C:\cmake\bin\ctest.exe --force-new-ctest-process -C Debug
> 1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\
> v4.0\V140\Microsoft.CppCommon.targets(133,5): error MSB3073: if
> %errorlevel% neq 0 goto :cmEnd
> 1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\
> v4.0\V140\Microsoft.CppCommon.targets(133,5): error MSB3073: :cmEnd
> 1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\
> v4.0\V140\Microsoft.CppCommon.targets(133,5): error MSB3073: endlocal &
> call :cmErrorLevel %errorlevel% & goto :cmDone
> 1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\
> v4.0\V140\Microsoft.CppCommon.targets(133,5): error MSB3073:
> :cmErrorLevel
> 1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\
> v4.0\V140\Microsoft.CppCommon.targets(133,5): error MSB3073: exit /b %1
> 1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\
> v4.0\V140\Microsoft.CppCommon.targets(133,5): error MSB3073: :cmDone
> 1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\
> v4.0\V140\Microsoft.CppCommon.targets(133,5): error MSB3073: if
> %errorlevel% neq 0 goto :VCEnd
> 1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\
> v4.0\V140\Microsoft.CppCommon.targets(133,5): error MSB3073: :VCEnd"
> exited with code 8.
>
> Does anybody know how to solve this?
>
> Best,
> Thomas
>
> Am Donnerstag, 10. November 2016 19:10 schrieb thomasblome at startmail.com:
>
>
> Hi Andy,
>
> The linker error concerning the missing main method was due to a wrong
> solution setup of the Fortran90FullExample in VS.
> The CMakeLists file provided generates only one single (C++) project in
> VS, which means all .f90 files will be ignored by the compiler (it's
> impossible to have a single Fortran/C++ mixed language project in VS).
> To solve this I had to configure the CMakeLists file to create a library
> from FECxxAdaptor.cxx and link it with the Fortran90FullExample.
>
> Other linker & compiler errors occurred with regards to mpi:
> 1) the target_link_libraries command in the CMakeLists file links
> ${MPI_Fortran_LIBRARIES} to the fortran project,
> but it forgets to link with msmpifec.lib (see also:
> http://public.kitware.com/pipermail/cmake/2016-February/062861.html).
> 2) The specification of an include directory (containing header mpifptr.h)
> was missing.
>
> Another problem arose when it comes to the the by hand name mangling for
> fortran in FECxxAdaptor.cxx.
> To get rid of that I introduced function interfaces in the
> FEFortranAdaptor.f90 file and now it works independently of the Fortran
> compiler used.
>
> Now, there are only five remaining linker errors as shown below:
>
> LNK2019: unresolved external symbol COPROCESS referenced in function
> TCP_mp_TESTCOPROCESSOR FEFortranAdaptor.obj
> LNK2019: unresolved external symbol COPROCESSORINITIALIZEWITHPYTHON
> referenced in function MAIN__ FEDriver.obj
> LNK2019: unresolved external symbol COPROCESSORFINALIZE referenced in
> function MAIN__ FEDriver.obj
> LNK2019: unresolved external symbol NEEDTOCREATEGRID referenced in
> function TCP_mp_TESTCOPROCESSOR FEFortranAdaptor.obj
> LNK2019: unresolved external symbol REQUESTDATADESCRIPTION referenced in
> function TCP_mp_TESTCOPROCESSOR FEFortranAdaptor.obj
>
> In the ParaViewCatalystUsersGuide_v2 the missing symbols appear to be
> declared in CAdaptorAPI.h and CPythonAdaptorAPI.h (but NEEDTOCREATEGRID),
> but I can't just include them in the Fortran code.
>
> Can you tell me how to resolve those missing references?
>
> Best,
> Thomas
>
>
> Am Mittwoch, 26. Oktober 2016 18:47 schrieb Andy Bauer <
> andy.bauer at kitware.com>:
>
>
> Hi Thomas,
>
> I really don't know about this. Do you get the same behavior if you don't
> link with Catalyst? Can you create a simple helloworld.f90 example that
> works?
>
> Best,
> Andy
>
> On Wed, Oct 26, 2016 at 3:39 AM, <thomasblome at startmail.com> wrote:
>
> Hi Andy,
>
> I have changed both lines from coproc to main, but the error message
> remains the same.
>
> Best,
> Thomas
>
> Am Montag, 24. Oktober 2016 22:00 schrieb Andy Bauer <
> andy.bauer at kitware.com>:
>
>
> Hi Thomas,
>
> If you change from coproc to main in the "program" and "end program" lines
> in FEDriver.f90 does that fix the problem?
>
> I'm working on a fix for this but don't have access to any MSVS compilers.
>
> Thanks,
> Andy
>
> On Sat, Oct 22, 2016 at 1:46 PM, <thomasblome at startmail.com> wrote:
>
> Hello,
>
> I'm trying to compile the Fortran90FullExample using MSVS (Intel Fortran
> Compiler 2017 and Visual C++ 2015 compiler).
> Doing so I'm getting following linker error:
>
> Error LNK2019 unresolved external symbol main referenced in function
> "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
> Fortran90FullExample.
>
> Obviously, the source code doesn't contain a main method at all, since the
> entry point is given by the fortran program in file 'FEDriver.f90'.
> Nevertheless, I guess the compiler internally creates a main method, and
> the linker cannot resolve the reference due to a name mangling problem, as
> there are different compilers involved. But I'm not quite sure about that,
> nor how to solve it, at that matter.
>
> Can you give me a hint how to solve that problem?
>
> Kind regards,
> Thomas
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=
> Paraview-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/paraview-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20161129/e47306d2/attachment-0001.html>
More information about the Paraview-developers
mailing list