[Info-vax] Status of the PostgreSQL port?

[hb]

On 06/30/2015 12:46 AM, John Reagan wrote:
> On Monday, June 29, 2015 at 2:26:13 PM UTC-4, Stephen Hoffman wrote:
> 
>>
>> I very much do understand what you are writing about here, too.   All 
>> of the OpenVMS open-source I've worked on most recently -- around 100KB 
>> of new source code, plus some source bits ported from BSD to work 
>> around the lack of common C calls -- is itself a work-around for a lack 
>> of lowercase aliases in some shareable image symbol vectors.    For a 
>> lack of lower case alias entries in a shareable image options file 
>> somewhere.   That's a ~100KB work-around, all to make it easier for 
>> other open-source projects to be ported to OpenVMS.   All due to a lack 
>> of options file alias entries.
>>
> 
> I absolutely would support changes to the linker to help it resolve
lowercase aliases.  I'd even consider some tool (perhaps the linker itself)
to modify an existing symbol vector.

I'm sure there was a discussion on case-tolerant symbol resolution when
the linker was ported to I64. I don't remember the arguments. Obviously
it was decided to keep the exact match behavior. And, that's what I
think the linker in general should do.

If the owner of a shareable image exported a symbol "FOO" and a
developer codes a C application with calling "foo", it is simply wrong
and should not work. (Today it only works, because, by default, external
symbols are "uppercased" and, obviously, open source compiled with
/NAMES=AS_IS makes this fail).

The owner of the interface should either export both symbols "FOO" and
"foo" or the developer should code a call to "FOO". That's what the
alias name in the linker option symbol_vector offers and/or on the other
hand one might want to use #defines to continue using "foo" in the
sources. In other words, the owner of the shareable image and the
developer are responsible to offer and use the correct interface. It's
not the job of the linker to make a match just by magic: do what I mean.

That said and putting my in-theory-hat off, I don't think that the
support request is for case blind symbol resolution, in general. And I
see the problem and saw linker options files with lots of alias names
defined as well as C include files which have a lot of #defines to get
this right. From my point of view, to help or support some case-tolerant
resolution, one option could be to tell the linker that a case blind
match is wanted: a flag either in the object module or in the symbol,
set on request. Another option would be to have a linker option to map
symbols. So with the shareable image an options file could be provided
to define the mapping, or the developer of the application writes one
for the interfaces which are used. Then the owners of the code are still
responsible for using the correct interface.  A much simpler option may
be to let the linker, on request, generate matching lower- or uppercase
symbols for each exported symbol in a symbol_vector option. OK, just
some thoughts, open for discussion. This would be all for the x86_64
port, although I suspect, some people would like to have that for
Alpha/I64 as well.

On the other hand I don't understand what in this context you mean with
"some tool ... to modify an existing symbol vector". The symbol vector
itself doesn't contain any symbol. On I64, for procedures, it contains
the address of the function descriptor (which resides in short data). I
don't think you want to modify that. Do you want to modify the symbol
table? As you probably know, the symbols are only used by the linker and
lib$fis, the image activator doesn't use or need any symbol. (That's the
current or traditional VMS implementation and it is what some people
refer to as "early binding" which is different from Unix where the
loader uses the symbol for a "late binding").

The current tool to change an image is "SET IMAGE". There are no options
to modify anything related to symbols: striping off the symbols requires
a re-link.