AWalker@RED.RUTGERS.EDU.UUCP (08/01/87)
/NOSYSSHR does *not* do what I want. I want to *include the code from the shareable library*, not simply exclude it. Say I have something that calls lib$put_output, which I want to build on a 4.5 system and then run on a 4.1 box. [Or have somebody *else* run it, more to the point.] Link/nosysshr complains about undefined symbols like lib$put_output; if I link my thing together with imagelib I *still* get the mismatches at the 4.1 end. Sorry if my original query wasn't clear enough. Please understand that I'm trying to do something that "I shouldn't"; I see no reason, however, why I am being *prevented* from generating a downward-compatible image. I further don't want to hear about this being a marketing ploy for upgrading my VMS; whether it is or not there are some people who simply don't, and I refuse to let something as dumb as this disallow my shipping them an executable. Short of diddling the 4.1 gsmatch flags, how do I do this?!?! _H* -------
gkn@SDS.SDSC.EDU (08/03/87)
From: *Hobbit* <AWalker@RED.RUTGERS.EDU> Subject: Y'all don't get it Date: 1 Aug 87 03:45:32 EDT /NOSYSSHR does *not* do what I want. I want to *include the code from the shareable library*, not simply exclude it. Er, consider the following example program: .title foo .ident /x/ .psect data noexe,rd,nowrt,pic,shr,page message: .ascid "Hello, Hobbit!" .psect code exe,rd,nowrt,pic,shr,page .entry start,0 pushaq message calls #1,g^lib$put_output ret .end start I linked it two ways on a VMS V4.5 system: $ Link/NoSYSSHR FOO $ Link/EXE=FOO1 FOO Then I copied both executables over to a VMS V4.2 system. When I run FOO, I get "Hello Hobbit!". When I run FOO1, I get "Ident mismatch with shareable image". Say I have something that calls lib$put_output, which I want to build on a 4.5 system and then run on a 4.1 box. [Or have somebody *else* run it, more to the point.] Link/nosysshr complains about undefined symbols like lib$put_output; if I link my thing together with imagelib I *still* get the mismatches at the 4.1 end. Sounds as if you've lost your copy of STARLET.OLB; /NoSYSSHR directs the linker to not link against IMAGELIB.OLB (the shareable image library) and instead resolve references by searching STARLET.OLB. Sorry if my original query wasn't clear enough. Please understand that I'm trying to do something that "I shouldn't"; I see no reason, however, why I am being *prevented* from generating a downward- compatible image. I've had to do this lots of times -- when you're writing software for a customer, and the company has promised to deliver executables only, you have to do this or you get sick of the phone calls about "Ident mismatch...". gkn -------------------------------------- Arpa: GKN@SDS.SDSC.EDU Bitnet: GKN@SDSC Span: SDSC::GKN (27.1) USPS: Gerard K. Newman San Diego Supercomputer Center P.O. Box 85608 San Diego, CA 92138 AT&T: 619.534.5076
ted@blia.BLI.COM (Ted Marshall) (08/04/87)
In article <12322949899.25.AWALKER@RED.RUTGERS.EDU>, AWalker@RED.RUTGERS.EDU (*Hobbit*) writes: > /NOSYSSHR does *not* do what I want. I want to *include the code from the > shareable library*, not simply exclude it. > > Say I have something that calls lib$put_output, which I want to build on > a 4.5 system and then run on a 4.1 box. [Or have somebody *else* run it, > more to the point.] Link/nosysshr complains about undefined symbols > like lib$put_output; if I link my thing together with imagelib I *still* > get the mismatches at the 4.1 end. This (LINK/NOSYSSHR) works fine for me. However, are you by chance running micro-VMS instead of VMS? As I said in my earlier posting, the copy of STARLET.OLB shipped with Micro-VMS is much cut down. Unless you can get your hands on the STARLET.OLB from full VMS, I think you are stuck. -- Ted Marshall ...!ucbvax!mtxinu!blia!ted <or> mtxinu!blia!ted@Berkeley.EDU Britton Lee, Inc., 14600 Winchester Blvd, Los Gatos, Ca 95030 (408)378-7000 The opinions expressed above are those of the poster and not his employer.