Repository navigation
Readme misleads proper loading order of artifacts (header->library) instead of (library->header) #123
Description
The readme is misleading
import cppjit
cppjit.include('zlib.h') # bring in the declarations
cppjit.load_library('libz') # load the symbols
cppjit.gbl.zlibVersion() # '1.3'; call the library directlyThis can cause same "Failure to materialize" issues as in wlav/cppyy#156.
Easy to reproduce
import cppjit
cppjit.cppdef("""bool call_func();static bool trap = call_func();""")
cppjit.cppdef("""bool call_func(){return true;}""")Correct order should be
import cppjit
cppjit.load_library('libz') # load the symbols
cppjit.include('zlib.h') # bring in the declarations
cppjit.gbl.zlibVersion() # '1.3'; call the library directlyFor ns-3 in particular, we build the library dependency tree (inspecting symbols in the binary). From there we determine the order to load (root library, then first level, second level, etc), then load libraries followed by their respective headers for each library of the simulator.
Before we had a crazy weird workaround that worked who knows why. Something like this in the header
class Time
{
public:
static StaticInit(); // defined in .cpp
};
// broken code did this: would not call Time::StaticInit due to symbol materialization issue
bool g_staticInit = Time::StaticInit();
// workaround code (before I realized I needed to load library before header): calls Time::StaticInit in spite of symbol materialization issue of g_staticInit
class TimeInitHelper
{
public:
TimeInitHelper()
{
Time::StaticInit();
}
};
static TimeInitHelper g_staticInit; // g_staticInit fails to be materialized, but StaticInit is called anyways
Metadata
Metadata
Assignees
Labels
No labels
Activity
aaronj0 commentedon Oct 6, 2026
Yeah this makes sense. I'll update the README before our next release and address this along with that. Thanks for the report!