ADIOS2 2.8.3 undefined reference #3742

albenstein · 2023-08-07T13:22:38Z

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 ]

The text was updated successfully, but these errors were encountered:

eisenhauer · 2023-08-07T13:43:04Z

Thanks for the report. Given the info here, I think the clues lead to a problem in the build environment. All of the undefined symbols should be in lex.yy.c, the output of the lexical analyzer (used in FFS, a third-party sub-component of ADIOS). That file is in turn #included by cod.tab.c, the output of a parser generator. If I were guessing, I'd guess that something is broken with flex/lex on your build system. Given the error, you must have a cod.yy.c, but somehow it isn't seeing a lex.yy.c, or if it is seeing it it's empty. That may mean that lex/flex is seen but broken, or something else. You might look for lex.yy.c in your build directory, try to figure out if lex or flex is available, etc. (FFS does have a mechanism for using pre-generated versions of lex.yy.c and cod.yy.c in the event that Flex/Bison are not available, so it's also possible that something has gone wrong in that process, but it's going to take digging into the actual build details to find that out.)

albenstein · 2023-08-07T14:15:35Z

Thanks for response.
I recompiled flex 2.6.4 and it gave no error.
When I tried to compile ADIOS2 again, it gave same error.

[ 43%] Linking CXX executable ../../bin/adios2_reorganize
/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 '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 'terminate_string_parse'
collect2: error: ld returned 1 exit status
make[2]: *** [bin/adios2_reorganize] Error 1
make[1]: *** [source/utils/CMakeFiles/adios_reorganize.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 43%] Linking CXX shared library ../../lib64/libadios2_c.so
[ 43%] Built target adios2_c
[ 43%] Linking CXX shared library ../../lib64/libadios2_core_mpi.so
[ 43%] Built target adios2_core_mpi
[ 43%] Linking CXX shared library ../../lib64/libadios2_cxx11.so
[ 43%] Built target adios2_cxx11
[ 44%] Linking CXX executable ../../bin/bpls
/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

eisenhauer · 2023-08-07T14:36:51Z

I think I still have the same questions WRT whether or not the flex you built is found by the ADIOS build (CMake output will yield that answer) and if lex.yy.c is absent or present and empty in the build directory. This isn't likely to be a version-of-flex issue. Look for output like this in the build:

-- Looking for socket
-- Looking for socket - found
-- Found BISON: /usr/bin/bison (found version "2.3")
-- Found FLEX: /usr/bin/flex (found version "2.6.4")
-- Found dill: /Users/eisen/prog/ADIOS2/build/thirdparty/dill/dill/dill-config.cmake (found suitable version "3.0.0", minimum required is "3.0.0")
-- Found atl: /Users/eisen/prog/ADIOS2/build/thirdparty/atl/atl/atl-config.cmake (found suitable version "2.2.1", minimum required is "2.2.1")
-- Looking for netdb.h

and this in the build:
[ 3%] Building C object thirdparty/dill/dill/CMakeFiles/dill.dir/arm6_rt.c.o
[ 3%] Linking C shared library ../../../lib/libadios2_dill.dylib
[ 3%] Built target dill
[ 3%] [FLEX][CODScanner] Building scanner with flex 2.6.4
[ 3%] Generating cod_node.c
Done

thanks,
g

albenstein · 2023-08-07T14:41:32Z

It found flex and bison on system.

...
-- Found dill: /beegfs/apps/openfoam-v2306/OpenFOAM-v2306/ThirdParty/build/linux64Gcc/ADIOS2-2.8.3/thirdparty/dill/dill/dill-config.cmake (found version "2.4.1")

-- ADIOS2 ThirdParty: Configuring ffs
-- Check size of off_t
-- Check size of off_t - done
-- Check size of long double
-- Check size of long double - done
-- Check size of long long
-- Check size of long long - done
-- Check size of size_t
-- Check size of size_t - done
-- Looking for socket
-- Looking for socket - found
-- Found BISON: /usr/bin/bison (found version "3.0.4")
-- Found FLEX: /beegfs/apps/flex/2.6.4/bin/flex (found version "2.6.4")
-- Found atl: /beegfs/apps/openfoam-v2306/OpenFOAM-v2306/ThirdParty/build/linux64Gcc/ADIOS2-2.8.3/thirdparty/atl/atl/atl-config.cmake (found suitable version "2.2.1", minimum required is "2.2.1")
...

eisenhauer · 2023-08-07T14:44:10Z

If lex.yy.c is present in the build directory, can you please attach it here?

albenstein · 2023-08-07T14:51:04Z

lex.yy.c.txt

