Boy, where do I start. This one really kicked me around the office for a couple weeks. I believe I figured out just what is going on though. I now have reason to believe that "Error" is some sort of reserved word/object in C++. The "CC" compiler has some sort of problem with it. I made use of the "nm" command in UNIX and took a look at the ".o", the ".a", and the ".exe" and discovered some interesting things. nm on the ".o" showed me that gcc new the "Error" function as a function (type = FUNC). nm on the ".a" also showed me that gcc understood the "Error" function to be a function (type = FUNC). nm on the ".exe" showed me something a bit different. It showed me that CC understood the "Error" function to be a data object (type = OBJT). This told me why I received the SIGILL when my exe made the call to the "Error" function. I also threw a "-m" into the link of my exe in order to generate a Link Editor Memory Map. This Map also showed me (or should I say didn't show me) something interesting. The ".o" file that contained the "Error" function was no where to be found in the map I generated. This told me that CC understood "Error" to be something other than a function from the api. I went even further and built a small variadic function called "Error" in my code. Rebuilt the exe and looked at the new map and the output from nm and noticed the same things. It thought "Error" was still of type OBJT. I tried one more thing (and this clinched it for me), I built another function called "robError" in the api exactly like "Error". I called "robError" in my code and rebuilt the exe. The nm command told me that "robError" was of type FUNC and the map included the ".o" file. So, my solution .............................. Rename the "Error" function in the api code and place a "#define Error newErrorName" in the header file that contains the function prototype. This saves me from having to rename it everywhere the api calls it.

Just thought I'd share this info with everyone interested !!!