I used "configure-alt" to build the static newlisp binary. The "--disable-static" flag doesn't seem to be the right option. It builds the the executable as shared, but doesn't build the newlisp.so library.
After running configure-alt, I've update makefile_build to add -fPIC to the .o rule and -shared -o newlisp.so. That creates a shared library. I don't see a simple way to check it though - it looks like it's impossible to build a newlisp that dynamically loads newlisp.so. It seems that driving newlisp from a C program isn't a common use case, so I'd like to step back and make sure that I'm approaching this sanely.
I have an application written in C. Currently, it has Lua embedded in it. It's a shebang executable, so script files with "#!/path/to/ox" are the most common entry point. When it executes, it initializes the environment, loads the Lua interpreter from shared libraries, does the same for Oracle and SQLite3. Once all the shared libraries are in place, it loads the text of the script, strips off the shebang, and executes the script. As it reads in the script, it does some basic substitutions so that the users can run the same script on different servers (dev/test/qa/production). The processed text is feed into Lua and Lua is the glue to run the various bits and pieces against the database.
I want to replace the Lua bits with newlisp. I have to keep the external interface the same - I can't change the name of the job script or the invocation. Going from "/path/to/there/aJobName" to "/path/to/bin/newlisp aJobName" isn't acceptable. Heck, I can't even have them set up their environment to add the library paths newlisp needs. There's no technological reason for that constraint, it's budge. There are about a thousand users working in many different departments and my group doesn't have the budget to pay them to change their jobs.
Other than that, I have a good degree of freedom. As long as the system is always operational, that is, so I plan on reusing the current system's C code that does the initialization and script substitution logic. After testing that, I can roll out changes as quickly as I can update the Lua code in a job script to newlisp.
I looked at the option of changing "/path/to/there/aJobName" to a bash script that does something like set up the new lisp environment then run "newlisp /path/to/there/aJobName.lsp." I'd prefer not to if it's reasonable to have that preference.
Sorry for the big build-up to a simple question: What's the "best practice" - embedding newlisp or extending newlisp?