eisenhauer · 2023-08-07T16:01:21Z

Interesting. The file you attach certainly was not generated by Flex on your system as it has paths from my laptop embeded in it. (I'm the maintainer of FFS.)

#line 2 "/Users/eisen/prog/ffs/build/lex.yy.c"
#line 4 "/Users/eisen/prog/ffs/build/lex.yy.c"
#define  YY_INT_ALIGNED short int

It seems to be identical to the version in ADIOS2/thirdparty//ffs/ffs/cod/pregen_source/Linux/lex.yy.c. It could be that we're using the pre-generated version lex.yy.c (which we should NOT be doing if we found flex as your CMake output says we did), or it could be that you snagged the wrong version, out of the pre-gen directory instead of out of your build directory. (You are using a build directory separate from the source, yes?).

Some compilers don't warn when a #include file is missing, so if the only copy of lex.yy.c that you find is the one in pregen_source, it could be that flex was run, but something went wrong and the file didn't get generated. Would you please give the path where you found lex.yy.c?

If it is from the build directory, then I'm at more of a loss. This version of lex.yy.c obviously contains the reset_types_table() and other subroutines. We'd have to start guessing as to why they show up missing.

albenstein · 2023-08-08T07:18:39Z

I'm using different build and source location.
attached lex.yy.c path is: /beegfs/apps/openfoam-v2306/OpenFOAM-v2306/ThirdParty/sources/adios/ADIOS2-2.8.3/thirdparty/ffs/ffs/cod/pregen_source/Linux/lex.yy.c
On this path there is one lex.yy.c file too /beegfs/apps/openfoam-v2306/OpenFOAM-v2306/ThirdParty/build/linux64Gcc/ADIOS2-2.8.3/thirdparty/ffs/ffs/lex.yy.c
I'm attaching in build directory's lex.yy.c:
lex.yy.c.txt

albenstein · 2023-08-08T12:36:29Z

I've checked on OpenFoam-v2212 version, I got same error.

albenstein · 2023-08-08T12:40:26Z

I'm also attaching compiling process log:
compiling_Adios2.txt

albenstein · 2023-08-09T11:12:51Z

I've just compiled ADIOS2 version 2.9.1 and I got same error.

eisenhauer · 2023-08-09T11:34:09Z

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.

albenstein · 2023-08-09T12:09:18Z

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'm trying to build with Openfoam context and using Allwmake and makeAdios2 script, they have same result.

After you said on seperate directory, I tried that option also with following this page -> https://adios2.readthedocs.io/en/latest/setting_up/setting_up.html. This time I got googletest error like below:
/beegfs/apps/work/ADIOS2/thirdparty/GTest/googletest/googletest/include/gtest/gtest-matchers.h:431:3: error: body of constexpr function ‘static constexpr bool testing::internal::MatcherBase<T>::IsInlined() [with M = testing::internal::EqMatcher<std::basic_string<char> >; T = const std::basic_string<char>&]’ not a return-statement } ^

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.

I've searched system-wide lex.yy.c file and I found in other directories like vasp, vtk that compiled before on system and using with modules.

(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)

I've added VERBOSE=1 to makeAdios2 file but I could not see any -I argument on screen.

albenstein · 2023-08-09T12:11:37Z

I thought that cmake version is maybe a problem, and I compiled cmake 3.27.1 (latest) but no change on result.

I'm checking all possibilities :)

eisenhauer · 2023-08-09T16:32:09Z

The gtest error is unrelated and I see it popping up elsewhere, for example: google/googletest#3639 and google/benchmark#1103 which also seem to be on centos. Those reports all seem to be compiler version related, but whatever is going on there is outside the ADIOS purview.

If you add VERBOSE=1 to makeAdios2 like this:

        cd "$PKG_BUILD" && set -x && \
        ${cmake:?} \
            -DCMAKE_INSTALL_PREFIX="$PKG_PREFIX" \
            -DCMAKE_BUILD_TYPE=Release \
            -DADIOS2_USE_Fortran=FALSE \
            -DADIOS2_BUILD_EXAMPLES=FALSE \
            ${WM_QUIET:+-DCMAKE_RULE_MESSAGES=OFF} \
            "$PKG_SOURCE" \
        && make VERBOSE=1 -j $WM_NCOMPPROCS all \
        && make install \
        && echo "Built: $PACKAGE"

You should see a bunch of verbose output that tells you how things are compiled, etc. For example I see these lines relevant to cod.tab.c:

