Suddenly, make spaghetti of enormity

OK, here is software land I decide to give the symbols code three compile time options, linked in t run time, loadables, that is three, but multiply by the tree module it effects in three different sub directories. If i consider optional configure for IO manager, multiply by 2 sqyuared, because I have all the sub configurations to match.

Compile time is difficult because the code is not up and running, and the code knows what it is dong much better than a compiler. That is sort of the advantage of interpretive languages, the 'compile' is run time, so the code itself knows when to '=share', 'link', or 'standalone' or whatever.

Very little is known at compile time,  hence the preparation for all possible object formats spread ll over the directories.  But the console loop is getting a good test trying to load these mis construed objects I am generating.  Run time configuration, i need to get back to that model.

Take PIC, for example

The function of placing a compiled code in the proper place in memory is a necessity, whether done at compile, run, or load time. The addresses are 64 bit, this is not a problem, compile it all to PIC, then let the run time loader and compile time loader be the same short code and place it where is can fit.  These are the gains from Moores's Law, use them.

User space name spacing. It would be nice if one module can load another and privatize the entry points, cascade module,like c++ does at compile time. The dlsym has some facility for that, but it needs be built in.

RTLD_DEEPBIND (since glibc 2.3.4)Place the lookup scope of the symbols in this library ahead of the global scope. This means that a self-contained library will use its own symbols in preference to global symbols with the same name contained in libraries that have already been loaded.

And:

There are two special pseudo-handles, RTLD_DEFAULT and RTLD_NEXT. The former will find the first occurrence of the desired symbol using the default library search order. The latter will find the next occurrence of a function in the search order after the current library. This allows one to provide a wrapper around a function in another shared library. 

Option one lets a module declare its symbols local to itself to avoid calling the global entry f another module having the same interface..   Notquite what I need.

The second is the complement, is closer. I seems that RTLD_NEXT chains the module, and the master module, that loaded the others, ends up getting the entry calls, and it dispatches to the others.  This seems like a good idea to me. LoadModule can check the chain, find the master module and let it handle init of new module. The challenge has already been pioneered by someone else.