Craig Berry wrote: > > > 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.
Ok, I'll confess to being relatively new to Perl, especially in regards to the internal workings of building extensions to Perl so I may be missing something fundamental. But, why not simply have the utility that turns the .XS file into a .C file surround the routine/function names with the appropriate #pragma statements to make them compile as_is but leave everything else untouched. This should handle whatever names the extension author may choose to use without impacting the ability to link to anything else on VMS. Is there any reason why this wouldn't work? Mark Berryman
