3

My project aims to provide a common interface between multiple different HDL simulators, so users can write test benches that will work no matter the simulator used. In this situation, it is the simulator, not the user's code, that is the driving application. When the simulator starts, it loads with it a library that abstracts the usage of the simulator to match a common interface. A library is written that exposes this interface for every supported simulator. So a user can write a single testbench using that common interface, and the testbench will work with any simulator.

What I need to know is the best way to load a user's library (that implements the testbench) from the common simulator interface libraries. There are two ways that I know of:

  1. Require the user's library to be named in a known way. They can modify LD_LIBRARY_PATH such that their implementation will be picked up (and first) when dlopen()ed.
  2. Make the full path to the user library available in a known environment variable and dlopen() it.

The first is what immediately came to mind when I thought about the problem. The second I have seen working before, but I don't really like it since it can pollute the environment; modifying LD_LIBRARY_PATH is otherwise innocuous. Are there any other ways this can be done? What are their pros and cons?

  • 4
    Two other options: - Read the name/path of the library from a configuration file; - Accept the name/path of the library as a command-line argument. – Bart van Ingen Schenau Oct 10 '18 at 7:04
  • Environment variables do not necessarily pollute your environment: You can start your programme via VARIABLE=VALUE EXECUTABLE. – Aconcagua Dec 25 '18 at 16:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.