ADIOS2: ADIOS2 2.8.3 undefined reference

Describe the bug When I try to compile on HPC system, I get error message like this:

/beegfs/apps/openfoam-v2306/OpenFOAM-v2306/ThirdParty/build/linux64Gcc/ADIOS2-2.8.3/lib64/libadios2_ffs.so.1: undefined reference to 'setup_for_string_parse' /beegfs/apps/openfoam-v2306/OpenFOAM-v2306/ThirdParty/build/linux64Gcc/ADIOS2-2.8.3/lib64/libadios2_ffs.so.1: undefined reference to 'reset_types_table' /beegfs/apps/openfoam-v2306/OpenFOAM-v2306/ThirdParty/build/linux64Gcc/ADIOS2-2.8.3/lib64/libadios2_ffs.so.1: undefined reference to 'terminate_string_parse' collect2: error: ld returned 1 exit status make[2]: *** [bin/bpls] Error 1 make[1]: *** [source/utils/CMakeFiles/bpls.dir/all] Error 2 make: *** [all] Error 2 Error building: ADIOS2-2.8.3

To Reproduce A minimal reproducible example is preferred. Or Steps to reproduce the behavior:

Download OpenFOAM and ThirdParty from ‘Source: https://dl.openfoam.com/source/v2306/OpenFOAM-v2306.tgz ThirdParty: https://dl.openfoam.com/source/v2306/ThirdParty-v2306.tgz’
Follow build doc on ‘https://develop.openfoam.com/Development/openfoam/-/blob/master/doc/Build.md’
Try to makeAdios2 with command ‘./makeAdios2’
See error

Desktop (please complete the following information):

OS/Platform: [CentOS 7.9]
Build [compiler version gcc 9.5.0, cmake 3.20.2 ]

About this issue

Original URL
State: closed
Created a year ago
Comments: 26 (13 by maintainers)

Most upvoted comments

Huh. Odd that these are popping up with code that hasn’t changed quite a long time. @ax3l , I see this in your build

  [ 10%] Using pre-generated Flex Output from /project/ADIOS2-fix-blosc2-findpackage/thirdparty/ffs/ffs/cod/pregen_source/Linux
  cd /project/build-adios2/thirdparty/ffs/ffs && /opt/_internal/cpython-3.8.16/lib/python3.8/site-packages/cmake/data/bin/cmake -E copy /project/ADIOS2-fix-blosc2-findpackage/thirdparty/ffs/ffs/cod/pregen_source/Linux/lex.yy.c /project/build-adios2/thirdparty/ffs/ffs
  [ 11%] Using pre-generated Flex Output from /project/ADIOS2-fix-blosc2-findpackage/thirdparty/ffs/ffs/cod/pregen_source/Linux
  cd /project/build-adios2/thirdparty/ffs/ffs && /opt/_internal/cpython-3.8.16/lib/python3.8/site-packages/cmake/data/bin/cmake -E copy /project/ADIOS2-fix-blosc2-findpackage/thirdparty/ffs/ffs/cod/pregen_source/Linux/lex.yy.c /project/build-adios2/thirdparty/ffs/ffs
  Error copying file "/project/ADIOS2-fix-blosc2-findpackage/thirdparty/ffs/ffs/cod/pregen_source/Linux/lex.yy.c" to "/project/build-adios2/thirdparty/ffs/ffs".

Clearly not being able to copy the pre-generated lex.yy.c is the source of your later lex.yy.c not found error, but why isn’t cmake able to do that copy? This is all rather puzzling…

eisenhauer on Aug 9, 2023

Ah, yes, there were no build issues on any of our CI systems, so it just got merged to ADIOS master. If you can build with the master branch at https://github.com/ornladios/ADIOS2, we can see if it actually fixed anything or if the problem still exists.

eisenhauer on Aug 15, 2023

Well, nothing looks weird about the -I args. The other possibility that occurs to me is that perhaps something had gone wrong with the #ifdef structure that was meant to handle the differences between flex and the original lex. That structure is quite old, and the original lex is functionally extinct in the wild. so we really don’t need those complications. I’ll try to find time to take a look at this later today or tomorrow.

eisenhauer on Aug 10, 2023

Just confirming, you’re still building ADIOS in the Openfoam context when you try 2.9.1, yes? Not on its own, separate directory, using the native ADIOS build process and not the makeAdios2 script? I’ve built openfoam myself without seeing the issue (and of course ADIOS CI builds on a couple dozen platforms with every PR). My current theory is that somehow your build is pulling a different lex.yy.c. That filename is the default output name for lex/flex, so it may exist in other contexts. It is pulled into the adios build with #include, which means that it is found via a search path. A file with that name also appears in the openfoam Thirdparty tools (ThirdParty-v2306/sources/paraview/ParaView-v5.11.1/VTK/Wrapping/Tools/lex.yy.c). If something like this were happening, that other lex.yy.c would be defining most of the same symbols as ours because they are standard lex/flex output. What it wouldn’t be defining are our specific routines that are defined in lex.yy.c and referenced elsewhere, exactly those routines that show up as undefined in your build.

The “#include finding the wrong file theory” fits the behavior you’re seeing. The problem is I can’t test this theory because it’s not happening for us, it’s outside the control of ADIOS and specific to either your build environment (or maybe other third party things you’re building?). You might try looking for other files named lex.yy.c in your build and/or trying to sort the exact #include search path that is used when cod.tab.c is compiled in ADIOS. (You can do the latter by modifying makeAdios2 to add “VERBOSE=1” to the invocation of make that builds ADIOS, then look for the -I arguments to the compile command for cod.tab.c (the bison/yacc output file). That won’t include the system search paths, but it’s a start. If it’s not that there’s a different lex.yy.c that the compile is pulling in, then I don’t have a second theory.

eisenhauer on Aug 9, 2023