| Title: | VAX and Alpha VMS |
| Notice: | This is a new VMSnotes, please read note 2.1 |
| Moderator: | VAXAXP::BERNARDO |
| Created: | Wed Jan 22 1997 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 703 |
| Total number of notes: | 3722 |
Hello,
A cust is seeing problems with the linker which wasn't happening on
previous version of his OpenVMS. Can anyone shed some light as to
why this is happening and if there is anything which can be done to
work around this.....
I am comparing OpenVMS 7.1 on VAX with OpenVMS 6.1 on VAX. I believe I
had the problem on 7.0 and that it is not on 6.2 but I am not in a
position to reproduce those easily.
I have just completely rebuilt the two development areas, so that all
command and option files are identical.
In its simplest form, a link of an .EXE that works fine on 6.1 produces
the following error on 7.1 :-
%LINK-E-CONFBASADR, conflicting base address for image SORTSHR
base of %X000C5400 in file SYS$COMMON:[SYSLIB]ADLIBSHR.EXE;78
conflicts with base of %X000B8A00 in file
SYS$COMMON:[SYSLIB]ADLIBSHR.EXE;78
%LINK-E-NOIMGFIL, image file not created
%LINK-E-CONFBASADR, conflicting base address for image LIBRTL2
base of %X000CBC00 in file SYS$COMMON:[SYSLIB]ADLIBSHR.EXE;78
conflicts with base of %X000C3800 in file
SYS$COMMON:[SYSLIB]ADLIBSHR.EXE;78
%LINK-E-INSVIRMEM, insufficient virtual memory for 104. pages
for cluster SORTSHR
%LINK-E-INSVIRMEM, insufficient virtual memory for 68. pages
for cluster LIBRTL2
The relevant part of the two maps are:-
Cluster Type Pages Base Addr Disk VBN PFC Protection and
Paging Global Sec. Name Match Majorid Minorid
------- ---- ----- --------- -------- ---
--------------------- ---------------- ----- ------- -------
ADLIBSHR 2 1253 00000000 3 0 READ WRITE COPY
ON REF ADLIBSHR_001 EQUAL 63 5692694
4 50 0009CA00 1256 0 READ WRITE COPY
ON REF ADLIBSHR_002 EQUAL 63 5692694
3 86 000A2E00 1306 0 READ ONLY
ADLIBSHR_003 EQUAL 63 5692694
4 1 P-000ADA00 1392 0 READ WRITE COPY
ON REF ADLIBSHR_004 EQUAL 63 5692694
LIBRTL 3 264 000ADC00 2 0 READ ONLY
LIBRTL_001 LESS/EQUAL 1 14
4 15 000CEC00 0 0 READ WRITE DEMAND
ZERO LIBRTL_002 LESS/EQUAL 1 14
SORTSHR 3 101 000B8A00 2 0 READ ONLY
SORTSHR_001 LESS/EQUAL 2 29
4 1 000C5400 103 0 READ WRITE COPY
ON REF SORTSHR_002 LESS/EQUAL 2 29
4 1 P-000C5600 104 0 READ WRITE COPY
ON REF SORTSHR_003 LESS/EQUAL 2 29
2 1 000C5800 105 0 READ WRITE FIXUP
VECTORS SORTSHR_004 LESS/EQUAL 2 29
LIBRTL2 3 66 000C3800 2 0 READ ONLY
LIBRTL2_001 LESS/EQUAL 1 12
4 1 000CBC00 68 0 READ WRITE COPY
ON REF LIBRTL2_002 LESS/EQUAL 1 12
2 1 000CBE00 69 0 READ WRITE FIXUP
VECTORS LIBRTL2_003 LESS/EQUAL 1 12
and
Cluster Type Pages Base Addr Disk VBN PFC Protection and
Paging Global Sec. Name Match Majorid Minorid
------- ---- ----- --------- -------- ---
--------------------- ---------------- ----- ------- -------
ADLIBSHR 2 1253 00000000 0 0 READ WRITE COPY
ON REF ADLIBSHR_001 EQUAL 63 5657749
4 50 0009CA00 0 0 READ WRITE COPY
ON REF ADLIBSHR_002 EQUAL 63 5657749
3 86 000A2E00 0 0 READ ONLY
ADLIBSHR_003 EQUAL 63 5657749
4 1 P-000ADA00 0 0 READ WRITE COPY
ON REF ADLIBSHR_004 EQUAL 63 5657749
LIBRTL 3 241 000ADC00 0 0 READ ONLY
LIBRTL_001 LESS/EQUAL 1 14
4 15 000CBE00 0 0 READ WRITE DEMAND
ZERO LIBRTL_002 LESS/EQUAL 1 14
3 1 000CDC00 0 0 READ ONLY
LIBRTL_003 LESS/EQUAL 1 14
SORTSHR 3 101 000CDE00 0 0 READ ONLY
SORTSHR_001 LESS/EQUAL 2 29
4 1 000DA800 0 0 READ WRITE COPY
ON REF SORTSHR_002 LESS/EQUAL 2 29
4 1 P-000DAA00 0 0 READ WRITE COPY
ON REF SORTSHR_003 LESS/EQUAL 2 29
2 1 000DAC00 0 0 READ WRITE FIXUP
VECTORS SORTSHR_004 LESS/EQUAL 2 29
LIBRTL2 3 64 000DAE00 0 0 READ ONLY
LIBRTL2_001 LESS/EQUAL 1 12
4 1 000E2E00 0 0 READ WRITE COPY
ON REF LIBRTL2_002 LESS/EQUAL 1 12
2 1 000E3000 0 0 READ WRITE FIXUP
VECTORS LIBRTL2_003 LESS/EQUAL 1 12
DEFAULT_CLUSTER 0 270 000E3200 3 0 READ ONLY
Note that SORTSHR in the bad one chooses to base itself halfway up LIBRTL
instead of behind it!
I tried various permutations of LINK parameters before I contacted you.
Recently, I tried heavily modifying the application to be not based, but
I have finally had to give that up, as one particular PSECT must be based
at low memory for the application to run properly. I could make those
changes again if it helped, but I now believe the answer must be simpler
than that.
I have another application that similarly requires to be based, but this
time the shareable module doesn't need to, it can be the one that links
to it. Interestingly, in this case, two things are different in the map.
The LINKER pulls in LBRSHR, and SORTSHR does not get given a base
address.
Cluster Type Pages Base Addr Disk VBN PFC Protection and
Paging Global Sec. Name Match Majorid Minorid
------- ---- ----- --------- -------- ---
--------------------- ---------------- ----- ------- -------
LIBRTL 3 264 00000000-R 0 0 READ ONLY
LIBRTL_001 LESS/EQUAL 1 14
4 15 00021000-R 0 0 READ WRITE DEMAND
ZERO LIBRTL_002 LESS/EQUAL 1 14
LBRSHR 1 1 00000000-R 0 0 READ ONLY
LBRSHR_001 LESS/EQUAL 2 9
2 3 00000200-R 0 0 READ WRITE COPY
ON REF LBRSHR_002 LESS/EQUAL 2 9
2 60 00000800-R 0 0 READ ONLY
LBRSHR_003 LESS/EQUAL 2 9
2 1 00008000-R 0 0 READ WRITE FIXUP
VECTORS LBRSHR_004 LESS/EQUAL 2 9
SORTSHR 3 101 00000000-R 0 0 READ ONLY
SORTSHR_001 LESS/EQUAL 2 29
4 1 0000CA00-R 0 0 READ WRITE COPY
ON REF SORTSHR_002 LESS/EQUAL 2 29
4 1 P-0000CC00-R 0 0 READ WRITE COPY
ON REF SORTSHR_003 LESS/EQUAL 2 29
2 1 0000CE00-R 0 0 READ WRITE FIXUP
VECTORS SORTSHR_004 LESS/EQUAL 2 29
LIBRTL2 3 66 00000000-R 0 0 READ ONLY
LIBRTL2_001 LESS/EQUAL 1 12
4 1 00008400-R 0 0 READ WRITE COPY
ON REF LIBRTL2_002 LESS/EQUAL 1 12
----------
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 592.1 | Linker command and options file .. | KERNEL::SMITH | Wed May 14 1997 08:46 | 44 | |
For the shareable image... LINK ADLIBshr/share/NOTRACEBACK/MAP/FULL/CROSS/OPT - ,sys$system:sys.stb/select- ,sys$system:rmsdef.stb/sel- ,sys$input/opt with ADLIBSHR.OPT looking like this... base=0 cluster=adlib_imp0_data,0,,adlib/include=(adlib_data,adlib_rmsd) cluster=adlib_pure_inst,,,adlib/include=- (adlib_adlt,adlib_boot,adlib_cras,adlib_erro,adlib_init,adlib_stop,adlib_w ait,- adlib_astm,adlib_acti,adlib_comp,adlib_core,adlib_disp,adlib_edit,adlib_fo rm,- adlib_geto,adlib_goto,adlib_inpu,adlib_inte,adlib_letu,adlib_move,adlib_pa ck,- adlib_subr,adlib_symb,adlib_tran,adlib_upac,adlib_util,adlib_zero,- adlib_prin,adlib_alph,adlib_sort,adlib_utix,adlib_mbco,adlib_mbca,adlib_mb tg,- adlib_mbtb,adlib_mbtj,adlib_mbtr,adlib_unco,adlib_vist,- adlib_vist1,adlib_vist2,adlib_vist3,adlib_msg) ! universal=adlib_ab_flag universal=adlib_acti_0 universal=adlib_acti_1 universal=adlib_adlt_c universal=adlib_adlt_d universal=adlib_adlt_e universal=adlib_adlt_e etc. And for the executable image... LINK/MAP/full/notraceback addemo/EXECUTEABLE=addemo,adtemp/OPTIONS with ADTEMP.OPT looking like this... CLUSTER=VISTA_SHARE,,,SYS$SHARE:ADLIBshr/SHARE ---------- | |||||
| 592.2 | More Info On ADLIBSHR Needed | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Wed May 14 1997 10:39 | 12 |
I'd expect this from a based shareable image such as ADLIBSHR -- recreate this image as position independent. Failure to do so will provoke this same sort of "fun" after various OpenVMS ECO kits, and after various OpenVMS upgrades -- position-dependent (based; NOPIC) code is bad news. What we need are the link maps from ADLIBSHR, and more details around the design of that image, and information on whether or not this image can be "broken up" into position-independent code and a COMMON (which will be position dependent) or (better) a global section. And on what problem(s) the customer was encountering when attempting to remove the position-dependence. | |||||
| 592.3 | maps and cust reply ... | KERNEL::SMITH | Wed May 14 1997 13:43 | 41 | |
Hi, THanks for your reply, I have the maps, unfortunately they are
extensive and the cust reply was less than favourable. Would you like
them posted in a reply or mailed/copied somewhere ...
many thanks
ewan
====================================================================
cust reply :-
I appreciate that if I re-design the application to be
position-independent the problem will go away. Unfortunately I have
customers out there who might go VMS 7 before I get around to doing
that.
You (Digital) have changed something in the LINKER, or SORTSHR, or
LIBRTL
to make it go wrong. If you can't narrow it down to something I can
bypass, then I'll just have to abandon this product from the market,
and
blame Digital!
Here are the maps...
[[ ADLIBSHR.V61 : 3644 in ADLIBSHR.V61 ]][[ ADLIBSHR.V71 : 3645 in
ADLIBSHR.V71 ]]
Adlib is a report generator, and the application .EXEs that link to
adlibshr 'know' about certain areas in low memory. The product is
based
(no pun) on another product of ours that has been around since PDP
days,
and still survives using this technique. I have successfully ported it
to ALPHA, so I know that the problem is not insoluble, but frankly the
income from adlib doesn't justify the work involved.
PS. The above information is price-sensitive, and therefore
CONFIDENTIAL.
| |||||
| 592.4 | CSC64::BLAYLOCK | If at first you doubt,doubt again. | Thu May 15 1997 15:39 | 18 | |
The next experiments are then to On V7.1, use the V6.1/2 linker. Does the problem go away? If it does, the issue is highly likely a change in the linker. This also gives you a work around. If the link still fails, on V7.1 use a copy of the V6.1 SORTSHR (or LIBRTL). Does the issue go away? If so, then the change is with the SORTSHR image. If it is a conflict with the sharables on V7.1, just link against the V6.1 OpenVMS sharables. Between 6.1 and 7.1, the virtual address size of SORTSHR did not change (104 pages). For LIBRTL it went from 257 pages to 279 pages which makes a big difference to a based image. Oracle has/had this problem for over a decade because of their based images. Other than having his customers use the V6 LIBRTL images on V7 (private copies), then he will see a problem with a base image with every increase in size of the shareable images that it touches. | |||||
| 592.5 | undefined symbol AMAC_FLT_V | KERNEL::SMITH | Tue Jun 03 1997 12:34 | 24 | |
Many thanks for your replies, the cust will persevere with this and
in the meantime could someone pls comment on the following.
One of their applications, has been rebuilt, but when the libraries are
shipped to a customer running VMS 6.2 the re-link on site gives the
following error:
Undefined symbol AMAC_FLT_V referenced in PSECT ...
According to the map on VMS 7.1 this symbol is in module AMAC_FLT_DATA.MAR
which comes from SYS$SHARE:STARLET.OLB. The symbol is not in the VMS 6.2
STARLET.
This technique used to ship their products has worked for the last 15
years. Is there anything he can do to allow them to continue to support
earlier VMS systems?
My understanding is that we don't or won't support backward
compatibility between VMS versions. Is this the case. PLease correct me
if I'm wrong.
Many thanks,
Ewan Smith - UK CSC
| |||||
| 592.6 | /trace prevents calling AMAC_FLT_ | KERNEL::SMITH | Wed Jun 04 1997 08:45 | 9 | |
In the meantime, he has discovered that he can stop the linker calling
in the AMAC_FLT_ routines by adding /trace to the link command.
Unfortunately, that prevents him installing the image with privileges
which he needs for this application.
Is there any other of getting around this.
regards
ewan
| |||||
| 592.7 | CSC64::BLAYLOCK | If at first you doubt,doubt again. | Wed Jun 04 1997 12:52 | 11 | |
The base note describes a shareable image. Shareable images cannot use the /privileges defined with install, so there is no need to use this qualifier and thus the traceback information is not relavent. I would look at the maps generated by the two link operations to see where the AMAC_FLT_* reference is coming from. That is, with /CROSS_REF in the link, what is referencing this symbol that it is brought in. Backwards compatiblity has never been a goal for OpenVMS, so if you are building on V7 for V6 customers, you must use V6 libraries and shareable images. | |||||