Whoops, I totally forgot to mention the other potentially useful feature I added this weekend. Now, entries in the 'libraries' list can include a directory component, which will tell the compiler interface to instruct the C compiler to look only in that directory for that particular library.
This can lead to some real problems. When given a shared object, most link editors (ld) will use that exact pathname to find the object at runtime, ignoring the -R (-rpath) and LD_LIBRARY_PATH (LIB_PATH) variables. The system had better determine when and how shared objects (.sl/.so) should be handled differently from archive files (.a). Also, considering that most testing is handled in the build environment (with those same pathnames), this type of problem might not be found until after installation. (Just as a rule, think of how the executable search path rules work. The library search path rules are similar: if there is a '/' in the filename, then do not search with LD_LIBRARY_PATH.) Does anyone know if this might happen with DLLs too? -Arcege -- ------------------------------------------------------------------------ | Michael P. Reilly, Release Engineer | Email: arcege@shore.net | | Salem, Mass. USA 01970 | | ------------------------------------------------------------------------