Article 147438 of comp.os.vms: In article <15MAY199619292980@eql.caltech.edu>, rankin@eql.caltech.edu (Pat Rankin) writes: > In article <31991A1A.527A@airmail.net>,\ > Chris Scheers writes... >> I'm curious, how does it break an existing application? > > It wouldn't affect existing images, and it wouldn't pose any > inordinate trouble for new applications. But it would potentially > break the rebuilding of existing applications. > > Yesterday your application built find. Today you update the > VMS linker to apply the fix being discussed. Tomorrow some of your > build procedures or makefiles don't work any more; the linker reports > lots of unresolved references to library routines. On one hand, your > build procedure was already wrong, because it replied on library A > dragging in library B to resolve your own references to library B. > On the other hand, a change to VMS just caused you to do more work > (the fix would generally be trivial, but investigating it probably > wouldn't be) so you start complaining to Digital. > > ... > Pat Rankin, rankin@eql.caltech.edu -- Pat, et. al, A small trick that I have used for many years (and suggest to all of my clients): Do your applications links against a dummy shareable image which only has the entry points actually exported by that particular image. That way, you don't have cascading problems. This trick also prevents new entry points from sneaking into the library. Additionally, this trick makes it straightforward to do some very interesting applications tricks (one of presentations at the Spring 1996 DECUS will be on this topic, "Case Studies in VMS Shareable Libraries"). - Bob +--------------------------------------------------------------------------+ | Robert "Bob" Gezelter E-Mail: gezelter@rlgsc.com | | Robert Gezelter Software Consultant Voice: +1 718 463 1079 | | 35-20 167th Street, Suite 215 Fax: (on Request) | | Flushing, New York 11358-1731 | | United States of America | +--------------------------------------------------------------------------+