[  5%] Building C object thirdparty/ffs/ffs/CMakeFiles/ffs.dir/cod.tab.c.o
cd /Users/eisen/prog/openfoam/ThirdParty-v2306/build/darwin64Clang/ADIOS2-2.8.3/thirdparty/EVPath/EVPath && /opt/homebrew/bin/mpicc -DEVPATH_MODULE_BUILD_DIR=\"/Users/eisen/prog/openfoam/ThirdParty-v2306/build/darwin64Clang/ADIOS2-2.8.3/thirdparty/EVPath/EVPath/lib\" -DMPICH_SKIP_MPICXX -DOMPI_SKIP_MPICXX -Dcmzplenet_EXPORTS -I/Users/eisen/prog/openfoam/ThirdParty-v2306/sources/adios/ADIOS2-2.8.3/thirdparty/EVPath/EVPath -I/Users/eisen/prog/openfoam/ThirdParty-v2306/build/darwin64Clang/ADIOS2-2.8.3/thirdparty/EVPath/EVPath -I/Users/eisen/prog/openfoam/ThirdParty-v2306/sources/adios/ADIOS2-2.8.3/thirdparty/ffs/ffs -I/Users/eisen/prog/openfoam/ThirdParty-v2306/sources/adios/ADIOS2-2.8.3/thirdparty/ffs/ffs/fm -I/Users/eisen/prog/openfoam/ThirdParty-v2306/sources/adios/ADIOS2-2.8.3/thirdparty/ffs/ffs/cod -I/Users/eisen/prog/openfoam/ThirdParty-v2306/sources/adios/ADIOS2-2.8.3/thirdparty/ffs/ffs/ffs -I/Users/eisen/prog/openfoam/ThirdParty-v2306/build/darwin64Clang/ADIOS2-2.8.3/thirdparty/ffs/ffs -I/Users/eisen/procd /Users/eisen/prog/openfoam/ThirdParty-v2306/sources/adios/ADIOS2-2.8.3/thirdparty/ffs/ffs && /usr/bin/bison -d -d -o /Users/eisen/prog/openfoam/ThirdParty-v2306/build/darwin64Clang/ADIOS2-2.8.3/thirdparty/ffs/ffs/cod.tab.c cod/cod.y
[ 11%] Building C object thirdparty/ffs/ffs/CMakeFiles/ffs.dir/cod.tab.c.o
cd /Users/eisen/prog/openfoam/ThirdParty-v2306/build/darwin64Clang/ADIOS2-2.8.3/thirdparty/ffs/ffs && /opt/homebrew/bin/mpicc -DMPICH_SKIP_MPICXX -DOMPI_SKIP_MPICXX -Dffs_EXPORTS -I/Users/eisen/prog/openfoam/ThirdParty-v2306/sources/adios/ADIOS2-2.8.3/thirdparty/ffs/ffs -I/Users/eisen/prog/openfoam/ThirdParty-v2306/sources/adios/ADIOS2-2.8.3/thirdparty/ffs/ffs/fm -I/Users/eisen/prog/openfoam/ThirdParty-v2306/sources/adios/ADIOS2-2.8.3/thirdparty/ffs/ffs/cod -I/Users/eisen/prog/openfoam/ThirdParty-v2306/sources/adios/ADIOS2-2.8.3/thirdparty/ffs/ffs/ffs -I/Users/eisen/prog/openfoam/ThirdParty-v2306/build/darwin64Clang/ADIOS2-2.8.3/thirdparty/ffs/ffs -I/Users/eisen/prog/openfoam/ThirdParty-v2306/build/darwin64Clang/ADIOS2-2.8.3/thirdparty/ffs/ffs/ffs -I/Users/eisen/prog/openfoam/ThirdParty-v2306/sources/adios/ADIOS2-2.8.3/thirdparty/dill/dill -I/Users/eisen/prog/openfoam/ThirdParty-v2306/build/darwin64Clang/ADIOS2-2.8.3/thirdparty/dill/dill -I/Users/eisen/prog/openfoam/ThirdParty-v2306/sources/adios/ADIOS2-2.8.3/thirdparty/atl/atl -I/Users/eisen/prog/openfoam/ThirdParty-v2306/build/darwin64Clang/ADIOS2-2.8.3/thirdparty/atl/atl -m64 -ftrapping-math -fPIC -w -O3 -DNDEBUG -std=gnu99 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -fPIC -MD -MT thirdparty/ffs/ffs/CMakeFiles/ffs.dir/cod.tab.c.o -MF CMakeFiles/ffs.dir/cod.tab.c.o.d -o CMakeFiles/ffs.dir/cod.tab.c.o -c /Users/eisen/prog/openfoam/ThirdParty-v2306/build/darwin64Clang/ADIOS2-2.8.3/thirdparty/ffs/ffs/cod.tab.c
/opt/homebrew/bin/mpicc -m64 -ftrapping-math -fPIC -w -O3 -DNDEBUG -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -dynamiclib -Wl,-headerpad_max_install_names -compatibility_version 1.0.0 -current_version 1.6.0 -o ../../../lib/libadios2_ffs.1.6.0.dylib -install_name @rpath/libadios2_ffs.1.dylib CMakeFiles/ffs.dir/ffs/ffs.c.o CMakeFiles/ffs.dir/ffs/ffs_formats.c.o CMakeFiles/ffs.dir/ffs/ffs_conv.c.o CMakeFiles/ffs.dir/ffs/ffs_gen.c.o CMakeFiles/ffs.dir/ffs/ffs_file.c.o CMakeFiles/ffs.dir/ffs/unix_io.c.o CMakeFiles/ffs.dir/ffs/evol.c.o CMakeFiles/ffs.dir/ffs/ffs_marshal.c.o CMakeFiles/ffs.dir/version.c.o CMakeFiles/ffs.dir/fm/fm_formats.c.o CMakeFiles/ffs.dir/fm/fm_dump.c.o CMakeFiles/ffs.dir/fm/lookup3.c.o CMakeFiles/ffs.dir/fm/string_conversion.c.o CMakeFiles/ffs.dir/fm/fm_get.c.o CMakeFiles/ffs.dir/fm/xml.c.o CMakeFiles/ffs.dir/fm/server_acts.c.o CMakeFiles/ffs.dir/fm/unix_io.c.o CMakeFiles/ffs.dir/cod/cg.c.o CMakeFiles/ffs.dir/cod/standard.c.o CMakeFiles/ffs.dir/cod.tab.c.o CMakeFiles/ffs.dir/cod_node.c.o  -Wl,-rpath,/Users/eisen/prog/openfoam/ThirdParty-v2306/build/darwin64Clang/ADIOS2-2.8.3/lib -lm ../../../lib/libadios2_dill.2.4.1.dylib ../../../lib/libadios2_atl.2.2.1.dylib

