-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ADIOS2 2.8.3 undefined reference #3742
Comments
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.) |
Thanks for response.
|
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 and this in the build: thanks, |
It found flex and bison on system. ... -- ADIOS2 ThirdParty: Configuring ffs |
If lex.yy.c is present in the build directory, can you please attach it here? |
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.)
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. |
I'm using different build and source location. |
I've checked on OpenFoam-v2212 version, I got same error. |
I'm also attaching compiling process log: |
I've just compiled ADIOS2 version 2.9.1 and I got same error. |
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. |
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:
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.
I've added VERBOSE=1 to makeAdios2 file but I could not see any -I argument on screen. |
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 :) |
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:
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:
So you've at least got the relevant -I command lines. Looking for lines containing lex.yy.c I also see: If you can get this kind of verbose output from make, maybe we can sort things. |
Maybe this helps: I just saw this error in one of my builds - Build i686 wheel on ubuntu-20.04 / build.log.zip:
This is ADIOS 2.9.0 with a series of patches for static builds (see my last week's activity here). |
Huh. Odd that these are popping up with code that hasn't changed quite a long time. @ax3l , I see this in your build
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... |
I'm attaching compile ADIOS2 with verbose; |
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. |
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! |
@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". |
@eisenhauer Thanks, but there is no branch UpstreamFFS on github page. |
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. |
It's done, successfully installed. Now I'm trying to install openfoam. Thank you for your help :) |
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. |
This could have been resolved in #3760 since there we change the way that we export the ffs dependency |
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:
ThirdParty: https://dl.openfoam.com/source/v2306/ThirdParty-v2306.tgz'
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: