Compile common libraries to single libs directory

[themperek]

• common libraries are compiled once to /cocotb/libs directory which results in a faster compilation, less space and easier use

• vpi/vhpi/fli are compiled with _simulator_name sufix (. has special (directory separation) meaning in setuptools) in same directory /cocotb/libs.

• simulator module is compiled once and located in /cocotb folder. This allows using form cocotb import simulator
  -> simulator module can be added to documentation (need to install/compile) -> future PR.
  -> can remove COCOTB_SIM -> future PR

• removed from makefiles LD_LIBRARY_PATH everywhere -> less potential collision with user environment settings

Resolves #1181

Checked with ALL supported (Linux) simulators.

[eric-wieser]

Would it be easier to compile all the libraries (and not just the "common" ones) to a single directory, and call them libcocotbvpi.aldec.so etc? That would reduce the need for the rpath stuff, right?

[themperek]

Would it be easier to compile all the libraries to a single directory, and call them libcocotbvpi.aldec.so etc? That would reduce the need for the rpath stuff, right?

Then one needs to change how entry_points work. Possibly can be done but not sure if less ugly.

[eric-wieser]

Which entry_points are you referring to?

[themperek]

Which entry_points are you referring to?

Like here:

cocotb/cocotb/share/lib/vpi/VpiImpl.cpp

Line 716 in 1e8880e

GPI_ENTRY_POINT(vpi, register_embed)

cocotb/cocotb/share/lib/gpi/gpi_priv.h

Lines 346 to 355 in b283b48

	/* Use this macro in an implementation layer to define an entry point */
	#define GPI_ENTRY_POINT(NAME, func) \
	extern "C" { \
	void NAME##_entry_point() \
	{ \
	func(); \
	} \
	}
	#endif /* COCOTB_GPI_PRIV_H_ */

I think I have seen problems here.

[eric-wieser]

I think we'd only want to change these lines:

cocotb/cocotb/share/lib/gpi/GpiCommon.cpp

Lines 163 to 172 in 1e8880e

	std::string full_name = "lib" + *iter + DOT_LIB_EXT;
	const char *now_loading = (full_name).c_str();
	lib_handle = utils_dyn_open(now_loading);
	if (!lib_handle) {
	printf("cocotb: Error loading shared library %s\n", now_loading);
	exit(1);
	}
	std::string sym = (*iter) + "_entry_point";
	void *entry_point = utils_dyn_sym(lib_handle, sym.c_str());

We use the name in GPIEXTRA twice - once to pick the dll, and another to pick the function name. We could strip the .aldec from the string before doing the second step, and then I think things would work.

[themperek]

We use the name in GPIEXTRA twice - once to pick the dll, and another to pick the function name. We could strip the .aldec from the string before doing the second step, and then I think things would work.

Looks like you are right.

[themperek]

We use the name in GPIEXTRA twice - once to pick the dll, and another to pick the function name. We could strip the .aldec from the string before doing the second step, and then I think things would work.

I did not write C/C++ code for 10 years. If you give me snippet I can try other way need to read a bit to remember myself how this was done ;-)

[marlonjames]

We could also change GPI_EXTRA format to provide the dll name and entry point name together, rather than enforce libXXX.dll, XXX_entry_point(). This could be useful for cocotb extensions that want to load code into GPI at startup.

[themperek]

Could follow the same convencion like some tools loading VPI: libX:entry_pointX,libY:entry_pointY ?

[eric-wieser]

Sounds like a good idea to me

[eric-wieser]

Re splitting - one way to do it would be something like this:

std::string arg = "mylib:my_entry_point";

std::string lib_name;
std::string func_name;
auto it = std::find(arg.begin(), arg.end(), ':');
if (it == arg.end()) {
    // no colon in the string
    lib_name= arg;
    func_name = "whatever our default was";
}
else {
    lib_name = std::string(arg.begin(), it);
    func_name = std::string(it+1, arg.end());
}

[eric-wieser]

For a future PR: These log lines aren't accurate, all you're doing is producing a list of libraries to be compiled.

[eric-wieser]

Looks good now, thanks for all the work here.

[themperek]

Thank you @eric-wieser for all help.

[imphil]

Looks great, thanks! Thanks a lot for pushing this through, it's greatly appreciated.

[eric-wieser]

Conflicts are with the change to C++, should be easy to resolve.