Question

Compiled object code is required for cases where the compilation and linking of source code is fully handled by the user; thus, the created object code only need be loaded to integrate the Foreign Language Code into a SystemVerilog application. All SystemVerilog applications shall support the integration of Foreign Language Code in object code form. Figure 7-1depicts the inclusion of object code and its relations to the various steps involved in this integration process.

Figure 7-1 — Inclusion of object code into a SystemVerilog application

Compiled object code can be specified by one of the following two methods:

1. by an entry in a bootstrap file; see Annex G.2.1 for more details on this file and its content. Its location shall be specified with one instance of the switch -sv_liblist pathname. This switch can be used multiple times to define the usage of multiple bootstrap files.
2. by specifying the file with one instance of the switch -sv_lib pathname_without_extension (i.e., the filename shall be specified without the platform specific extension). The SystemVerilog application is responsible for appending the appropriate extension for the actual platform. This switch can be used multiple times to define multiple libraries holding object code.

Both methods shall be provided and made available concurrently, to permit any mixture of their usage. Every location can be an absolute pathname or a relative pathname, where the value of the switch -sv_root is used to identify an appropriate prefix for relative pathnames (see Annex G.1 for more details on forming pathnames).

The following conditions also apply.

• The compiled object code itself shall be provided in form of a shared library having the appropriate extension for the actual platform. NOTE—Shared libraries use, for example, .so for Solaris and .sl for HP-UX; other operating systems might use different extensions. In any case, the SystemVerilog application needs to identify the appropriate extension.
• The provider of the compiled code is responsible for any external references specified within these objects. Appropriate data needs to be provided to resolve all open dependencies with the correct information.
• The provider of the compiled code shall avoid interferences with other software and ensure the appropriate software version is taken (e.g., in cases where two versions of the same library are referenced). Similar problems can arise when there are dependencies on the expected runtime environment in the compiled object code (e.g., in cases where C++ global objects or static initializers are used).
• The SystemVerilog application need only load object code within a shared library that is referenced by the SystemVerilog code or by registration functions; loading of additional functions included within a shared library can interfere with other parts.

In case of multiple occurrences of the same file (files having the same pathname or which can easily be identified as being identical; e.g., by comparing the inodes of the files to detect cases where links are used to refer the same file), the above order also identifies the precedence of loading; a file located by method 1) shall override files specified by method 2).

All compiled object code need to be loaded in the specification order similarly to the above scheme; first the content of the bootstrap file is processed starting with the first line, then the set of -sv_lib switches is processed in order of their occurrence. Any library shall only be loaded once.