On Wednesday, July 23, 2003, at 03:16PM, Michael G Schwern <[EMAIL PROTECTED]> wrote:
>On Wed, Jul 23, 2003 at 08:26:01AM -0500, Craig A. Berry wrote: >> We'd have to know (or determine at compile-time) whether the compiler >> had this capability > >Ok, should be a simple matter of having Configure compile a short C program >which contains two symbols with the same case. Just like it tests for >everything else. Yes, I meant configure-time, not compile-time. A configure-time check could probably tell you whether the compiler has the capability to produce case-sensitive symbols. In fact, simply running $ cc/names=as_is nl: should give you an unrecognized qualifier error if your compiler version does not have the feature. However, having the feature doesn't mean it will do all the things you expect it to. You will produce object code that has mixed-case symbols, but how will you know everything you might want to link against also has mixed-case symbols? The vendor-supplied libraries generally provide entry points in both upper case and mixed case, but coverage was uneven when this was a new feature a few years ago. I believe the pthread library, for example, at one point had symbols in one case but not the other, so there had to be workarounds to build against it using case sensitive symbols. >> We'd then need to test the new default >> on a range of systems, hoping we covered all the compiler versions >> that are likely to be found in the wild. > >No need if you base it on a functionality test above rather than version #. As noted above, compiler functionality isn't the whole story. And even if it were we would still need to test the configuration process against older compilers to make sure we didn't break anything. >> When we're done we'd have >> fixed some problems but created others, such as inability to resolve >> symbols when linking against external libraries that were not built >> with case preservation enabled. > >This problem I don't quite understand. Say you are linking against a math library with symbols in all upper case and a database library with symbols in mixed case. Though there are some tricks you can play with dynamic libraries, the basic choice is to rebuild one library or the other so you are using one case convention or another. Since all upper case was the convention for a couple of decades before there was an option and since most everything still supports that, the path of least resistance is usually to avoid using mixed-case symbols. If you control all the pieces, only need to support recent systems, and/or have a package with a large number of name collisions in a case-leveled environment, then the case sensitive option is ready and waiting.
