The Superbuild on cray uses the backend flavor of the GCC compiler (xk7_gcc target). I haven't made an xk7_pgi target yet.
David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Fri, Sep 6, 2013 at 4:07 PM, Andy Bauer <[email protected]> wrote: > Hi Hong, > > This Fortran/C mangling issue is a bit tricky. It has to be done during > the configuration process because the C and Fortran compilers won't > necessarily know how to properly mangle the function names. The thing is > that it the configuration process depends on using the same compilers as > any other code that links to the generated libraries. You can check out > Bill Hoffman's blog at http://www.kitware.com/blog/home/post/231 which > explains this issue and how CMake handles it. Now if ParaView Catalyst was > built with GCC and you built your simulation code with PGI, for example, > then it wouldn't surprise me that this issue crops up. What compilers did > you use for your ParaView build and your simulation code build? If they are > consistent then it is a problem with CMake or ParaView's superbuild. > > Regards, > Andy > > > On Fri, Sep 6, 2013 at 3:54 PM, Hong Yi <[email protected]> wrote: > >> Hi Andy,**** >> >> ** ** >> >> Thanks for the useful info. You are exactly right – the problem is caused >> by C/Fortran mangling of the names. In the Fortran code, underbar trailing >> is not there for all catalyst-related function calls, those underbar >> trailing to the function names as shown in the linking errors are >> automatically added by C/Fortran mangling in the final linking stage. I >> also pulled in the Fortran example in the github repo, and got the similar >> undefined reference errors in the final linking stage when linking to the >> ParaView 4.0 built with superbuild. So the linking problem seems to be >> generic to Fortran code linking to Catalyst. **** >> >> ** ** >> >> I checked the Catalyst static lib built with superbuild and found the lib >> only includes function symbols without the trailing underbar such as >> coprocessorinitialize, which explains why those undefined reference errors >> result. I also tried to build ParaView 3.98 with superbuild which included >> FortranAdaptor lib, and found the FortranAdatpor lib built with superbuild >> does not include the trailing underbar for coprocessor-related functions, >> while the FortranAdaptor lib built from source does include the trailing >> underbar, which explains why I can link our simulation code to Catalyst >> 3.98 built from source, but cannot successfully link to Catalyst 3.98 built >> with superbuild. So here is my question:**** >> >> ** ** >> >> Should Catalyst libs built with superbuild contain those coprocessing >> function symbols with trailing underbar in addition to those corresponding >> function symbols without trailing underbar? Specifically, for example, I am >> wondering whether both coprocessorinitialize and coprocessorinitialize_ >> need to present so these coprocessing functions can be called from >> different languages including Fortran? Could you confirm whether this is >> the case? If so, I need to check my superbuild to see why those trailing >> underbar functions are not created in the Catalyst libs. Let me know if >> you, David, or anybody else can confirm whether this is the case, or offer >> any ideas/suggestions.**** >> >> ** ** >> >> Thanks,**** >> >> ** ** >> >> Hong**** >> >> ** ** >> >> ** ** >> >> *From:* Andy Bauer [mailto:[email protected]] >> *Sent:* Friday, September 06, 2013 12:33 PM >> *To:* Hong Yi >> *Cc:* [email protected] >> *Subject:* Re: [Paraview] Errors when linking catalyst in ParaView >> version 4.0.1 to simulation code on Titan**** >> >> ** ** >> >> Hi Hong,**** >> >> ** ** >> >> I think it's the Fortran mangling of the names. Try taking out the >> underscore on the Fortran subroutine calls. Let me know if that doesn't >> help. Otherwise it may be an issue with how C/Fortran mangles things. The >> GCC behavior should be the following:**** >> >> Fortran -> call xyz()**** >> >> C -> void xyz_() {...}.**** >> >> All of these methods should be available in the vtkPVCatalyst module. If >> you can't get it to work, try to see what you can do with the Fortran >> example in the github repo.**** >> >> ** ** >> >> Regards, >> And**** >> >> ** ** >> >> On Thu, Sep 5, 2013 at 5:52 PM, Hong Yi <[email protected]> wrote:**** >> >> When linking our simulation code (a variant of phasta) to Catalyst in >> ParaView version 4.0.1 built on Titan with superbuild, I got the following >> linking errors: >> >> ----------------- >> ../../lib/libincompressible.a(itrdrv.f.o): In function `itrdrv_': >> itrdrv.f:(.text+0x2add): undefined reference to `coprocessorinitialize_' >> itrdrv.f:(.text+0x6198): undefined reference to `coprocessorfinalize_' >> itrdrv.f:(.text+0x973d): undefined reference to `coprocessorfinalize_' >> ../../lib/libincompressible.a(phastaadaptor.f.o): In function >> `phastacoprocessor_': >> phastaadaptor.f:(.text+0x84): undefined reference to >> `requestdatadescription_' >> phastaadaptor.f:(.text+0x95): undefined reference to `needtocreategrid_' >> phastaadaptor.f:(.text+0xba): undefined reference to `coprocess_' >> /usr/bin/ld: link errors found, deleting executable >> `../../bin/phastaIC.exe' >> ----------------- >> >> I use CMake to link Catalyst to our simulation code. I was able to >> resolve those linking errors when linking to ParaView version 3.98.1 by >> adding "find_package(ParaView 3.98 REQUIRED COMPONENTS FortranAdaptor)" in >> addition to find_package for vtkCoProcessorImplementation and then link >> both to the final executable. However, for ParaView version 4.0.1, it seems >> FortranAdaptor does not exist any more which defines those functions such >> as coprocessorinitialize, etc. Here is the corresponding excerpt in my >> CMakeLists.txt related to linking Catalyst in ParaView version 4.0.1: >> ------------------- >> if(USE_CATALYST) >> find_package(ParaView 3.98 REQUIRED COMPONENTS vtkPVPythonCatalyst) >> find_library(PHASTA_ADAPTOR_LIB PhastaAdaptorLib) >> include("${PARAVIEW_USE_FILE}") >> set(Adaptor_SRCS phastaadaptor.f) >> add_library(Adaptor ${Adaptor_SRCS}) >> target_link_libraries(Adaptor ${PHASTA_ADAPTOR_LIB} >> vtkPVPythonCatalyst) >> add_definitions("-DUSE_CATALYST") >> endif() >> ------------------- >> >> Adaptor is then linked to the final executable. >> >> Please let me know if you have ideas on what I should do to resolve those >> linking errors. >> >> Many thanks, >> >> Hong >> >> >> **** >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the ParaView Wiki at: >> http://paraview.org/Wiki/ParaView >> >> Follow this link to subscribe/unsubscribe: >> http://www.paraview.org/mailman/listinfo/paraview**** >> >> ** ** >> > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the ParaView Wiki at: > http://paraview.org/Wiki/ParaView > > Follow this link to subscribe/unsubscribe: > http://www.paraview.org/mailman/listinfo/paraview > >
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
