topic Re: GNV ar in Operating System - OpenVMS

GNV ar

ciju john — Fri, 28 Oct 2005 12:01:20 GMT

Hi all,

bash$ uname -a
OpenVMS VMS 0 V8.2 AlphaServer_ES40 Alpha

bash$ cc --version
GNV Nov 24 2004 10:09:12
Compaq C V6.5-001 on OpenVMS Alpha V8.2

I am porting a U*X library to OpenVMS and see the following problem with the GNV "ar". When trying to link my test program I get the following:

%LINK-I-UDFSYM, int ACE_ARGV::add(const char *)
%LINK-I-UDFSYM, ACE_ARGV::ACE_ARGV(int)
%LINK-I-UDFSYM, ACE_ARGV::~ACE_ARGV()

These are symbols which ar should have put in my library. However "lib /name/list" shows otherwise. The library pulls in stuff from over 150+ object files. I created a dummy library using just the file which contains the above symbols

% echo .obj/ARGV.o | xargs ar c libACE2.a

and sure enough "lib /name/list" lists them. Now my question is whats the difference between archiving one object file vs. 150+ object files. Is 'ar' doing anything special that results in the ARGV.o symbols being chopped out.

I am sorry for the rather windy description. Ping me back if more info is needed. My problem is that I don't understand the GNV ar and the underlying OpenVMS LIBRARY utilities enough to postulate why some symbols in some scenarios are being wipped out.

Appreciate any help...

Ciju

Re: GNV ar

Bojan Nemec — Fri, 28 Oct 2005 13:39:56 GMT

Ciju,

I am not much familiar with GNV. As I have read GNV ar is only a wraper around the VMS LIBRARY command. Are there any errors signaled by ar?

I suggest you to build the library with all 150+ object files and leave out ARGV.o. Then try to insert the ARGV.o from the DCL prompt:

$ LIBRARY/INSERT/OBJECT LIBACE2.a ARGV.o

and see if this command reports any error or warning like %LIBRAR-W-DUPMODULE or %LIBRAR-E-DUPGLOBAL.

Bojan

Re: GNV ar

Steven Schweda — Fri, 28 Oct 2005 14:35:15 GMT

Are you offering any clues as to the "ar"
command(s) used?

If you do a LIBR /LIST on the library, what's
special about the missing modules/symbols,
compared with the stuff which made it into the
library?

If there was a single long "ar" command, it's
conceivable that it became a too-long LIBR
command, and that the items at the end got
lost. (But I've never tried any of this, so
what do I know?)

Re: GNV ar

Arch_Muthiah — Fri, 28 Oct 2005 18:36:43 GMT

Ciju,

Afaik, ar program is used to insert/replace the objects into the object lib (OLB). These OLB (150+objects files) will be linked while creating images. The above error may be because your ar program misses to add these obj files (member) into your object lib as part of GNV-make processing.

GNV-make will search for any changes (new versions) with all the sources, header files, obj's and exe's used inside the makefiles. If there is any change with any source, GNV make look for a "compile rule", so
1. we have to add a "compile rule". and
2. next we have to add another "ar rule" to create/replace this (three) new objects to your object library.

I guess your GNV-make build procedure missing three "ar" rules inside your makefile procedures. Try adding this ar rule and create the new image and run. let see.

Archunan

Re: GNV ar

John Gillings — Mon, 31 Oct 2005 22:07:20 GMT

Ciju,

Since I can't see your LINK command I can only guess...

If you LINK against multiple libraries, remember that they're processed strictly left to right. Each library is scanned multiple times, until there is a pass through the library which doesn't resolve any new symbols. Consider:

$ LINK PROG,LIB1/LIB,LIB2/LIB

Now, suppose LIB1 contains symbol Z which is not referenced from PROG, but IS referenced from routine A in LIB2, which is referenced from PROG. The linker will search LIB1 and resolve anything it can find. It will then resolve A from LIB2 and discover it needs Z. However, since we've finished with LIB1, it won't be searched again.

So, we fail to find a symbol that is present in the link list.

If we were to combine all the modules in a single library, all symbols would be resolved correctly because Z is still visible at the time the linker realises it's referenced.

In general libraries should be ordered from "high level" to "low level", left to right. If it's not possible to break a circularity, specifying the same library twice might help. For example:

$ LINK PROG,LIB1/LIB,LIB2/LIB,LIB1/LIB

or, if you know what symbols are required, include them explicitly:

$ LINK PROG,LIB1/LIB/INCLUDE=Z,LIB2/LIB