How to solve -- Error: dlopen: ./out.so: undefined symbol

[jrmejiaa]

Hi,

I am working with Bluespec and my code is quite straight forward. It is one of the examples of the section 12.8.4 of the reference guide: Writing to a file. In this section there is this part of the code:

// Open the file and check for proper opening
String dumpFile = "dump_file1.dat" ;
File lfh <- $fopen( dumpFile, "w" ) ;
if ( lfh == InvalidFile ) begin
    $display("cannot open %s", dumpFile);
    $finish(0);
end
cnt <= 1 ;
fh <= lfh ;

However, when I run this code, I received an error after a successful compilation in the command $fopen which is the following:

Error: dlopen: ./out.so: undefined symbol: _Z12dollar_fopenPKcPKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_
    invoked from within
"sim load $model_name $top_module"
    (file "/opt/cad/bluespec/latest/lib/tcllib/bluespec/bluesim.tcl" line 188)

According to @rsnikhil in this closed issue of Picolo, the problem is related to a C compiler versioning. He is right, I started from scratch a compilation of bsc and later of the code and it works. However, in the server I don't have the rights to change the bsc compilation.

There is a way to solve this problem without compiling bsc again?

[quark17]

If your C++ compiler is gcc/g++, try providing the following flag:

-D_GLIBCXX_USE_CXX11_ABI=0

You can do this by adding the following to the BSC command line, which will tell BSC to pass the flag on to the C++ compiler:

-Xc++ -D_GLIBCXX_USE_CXX11_ABI=0

When BSC constructs the C++ compiler command, it will also look for CXXFLAGS and BSC_CXXFLAGS in the environment and, if defined, will add the value to the C++ command that it executes.

To go into more detail: BSC comes with precompiled C++ objects that implement the kernel of Bluesim. When you compile a design, BSC generates the C++ for your design, compiles that C++ using your C++ compiler, and links the compiled design objetcs with the provided Bluesim kernel object. Your C++ compiler doesn't have to be the same version as the C++ compiler that was used to make the kernel object, it just has to be compatible with those pre-generated objects, so that it can link them together. Compatibility is defined by whether the new C++ code will make calls into the library object using the same conventions (of how to find the function and where to put the arguments and how they are laid out etc). This convention is called the ABI (application binary interface). Some C++ compilers use a different ABI with each new major version, but GCC has tried to keep the ABI stable so that previously compiled libraries can still be used with newer versions of the compiler. However, the C++11 standard introduced some changes that required a new ABI for GCC, which was introduced in GCC 5. You can tell newer GCC to revert back to the old API, by defining _GLIBCXX_USE_CXX11_ABI to zero (as mentioned above).

Older BSC releases attempted to provide a single set of binaries that would work across multiple OSes, by being a "lowest common denominator". (This was unsustainable, though, and now you should use BSC releases that were compiled specifically for the OS and tool versions that you're using.) That multi-OS release was built with GCC 4, using its older ABI. If you're using that old release, but you have a newer version of GCC, you can probably get it to work by adding -D_GLIBCXX_USE_CXX11_ABI=0.

[jrmejiaa]

Hi @quark17

Thank you for such detail explanation about this issue of my setup. As you may anticipated it is working now as expected.

Thank you very much for your time