So you've at least got the relevant -I command lines. Looking for lines containing lex.yy.c I also see:
cd /Users/eisen/prog/openfoam/ThirdParty-v2306/sources/adios/ADIOS2-2.8.3/thirdparty/ffs/ffs && /usr/bin/flex -o/Users/eisen/prog/openfoam/ThirdParty-v2306/build/darwin64Clang/ADIOS2-2.8.3/thirdparty/ffs/ffs/lex.yy.c cod/cod.l

If you can get this kind of verbose output from make, maybe we can sort things.

ax3l · 2023-08-09T23:27:18Z

Maybe this helps: I just saw this error in one of my builds - Build i686 wheel on ubuntu-20.04 / build.log.zip:

  [ 18%] Building C object thirdparty/ffs/ffs/CMakeFiles/ffs.dir/cod.tab.c.o
  cd /project/build-adios2/thirdparty/ffs/ffs && /opt/rh/devtoolset-10/root/usr/bin/cc  -I/project/ADIOS2-fix-blosc2-findpackage/thirdparty/ffs/ffs -I/project/ADIOS2-fix-blosc2-findpackage/thirdparty/ffs/ffs/fm -I/project/ADIOS2-fix-blosc2-findpackage/thirdparty/ffs/ffs/cod -I/project/ADIOS2-fix-blosc2-findpackage/thirdparty/ffs/ffs/ffs -I/project/build-adios2/thirdparty/ffs/ffs -I/project/build-adios2/thirdparty/ffs/ffs/ffs -I/project/ADIOS2-fix-blosc2-findpackage/thirdparty/dill/dill -I/project/build-adios2/thirdparty/dill/dill -I/project/ADIOS2-fix-blosc2-findpackage/thirdparty/atl/atl -I/project/build-adios2/thirdparty/atl/atl -fPIC -w -O3 -DNDEBUG -std=gnu99 -fPIC -MD -MT thirdparty/ffs/ffs/CMakeFiles/ffs.dir/cod.tab.c.o -MF CMakeFiles/ffs.dir/cod.tab.c.o.d -o CMakeFiles/ffs.dir/cod.tab.c.o -c /project/build-adios2/thirdparty/ffs/ffs/cod.tab.c
  cod/cod.y:1869:10: fatal error: lex.yy.c: No such file or directory

openPMD/openPMD-api#1387

