linking for unit test?

[Scott Mark]

This is in the C language, OpenVMS on an Alpha.
I'm trying to unit-test some code. I've written a driver harness that calls a function-under-test (FUT). It also includes "dummy" versions of the functions that the FUT calls.

I'd like to create my driver.c with one unresolved symbol, the FUT, and then link with the actual .OBJ file to bring in that one function. I'd be willing to do it with a library.

But I'm running into problems with the linker bringing in ALL functions from the .OBJ file. The software seems to work, but I get a lot of duplicate- and undefined-symbol warnings.

Perhaps this is not possible. I read the Shareable Image Cookbook, and I got the impression that it simply isn't possible to have a routine in a .OBJ file link back to routines in the driver.c file.

I'm not tied to the idea of using a .OBJ or .LIB file if there's another way to do this.

I know I can cut and paste the source code, but ick.

Many thanks for any ideas.

[Hein van den Heuvel]

Have you checked out and/or experimented with the /SELECTIVE_SEARCH link switch?

Hein.

[Scott Mark]

Yes, I have tried the /selective_search option, both with the .OBJ file and with the .OBL (/lib/selective_search) file.

Neither one had any positive impact. It's as if the linker pulls in the entire module if it has to pull in anything. And on the one hand, that makes perfect sense, so you can do internal name resolution within the .OBJ file in the average case.

This is an unusual circumstance, where I want to "pull" a function out of its compile-time context.

Scott

[Joseph Huber_1 · Accepted solution]

You probably have put all those functions/procedures in ONE C source file ?
Then it always is linked completely if only one reference is resolved from that object file.
To get them selective, separate them into individual source -> object files.
(The fortran compiler has a nice option switch /SEPARATE, which produces separate object units in a library from a single source file.
The C compiler hasn't this capability).

[Robert Gezelter]

Scott,

This is a normal and reasonable need. I have done this many times, both internally and externally.

The key is separating the test environment into three components:
- the root level of the driver
- the all components shareable library
- the module under test linked into the form of a shareable library.

Done this way, the "call back" into the calling image is eliminated. The image activator will resolve the cross ties between the three different images at time that the image is activated.

This is one of the fundamental technologies mentioned in my series of DECUS presentations on shareable libraries, some of which are:
OpenVMS Shareable Libraries: An Implementor's Guide at http://www.rlgsc.com/cets/2000/460.html and my presentation on "Programming by Chinese Menu" (which I have not yet found the time to load on my www site).

I hope that the above is helpful. If I have been unclear, or can be of further assistance, please let me know.

- Bob Gezelter, http://www.rlgsc.com

[Scott Mark]

It looks like I was using the sharable libraries concept completely wrong.

Robert- thanks for the presentation. I'm going to try (and hope) that I can put the transfer vectors in a separate file, so that I can leave the source file untouched.

The link for the .pdf file worked. The links for the example source code do not. I know it sounds whiny, but there are so many details I could get wrong that I'd really appreciate seeing a working (alpha) example.

And thanks to everyone. Turns out that your advice has probably been right- I just haven't known how to use it.

Scott