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

[Stephen Hoffman]

On 2012-08-03 04:28:14 +0000, John Reagan said:

>> 
>> Hopefully similar functionality is included in the C and other compilers
>> as well.
> 
> The problem with such a feature is that SYMBOL_VECTORs are order 
> dependent. If you add a new routine to the middle of your C (or Fortran 
> or Pascal or...) module, you want the new PROCEDURE entry to be at the 
> END of the symbol vector.  Of course, the compiler wouldn't know how to 
> do that.  Each "automatically generated symbol vector" might have a 
> different order than the prior one.

True.

Which is why the GSMATCH is set to match-exactly, and why the match 
value intentionally changes.

The core of this is whether the upstream source intends API 
compatibility or not.  (This is what bit the SSL libraries; the 
upstream APIs changed.)

Dealing with some of this problem is simple with a database and some 
scanners, and particularly easy if modifications to the existing Linker 
and (maybe) the compilers are in play.

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.

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.

I have some stuff that brute-force scans C code to do this (using some 
carnal knowledge of the C code format), and loads that into a database. 
 This task can be generalized if you're willing to haul around parts of 
LLVM, or if you can get access to the analysis API libraries or the ANA 
file formats, and that Linker API.  (And preferably, if that Linker API 
gets hauled over to Itanium.)

Now for the difficulty with the automated process.  There'd be an 
expectation of a DIFFERENCES-like tool, which allows the programmer to 
see which APIs have been added or removed or changed, and determine 
which should be passed through to the caller, and (if APIs are 
vaporized) whether the major version of the GSMATCH should be changed.  
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.  If 
you're responsible for the APIs and aiming for compatibility, this 
becomes a vastly easier problem.  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.

Full disclosure: I shipped one of these API scanner hacks on the 
Freeware an eon or two back.


-- 
Pure Personal Opinion | HoffmanLabs LLC