Conference turris::c_plus_plus

3501.0. "How to link with /NOSYSSHR/NOSYSLIB??" by VAXCPU::michaud (Jeff Michaud - ObjectBroker) Tue Mar 18 1997 17:17

	I did an AltaVista NOTES search for +nosysshr* +nosyslib* and
	found no matches, and also searched for +mthrtl and looked at
	those seven matches but none of those were doing what I'm trying
	to do.

	I finally have built both VAX and Alpha VMS shared executables that
	are upward compatible.  Getting things code reviewed my project
	leader wanted me to change something that sounded simple enough,
	but isn't working....

	For all our C bindings shared executables on VMS we use
	LINK/NOSYSSHR/NOSYSLIB and explicitly (via an options file)
	link against copies all the needed shared executables that we
	have in our build tree.  The reason I'm told is because we
	want to make sure we are linking against consistent and correct
	versions of the executables so we won't get GSMATCH mismatches
	on customers systems.  Ie. we can't trust what's in Alpha/Sys$Library
	because some layered products we install on the cluster sometimes
	put newer or older shared executables on the system.

	To get our C++ bindings shared executable on VMS to link
	I simply used LINK with out specifying the NOSYS* qualifiers.

	Now I switched it over to LINK/NOSYSSHR/NOSYSLIB and I created
	an options file to pull in (using library.exe/SHAREABLE options
	in the options file) all the shared libraries that were listed
	in the output of ANALYZE/IMAGE of the shared executables.  For
	VAX/VMS this was:

ACA$MAKE_SYSSHARE:CXXL$011_SHR/SHAREABLE
ACA$MAKE_SYSSHARE:MTHRTL/SHAREABLE
ACA$MAKE_SYSSHARE:LIBRTL/SHAREABLE
ACA$MAKE_SYSSHARE:LIBRTL2/SHAREABLE
ACA$MAKE_SYSSHARE:SECURESHR/SHAREABLE
ACA$MAKE_SYSSHARE:SECURESHRP/SHAREABLE
ACA$MAKE_SYSSHARE:CMA$TIS_SHR/SHAREABLE
ACA$MAKE_SYSSHARE:CMA$RTL/SHAREABLE
ACA$MAKE_SYSSHARE:CMA$LIB_SHR/SHAREABLE
ACA$MAKE_SYSSHARE:CMA$OPEN_RTL/SHAREABLE
ACA$MAKE_SYSSHARE:DECC$SHR/SHAREABLE

	and for Alpha/VMS this was:

ACA$MAKE_SYSSHARE:CXXL$011_SHR/SHAREABLE
ACA$MAKE_SYSSHARE:LIBOTS/SHAREABLE
ACA$MAKE_SYSSHARE:SYS$PUBLIC_VECTORS/SHAREABLE
ACA$MAKE_SYSSHARE:DECC$SHR/SHAREABLE

	Linking this way however results in undefined symbol(s).  On
	VAX/VMS it also gets an additional warning:

%LINK-W-NUDFSYMS, 2 undefined symbols:
%LINK-I-UDFSYM,         LIB$INITIALIZE
%LINK-I-UDFSYM,         SYS$IMGSTA
%LINK-W-DBGTFR, image $USER1:[MICHAUD.OBB.BASE.BUILD.VAX_VMS]OBB$ORBSHR.EXE;1 ha
s no Debugger transfer address

	and on Alpha/VMS only one (and no debugger transfer address warning):

%LINK-W-NUDFSYMS, 1 undefined symbol:
%LINK-I-UDFSYM,         LIB$INITIALIZE

	Is there some piece of magic I'm missing, like maybe a static
	.obj in imagelib.olb that I need to link in?

    The undefined globals are due to /NOSYSLIB as opposed to /NOSYSSHR.
    On both VAX and Alpha add
    
       SYS$LIBRARY:STARLET/INCLUDE=LIB$INITIALIZE
    
    

>     The undefined globals are due to /NOSYSLIB as opposed to /NOSYSSHR.
>     On both VAX and Alpha add
>     
>        SYS$LIBRARY:STARLET/INCLUDE=LIB$INITIALIZE

	Thanks, that did it.  Actually we also have a copy of that
	in a private area as well (again to avoid layered products
	causing us version skew problems if they overwrite it).

	We don't use the /INCLUDE on it however, maybe that's because
	we already have unresolved symbols that are defined in that
	module?