[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference hydra::axp-developer

Title:Alpha Developer Support
Notice:[email protected], 800-332-4786
Moderator:HYDRA::SYSTEM
Created:Mon Jun 06 1994
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3722
Total number of notes:11359

3588.0. "Softlab - Point 27618" by KZIN::ASAP () Tue May 06 1997 11:57

    Company Name :  Softlab - Point 27618
    Contact Name :  Herr. Glania
    Phone        :  089 9936 1590
    Fax          :  
    Email        :  [email protected]
    Date/Time in :   6-MAY-1997 15:57:32
    Entered by   :  Ian Chamberlin
    SPE center   :  REO

    Category     :  unix
    OS Version   :  4.0b
    System H/W   :  


    Brief Description of Problem:
    -----------------------------

From:	RDGENG::MRGATE::"RDGMTS::PMDF::mail.dec.com::LennonD"  6-MAY-1997 14:48:39.85
To:	RDGENG::ASAP
CC:	
Subj:	POINT 27618, Softlab

From:	NAME: Declan Lennon <[email protected]@PMDF@INTERNET>
To:	NAME: '[email protected]' <IMCEAX400-c=US+3Ba=+20+3Bp=DIGITAL+3Bo=SBUEURMFG+3Bdda+3ASMTP=asap+40reo+2Emts+2Edec+2Ecom+3B@mail.dec.com@PMDF@INTERNET>

Hi,

Please replace the previous mail with this one - there was a slight 
error (company name).

Apologies,
Declan.

Hello -

POINT Log Number	 27618	
Company Name 	Softlab
Engineers name	Herr. Glania	
Telephone Number 		089 9936 1590
Fax Number		
E-mail Address	[email protected]

Operating System, Version	UNIX, V4.0B
Platform			Alpha ?

Problem Statement		

Developing an application on UNIX V4.0B. Uses third degree (part of 
atom) to optimise memory allocation, etc. He runs his executable 
against third degree, and finds that it produces an executable approx. 
twice the size. However, when he runs the new executable, he gets an 
error of the sort:
	cannot map libc.so.third.filename
Any ideas what may be causing this error?




In replying, please use [email protected]





RFC-822-headers:
Received: from reoexc1.reo.dec.com by rg71rw.reo.dec.com (PMDF V5.0-7 #15552)
 id <[email protected]> for [email protected]; Tue,
 06 May 1997 14:41:36 +0100
Received: by reoexc1.reo.dec.com with SMTP
 (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
 id <[email protected]>; Tue, 06 May 1997 14:42:39 +0100
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
T.RTitleUserPersonal
Name
DateLines
3588.1Read the instructionsRDGENG::CHAMBERLINDanger! Do not Reverse PolarityWed May 07 1997 08:0735
Herr Glania,

	The way that atom works is by instrumenting your executable, and (if it
is built using shared libraries), some or all of the shared libraries (.so
files) it uses. Instrumentation involves adding code to the application (and
libraries) to check, for example, memory allocation and usage with the third
degree tool. 	Atom and its tools should only be considered as development
test tools, the code they produce is not intended to be delivered to customers,
because it is larger and slower.

	Which shared libraries are instrumented is requested by use of the -all
or "-incobj <objectname>" flags when you perform the intrumentation run. Even
if no shared libraries are specifically requested, libc will be instrumented by
default to libc.so.third.<filename>.

	The instrumented shared libraries are placed by default in the directory
where atom was run from, or this can be directed using the "-shlibdir
<dirname>" flag. You should be able to see this using the "ls" command.

	When running the "atomised" executable, it is necessary to add the
location of the instrumented shared libraries to the path list pointed to by
the LD_LIBRARY_PATH environment varable , so the run-time loader can find them.
Usually, LD_LIBRARY_PATH is not set by default.

	This is described in the man page for atom, and also the user
documentation (Programmers Guide, Chapter 7). See the loader man page for more
information on LD_LIBRARY_PATH.


regards,


Ian Chamberlin,

Digital Equipment Co, Software Partner Engineering.
3588.2There's always more, sigh.....RDGENG::CHAMBERLINDanger! Do not Reverse PolarityThu May 08 1997 04:330
3588.3RDGENG::CHAMBERLINDanger! Do not Reverse PolarityMon May 19 1997 08:4549
Hello Damian,

	Whilst it is sensible to follow up open calls by mail, it is best to
submit new requests for neww questions, since we are not always in the office,
and mails may not be answered immediately. (I am out all next week).

Regarding your questions,

By moving your atomised library to /usr/shlib you are putting it in the default
loader search path, but you will have to copy it every ime you change it. By
setting LD_LIBRARY_PATH you will add your directory to the loader's search
path, so new versions will automatically be found. For ksh you shoud do
something like
ksh> LD_LIBRARY_PATH=<file_path>
ksh> export LD_LIBRARY_PATH
check that it is set using
ksh> echo $LD_LIBRARY_PATH

I attach the description for the Sytem V Environment product which youy
mentioned. Please see if it does what you need, it does provide Sytem V
compatible commands and libraries.

Unfortunately different suppliers makes seem to be different, so we provide
different ones for compati bility. The one you are using (man 1u make) is an
Ultrix compatibilty one. By all means use it, but be aware that it may retire
in the future. There is also a Posix compatible make (man 1p make), and of
course gnumake is available from the usual sources.

the shell you are using is also a Posix style Bourne shell (man 1p sh)

POsix style commands are supplied for Posix compliance, and you may happily use
them if they work best for you. They are part of the options we offer, to be
compliant with current standards and to provide as much flexibility for users
coming from other systems.

I am not aware of any other awks, except for nawk which is supplied with the
Sytem V option, and there is presumably one available from GNU.

I hope this helps.

regards,

	Ian.




[System V SPD delested]