[Info-vax] linkshrlib.com - link opensource libraries into shareable images

[Jose Baars]

Op vrijdag 3 augustus 2012 15:35:43 UTC+2 schreef Stephen Hoffman het volgende:

>Toss the entry points into an RMS indexed file or into a SQLite
>database for the version-to-version "views" of the APIs, have the
>linker look at that instead of the transfer vector dreck in the options
>file, and Bob's (Mostly) Your Uncle. 

True, that would be ideal, so you have the ability to track changes over the various versions as well.

This should be part of a more general version and package management system,
which should, among other things, include a network accessible repository and a dependency database.

> 
> 
> On OpenVMS Alpha, this task can be implemented without particular 
> integration in the Linker and the compilers, using the compiler 
> analysis files and an undocumented feature of the OpenVMS Alpha Linker 
> (which I don't think made it to Itanium), and the aforementioned 
> database.  You'd need to scan these analysis files from the compilers 
> and (maybe) from the constituent shareable images, and could then 
> synthesize the transfer vectors for the linker pass.

linkshrlib.com builds transfer vectors on Alpha and Itanium, using 
a slightly modified analyze/object command. It's text-processing though,
so arguably at the kludge side of the spectrum between proven mathematical algorithms and absolute kludges. 
It does not detect changes in the API, so if a function  int dothis( char *that ) changes to void dothis( char yesno ) you're on your own.

>  
> Now for the difficulty with the automated process.  There'd be an 
> expectation of a DIFFERENCES-like tool.

Which would be simple to build once the database based versioning system
were in place. 
linkshrlib marks differences in the warnings and output vector file, but that
is obviously only between two versions.

> The programmer would then need to sort out whether the routine can be 
> stubbed out with a "thanks for calling, but this call is no longer 
> valid", or if the programmer should implement a "stub", or if the 
> full-on GSMATCH major-version change is appropriate.

> There's a brute-force solution that a few folks around here know about, 
> too, that's pretty close to this.  A tool called vic.  But that tool is 
> expressly targeted at APIs that were intending to be compatible, where 
> open source APIs (for instance) can be the wild-west of APIs.  

Actually, most open source libraries seem at least to try to be as upward compatible as possible. OpenSSL is the odd one out.
 
> 
> If you're responsible for the APIs and aiming for compatibility, this 
> becomes a vastly easier problem.

Then there should be no problem, as you would be expected to maintain a comprehensive administration of your project, including API definitions.

> If you're working with a project 
> that's not targeting API compatibility, then no software tool in the 
> world is going to fix that mess for you.

True. But scanning the code of for instance OpenSSL by hand to find all possible entry points is an even greater mess.

> 
> Full disclosure: I shipped one of these API scanner hacks on the  
> Freeware an eon or two back.
> 
What was it called? Is it still online somewhere?