This is ADIOS 2.9.0 with a series of patches for static builds (see my last week's activity here).

eisenhauer · 2023-08-09T23:52:06Z

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...

albenstein · 2023-08-10T06:41:06Z

I'm attaching compile ADIOS2 with verbose;
compiling_Adios2_with_verbose.txt

eisenhauer · 2023-08-10T14:28:38Z

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.

ax3l · 2023-08-10T22:31:33Z

@eisenhauer

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...

Oh, thanks a lot! Let me restart the runner, might be a temporary GH runner issue and unrelated. Sorry for the noise in this thread!

eisenhauer · 2023-08-14T20:09:12Z

@albenstein , can you please try this substituting the ADIOS version in PR #3755? You can get this from https://github.com/eisenhauer/ADIOS2/, branch "UpstreamFFS".

albenstein · 2023-08-15T13:27:12Z

@eisenhauer Thanks, but there is no branch UpstreamFFS on github page.

eisenhauer · 2023-08-15T13:47:55Z

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.

albenstein · 2023-08-15T14:02:33Z

It's done, successfully installed. Now I'm trying to install openfoam. Thank you for your help :)

eisenhauer · 2023-08-15T16:02:40Z

Sounds good. There was a chunk of code that tested to see if the C preprocessor symbol "input" was defined as a way of telling if it needed to adapt to lex or the newer flex. If "input" was defined, that forced it to use the lex codepath, but that part had bitrotted because no system had the old lex. Something specific to your system or compiler must be defining "input" as a preprocessor symbol, triggering this problem. Hard to guess what that might be since we haven't seen it elsewhere, but as long as this fixes things all is well.

vicentebolea · 2023-08-23T23:16:22Z

This could have been resolved in #3760 since there we change the way that we export the ffs dependency

eisenhauer mentioned this issue Aug 14, 2023

Upstream ffs #3755

Merged

albenstein closed this as completed Aug 29, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ADIOS2 2.8.3 undefined reference #3742

ADIOS2 2.8.3 undefined reference #3742

albenstein commented Aug 7, 2023

eisenhauer commented Aug 7, 2023

albenstein commented Aug 7, 2023

eisenhauer commented Aug 7, 2023

albenstein commented Aug 7, 2023

eisenhauer commented Aug 7, 2023

albenstein commented Aug 7, 2023

eisenhauer commented Aug 7, 2023

albenstein commented Aug 8, 2023

albenstein commented Aug 8, 2023

albenstein commented Aug 8, 2023

albenstein commented Aug 9, 2023

eisenhauer commented Aug 9, 2023

albenstein commented Aug 9, 2023 •

edited

Loading

albenstein commented Aug 9, 2023 •

edited

Loading

eisenhauer commented Aug 9, 2023

ax3l commented Aug 9, 2023 •

edited

Loading

eisenhauer commented Aug 9, 2023

albenstein commented Aug 10, 2023

eisenhauer commented Aug 10, 2023

ax3l commented Aug 10, 2023

eisenhauer commented Aug 14, 2023

albenstein commented Aug 15, 2023

eisenhauer commented Aug 15, 2023

albenstein commented Aug 15, 2023

eisenhauer commented Aug 15, 2023

vicentebolea commented Aug 23, 2023

ADIOS2 2.8.3 undefined reference #3742

ADIOS2 2.8.3 undefined reference #3742

Comments

albenstein commented Aug 7, 2023

eisenhauer commented Aug 7, 2023

albenstein commented Aug 7, 2023

eisenhauer commented Aug 7, 2023

albenstein commented Aug 7, 2023

eisenhauer commented Aug 7, 2023

albenstein commented Aug 7, 2023

eisenhauer commented Aug 7, 2023

albenstein commented Aug 8, 2023

albenstein commented Aug 8, 2023

albenstein commented Aug 8, 2023

albenstein commented Aug 9, 2023

eisenhauer commented Aug 9, 2023

albenstein commented Aug 9, 2023 • edited Loading

albenstein commented Aug 9, 2023 • edited Loading

eisenhauer commented Aug 9, 2023

ax3l commented Aug 9, 2023 • edited Loading

eisenhauer commented Aug 9, 2023

albenstein commented Aug 10, 2023

eisenhauer commented Aug 10, 2023

ax3l commented Aug 10, 2023

eisenhauer commented Aug 14, 2023

albenstein commented Aug 15, 2023

eisenhauer commented Aug 15, 2023

albenstein commented Aug 15, 2023

eisenhauer commented Aug 15, 2023

vicentebolea commented Aug 23, 2023

albenstein commented Aug 9, 2023 •

edited

Loading

albenstein commented Aug 9, 2023 •

edited

Loading

ax3l commented Aug 9, 2023 •

edited

Loading