nasa / trick

Trick Simulation Environment. Trick provides a common set of simulation capabilities and utilities to build simulations automatically.
Other
34 stars 19 forks source link

Error `redefinition of ‘Trick::IPPythonEvent* castAsTrick__IPPythonEvent(PyObject*)` when compiling application #1569

Closed dsfenn closed 11 months ago

dsfenn commented 1 year ago

Hello,

I'm receiving the following error when trying to compile the cannonball sim:

SWIGing    build/vast_swbuild/swbuild3/hsp/TRICK/trick-19.6-09012023/include/trick/IPPythonEvent_py.i
Compiling  build/vast_swbuild/swbuild3/hsp/TRICK/trick-19.6-09012023/include/trick/IPPythonEvent_py.cpp
build/vast_swbuild/swbuild3/hsp/TRICK/trick-19.6-09012023/include/trick/IPPythonEvent_py.cpp:4195:24: error: redefinition of ‘Trick::IPPythonEvent* castAsTrick__IPPythonEvent(PyObject*)’
 Trick::IPPythonEvent * castAsTrick__IPPythonEvent( PyObject * obj1 ) {
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~
build/vast_swbuild/swbuild3/hsp/TRICK/trick-19.6-09012023/include/trick/IPPythonEvent_py.cpp:4114:24: note: ‘Trick::IPPythonEvent* castAsTrick__IPPythonEvent(PyObject*)’ previously defined here
 Trick::IPPythonEvent * castAsTrick__IPPythonEvent( PyObject * obj1 ) {

Looking at the file IPPythonEvent_py.cpp, I can see that castAsTrick__IPPythonEvent() is indeed defined twice.

My build environment is a bit unusual here. I'm trying to do this on the NASA High-Performance Computing systems (https://hec.nasa.gov/). One of their admins built Trick for me on the system, using Trick 19.6.

I appreciate any help you can give me.

dsfenn commented 1 year ago

Update: I've noticed the following errors near the beginning of the build

build/Makefile_swig:181: target 'build/vast_swbuild/swbuild3/hsp/TRICK/trick-19.6-09012023/include/trick/exec_proto_py.cpp' given more than once in the same rule
build/Makefile_swig:185: target 'build/vast_swbuild/swbuild3/hsp/TRICK/trick-19.6-09012023/include/trick/exec_proto_py.d' given more than once in the same rule
build/Makefile_swig:193: target 'build/vast_swbuild/swbuild3/hsp/TRICK/trick-19.6-09012023/include/trick/exec_proto_py.o' given more than once in the same rule

Could this be related?

I don't know anything about swig, and I'm not even sure how to begin trying to troubleshoot this. If anyone can give me any ideas about how to go about debugging this issue, I'd appreciate it.

Makefile_swig.txt

alexlin0 commented 1 year ago

Could you attach the Makefile_swig file here?

dsfenn commented 1 year ago

Could you attach the Makefile_swig file here?

Sure--I've added it to the above comment where I put the swig errors. Thanks

dsfenn commented 1 year ago

Update: I've tried using Trick 19.5, 19.6, and the latest master. All give the same error

jmpenn commented 1 year ago

Hmm, there's not a lot to go on from your description.

You said "One of their admins built Trick for me on the system".

How confident are you that he carefully read the installation instructions at https://nasa.github.io/trick/documentation/install_guide/Install-Guide ? The install instructions have been very reliable if carefully followed. Every install issue I've ever seen has been the result of not carefully reading the instructions.

Can you see / inspect the files in the Trick distribution that you have?

Do you have another Linux or MacOS computer that you can install Trick on for comparison?

Also, you said "My build environment is a bit unusual here." In what way?

jmpenn commented 1 year ago

You also said you you were trying to build the cannonball sim. From the tutorial? Or one of the versions of the cannon ball sim in trick.git/trick_sims/Cannon/ , like SIM_cannon_numeric?

alexlin0 commented 1 year ago

Sorry, I asked for the wrong file, can you attach IPPythonEvent_py.cpp?

dsfenn commented 1 year ago

@jmpenn -- The admin who built Trick for me wrote up a detailed installation readme, and, from what I can tell, followed all the instructions. I don't think they use package managers on those systems, so many of the dependencies were manually installed. Those computing systems seem to have pretty tightly-controlled environments, and oftentimes, not a lot of libraries are available. They use module systems to modify the system path to allow you to load and unload different libraries or tools, and prevent dependency conflicts. In case it's helpful, I'll include that readme here: README.txt

I tried building Trick myself a few times on that same system, using the libraries that the admin had installed for me. In all cases, I was able to build Trick, but unable to build the cannonball sim from the tutorial. I've also tried building trick_sims/Cannon/SIM_cannon_analytic and trick_sims/Cannon/SIM_cannon_numeric, all with the same result.

I regularly use Trick on my local Linux workstation, and I've never run into this issue. I recently built both cannon_analytic and cannon_numeric locally, with no issue. In answer to your question, I am able to see the files in my Trick distribution.

@alexlin0 -- No worries. I'm attaching IPPythonEvent_py.cpp as well as IPPythonEvent_py.i. Looking toward the end of IPPythonEvent_py.i, I see the following code:

...
#ifdef SWIG

%trick_cast_as(Trick::IPPythonEvent, Trick__IPPythonEvent)
#endif

#endif

#ifdef TRICK_SWIG_DEFINED_Trick__condition_t
%trick_cast_as(Trick::condition_t, Trick__condition_t)
#endif
#ifdef TRICK_SWIG_DEFINED_Trick__action_t
%trick_cast_as(Trick::action_t, Trick__action_t)
#endif
#ifdef TRICK_SWIG_DEFINED_Trick__IPPythonEvent
%trick_cast_as(Trick::IPPythonEvent, Trick__IPPythonEvent)
#endif

I notice that the line %trick_cast_as(Trick::IPPythonEvent, Trick__IPPythonEvent) appears twice, so perhaps this is getting called twice because both #define statements are true? Just a guess.

IPPythonEvent_py_cpp.txt IPPythonEvent_py_i.txt

alexlin0 commented 1 year ago

OK. When I went to compare your IPPythonEvent_py.cpp to mine I realized that that file should not exist. Then I went back to your Makefile_swig and realized that all of the files in "build/vast_swbuild/swbuild3/hsp/TRICK..." should not be listed in this makefile. All of these files should have been processed and compiled when Trick was built and should not be part of your sim makefile.

It is very likely that you have something unusual in your environment or directory setup. Can you first run "trick-gte" and paste the output here? And then can you also see if any directory in your path /vast_swbuild/swbuild3/hsp/TRICK/trick-19.6-09012023 is a symbolic link?

dsfenn commented 1 year ago

Ah, ok. That explains why I couldn't find that file when I looked for it in the build directory for a sim on my local machine. I was hoping to do a comparison, but it wasn't there.

Here's the output of trick-gte:

TRICK_CC=cc
TRICK_CFLAGS=-g -Wall -Wmissing-prototypes -Wextra -Wshadow
TRICK_CONVERT_SWIG_FLAGS=
TRICK_CPFLAGS=
TRICK_CXX=c++
TRICK_CXXFLAGS=-g -Wall -Wextra -Wshadow
TRICK_DEBUG=0
TRICK_EDITOR=
TRICK_EXEC_LINK_LIBS=
TRICK_EXT_LIB_DIRS=
TRICK_FORCE_32BIT=OFF
TRICK_GTE_EXT=
TRICK_HOME=/swbuild/hsp/TRICK/trick-19.6-09012023
TRICK_HOST_CPU=Linux_8.5_x86_64
TRICK_HOST_CPU_USER_SUFFIX=
TRICK_HOST_TYPE=Linux
TRICK_ICGFLAGS=
TRICK_ICG_COMPAT15=
TRICK_ICG_EXCLUDE=
TRICK_ICG_IGNORE_TYPES=
TRICK_ICG_NOCOMMENT=
TRICK_LDFLAGS=
TRICK_MAKE=
TRICK_PATH=/vast_swbuild/swbuild3/hsp/TRICK/trick-19.6-09012023/bin
TRICK_PRINTER_NAME=
TRICK_PRINT_CMD=lpr
TRICK_PYTHON_PATH=
TRICK_SFLAGS=
TRICK_SWIG_EXCLUDE=
TRICK_SYSTEM_CFLAGS=
TRICK_SYSTEM_CXXFLAGS=
TRICK_SYSTEM_LDFLAGS=
TRICK_USER_CSHRC=/home4/dsfenn/.Trick_user_cshrc
TRICK_USER_HOME=/home4/dsfenn/trick_sims
TRICK_USER_LINK_LIBS=
TRICK_USER_PROFILE=/home4/dsfenn/.Trick_user_profile
TRICK_VER=trick_dev
XML_CATALOG_FILES=/vast_swbuild/swbuild3/hsp/TRICK/trick-19.6-09012023/trick_source/data_products/DPX/XML/catalog.xml

Deprecated
TRICK_CPPC=c++

Also, it looks like none of the directories in that path are symbolic links:

dsfenn@pfe24:~> ll /vast_swbuild/swbuild3/hsp/TRICK/trick-19.6-09012023
total 0
drwxr-xr-x 2 hsp cstaff 4096 Sep  1 14:53 bin
drwxr-xr-x 2 hsp cstaff 4096 Sep  1 14:53 include
drwxr-xr-x 2 hsp cstaff 4096 Sep  1 14:53 lib64
drwxr-xr-x 2 hsp cstaff 4096 Sep  1 14:53 libexec
drwxr-xr-x 2 hsp cstaff 4096 Sep  1 14:53 share
alexlin0 commented 1 year ago

I see that TRICK_HOME and TRICK_PATH probably point to the same area, but get there with different paths. Is /swbuild a symbolic link pointing to /vast_swbuild/swbuild3?

Try changing TRICK_HOME in your environment to /vast_swbuild/swbuild3/hsp/TRICK/trick-19.6-0912023. Then "make spotless" in your sim directory and run "trick-CP" again.

dsfenn commented 1 year ago

Ah, that's it! I'm new on this system, and I'm not very familiar with how it's set up.

dsfenn@pfe27:~/test/SIM_cannon_analytic> ll -d /swbuild/hsp
lrwxrwxrwx 1 root root 26 Jul 27 10:31 /swbuild/hsp -> /vast_swbuild/swbuild3/hsp

Setting TRICK_HOME without using the symbolic link resolves the issue, as far as I can tell. I'm running into other build issues now, but I'm not sure if they're related or not. I'll spend some more time looking into them.

Thank you for your help!

alexlin0 commented 1 year ago

Happy to help. I'm curious, are you trying to run Trick on a supercomputer?

dsfenn commented 1 year ago

Happy to help. I'm curious, are you trying to run Trick on a supercomputer?

Yes, that's the goal. We're doing a bunch of runs over increasingly large parameter spaces, and being able to run on a supercomputer should help keep this manageable as the dimensionality of our parameter space grows.

I'm still running into issues that I can't figure out. It looks to me like it's still trying to build stuff that should have already been built:

SWIGing    build/vast_swbuild/swbuild3/hsp/TRICK/udunits-2.2.28/include/converter_py.i
Compiling  build/vast_swbuild/swbuild3/hsp/TRICK/udunits-2.2.28/include/converter_py.cpp
SWIGing    build/vast_swbuild/swbuild3/hsp/TRICK/udunits-2.2.28/include/udunits2_py.i
Compiling  build/vast_swbuild/swbuild3/hsp/TRICK/udunits-2.2.28/include/udunits2_py.cpp
build/vast_swbuild/swbuild3/hsp/TRICK/udunits-2.2.28/include/udunits2_py.cpp: In function ‘PyObject* _wrap_ut_write_to_stderr(PyObject*, PyObject*)’:
build/vast_swbuild/swbuild3/hsp/TRICK/udunits-2.2.28/include/udunits2_py.cpp:7422:15: error: invalid array assignment
       arg2 = *temp;
               ^~~~
build/vast_swbuild/swbuild3/hsp/TRICK/udunits-2.2.28/include/udunits2_py.cpp: In function ‘PyObject* _wrap_ut_ignore(PyObject*, PyObject*)’:
build/vast_swbuild/swbuild3/hsp/TRICK/udunits-2.2.28/include/udunits2_py.cpp:7478:15: error: invalid array assignment
       arg2 = *temp;
               ^~~~

When I look in the build directory on my local machine for the cannonball sim, I don't see the file udunits2_py.cpp. TRICK_HOME, along with the directories for the Trick dependencies, including udunits, have all been modified now so that they don't use symlinks. If I look at the udunits installation location, I can see the libraries there:

dsfenn@pfe21:/swbuild/hsp/TRICK/udunits-2.2.28/lib> ls
libudunits2.a  libudunits2.la  libudunits2.so  libudunits2.so.0  libudunits2.so.0.1.0

My PATH and LD_LIBRARY_PATH both refer to the correct udunits installation location as well, with no symlinks. I'm not sure what other variables may be important here.

alexlin0 commented 1 year ago

The udunits header files are not a standard place so Trick is treating them like normal model header files. The udunits header files don't need to be processed. We can tell Trick to ignore this directory. Add these 2 lines to your environment

(assuming bash) export TRICK_ICG_EXCLUDE=/vast_swbuild/swbuild3/hsp/TRICK/udunits-2.2.28 export TRICK_SWIG_EXCLUDE=/vast_swbuild/swbuild3/hsp/TRICK/udunits-2.2.28

dsfenn commented 1 year ago

That did the trick! It's compiling all the way through now. Just running into some linking errors at the end. I'll see if I can get those figured out.

dsfenn commented 12 months ago

The cannonball sim is compiling, linking, and running correctly now. Thanks again for your help.

sharmeye commented 11 months ago

I'm glad I could wait long enough to address this for it be fixed by other people. My favorite kind of issue, the ones I can close by doing literally nothing.