just a follow-up, I have abandoned my efforts to port the SBE to a strict POSIX make environment. The issue is not the strict POSIX part, as that can be done with some work (53 files by my count, some of which migrate easily).
The real issue is that the SBE code is not particularly portable. Much of the hardware descriptions use C++ that could easily be implemented with structs, and the SBE relies on trivial (even lazy) C++ code in dozens of places that will not compile because the Linux implementation of C++ does not mesh well with the FreeBSD C++ implementation. Libraries and namespaces are labeled differently, so included files are not found, leading to a failure to compile. Fixing this would require an unreasonable amount of effort (over 8000 identified locations, plus the hardware descriptors), when there shouldn't even be any C++ code in something this close to bare metal. None of the functionality causing issues requires C++, and would have been much more portable if written in C14 or even C99. In some cases it is literally a std:: class to make a brief reference to a string. Utterly unnecessary, and in my opinion, either lazy or intentional.
The code in question came from IBM; the choice to use C++ and how it is used leads me to believe there was not a true effort to open up the SBE. The code released was built to a pretty specific environment, to the exclusion of others. This is a direct (and very disappointing) example of how open source is not always free, as in "free to port and use in one's personal environment." "Our way or no way" is not a choice, and without choices we are not free.
In my opinion it would be easier to construct a replacement to the SBE than to try to fix it.
