Adios2: Static lib: Bison/Flex Symbol Hiding in SST

[ax3l]

Hi,

probably a question for @chuckatkins. Downstream in WarpX, we use flex to generate a parser for our input options.

If we are linking to a static ADIOS2, especially the libadios2_ffs.a components, we see symbol conflicts on NERSC's Cori of the kind:

/usr/bin/ld: lib64/libadios2_ffs.a(cod.tab.c.o):(.data+0x8): multiple definition of `yylineno'; CMakeFiles/WarpX.dir/Source/Parser/wp_parser.lex.cpp.o:(.data+0x0): first defined here
/usr/bin/ld: lib64/libadios2_ffs.a(cod.tab.c.o):(.bss+0x0): multiple definition of `yy_flex_debug'; CMakeFiles/WarpX.dir/Source/Parser/wp_parser.lex.cpp.o:(.bss+0x8): first defined here
collect2: error: ld returned 1 exit status

The problem goes away with shared builds (which can be done on Cori's Cray since last year).

Besides disabling the Bison/Flex features of SST at configuration time, I was wondering if it was possible to hide or rename the bison/flex symbols that are used in ADIOS2 to avoid such conflicts? I tested this currently with the ADIOS2 2.6.0 release.

Thank you for your help,
Axel

[eisenhauer]

So, yes, this should be fixable. We (or WarpX) can change the 'yy' prefix to something else, at least for flex (not lex) with the --prefix argument or '%option prefix="PREFIX"’ in the .l file. On installations that use lex rather than flex, and where lex generates yylineno (not all of them), this would continue to be a problem, but those might be rare (and switching to flex would avoid it). Let me see what I can do in ffs. I just want to make sure not to break lex compatibility.

Update: Actually, this is easier than I thought. There's already a renaming of yy variables setup in FFS (using #define so that it works in both flex and lex). However, it didn't include yylineno or yy_flex_debug. So simply adding two more #define's should do the trick. I'll get this pushed into FFS and then ADIOS. I would think we could do that for the 2.7.0 release.

[eisenhauer]

OK, merged. Can you test branch release_27 with this to verify that the patch fixes the problem?

[ax3l]

Hi Greg, thank you very much for the quick fix and hints!
I tested the release_27 branch and this fixes it, thanks a lot! :sparkles: