Info on IDL v5.4 shareable objects for 64-bit Solaris 8

Subject: Info on IDL v5.4 shareable objects for 64-bit Solaris 8
From: Roger Dejus <dejus@aps.anl.gov>
Date: Mon, 28 Aug 2000 16:29:08 -0500

This is a multi-part message in MIME format.
--------------705BDD4F135B68141ACC2138
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

To all, the enclosed information (and example programs) will be useful
if you are developing shareable objects for IDL v5.4 for the Sun 64-bit
Solaris 8 operating system. (The IDL v5.4 is still in beta testing.)

Regards, Roger Dejus (dejus@aps.anl.gov).



--------------705BDD4F135B68141ACC2138
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Received: from epics.aps.anl.gov (mailhost [164.54.8.141])
	by oxygen.aps1.anl.gov (8.8.8+Sun/8.8.8) with ESMTP id SAA06692
	for <dejus@oxygen.aps1.anl.gov>; Thu, 24 Aug 2000 18:31:16 -0500 (CDT)
Received: from iota.aps.anl.gov (iota [164.54.56.65])
	by epics.aps.anl.gov (8.8.8+Sun/8.8.8) with ESMTP id SAA01800
	for <dejus@aps.anl.gov>; Thu, 24 Aug 2000 18:31:15 -0500 (CDT)
Received: by iota.aps.anl.gov; id SAA04710; Thu, 24 Aug 2000 18:31:14 -0500 (CDT)
Received: from mailgate.rsinc.com(192.5.156.11) by iota.aps.anl.gov via smap (V5.5)
	id xma004628; Thu, 24 Aug 00 23:30:50 GMT
Received: from cliff.corp.rsinc.com (cliff.corp.rsinc.com [10.17.1.4])
	by crow.rsinc.com (8.9.3/8.9.3) with ESMTP id RAA92164
	for <dejus@aps.anl.gov>; Thu, 24 Aug 2000 17:30:49 -0600 (MDT)
Received: from atlas.corp.rsinc.com (atlas.corp.rsinc.com [10.17.1.11])
	by cliff.corp.rsinc.com (8.9.3/8.9.3) with ESMTP id RAA22424
	for <dejus@aps.anl.gov>; Thu, 24 Aug 2000 17:30:49 -0600 (MDT)
Received: by atlas.corp.rsinc.com with Internet Mail Service (5.5.2650.21)
	id <RB4FK1W6>; Thu, 24 Aug 2000 17:31:11 -0600
Message-ID: <20D1AB0E9EBDD311809900902789D31B209BE0@atlas.corp.rsinc.com>
From: RSI E-mail Support <support@rsinc.com>
To: ''dejus@aps.anl.gov'' <dejus@aps.anl.gov>
Subject: Re: Shareable object not loaded
Date: Thu, 24 Aug 2000 17:31:10 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary='----_=_NextPart_000_01C00E23.62CB8284'
X-Mozilla-Status2: 00000000

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C00E23.62CB8284
Content-Type: text/plain

Hi Roger,

It turns out that the problem loading a sharable object library with 64-bit
IDL is a documentation problem.

Sixty-four bit IDL on Solaris is built with certain compiler and linker
options, requiring sharable object libraries to be built with the same
options, if they are to be compatible with 64-bit IDL.

The additional options are

  -xtarget=ultra -xarch=v9

for both the C compiler and the linker.

Actually, these options can be found in the makefile provided in the
call_external/C subdirectory of the IDL 5.4b1 installation tree, but this is
a rather obscure place for them. They should have been added to the
callext_unix.txt file, at the very least, and should have been listed in the
IDL 5.4b1 Release Notes.

I have included a simple example that you can use as a guide for building
your sharable object libraries for 64-bit IDL on Solaris.

Now, with the 64-bit architectures, it is even more important to use the
typedef symbols for IDL data types (defined in export.h), rather than coding
C routines to use intrinsic C data types. For example, if a CALL_EXTERNAL
argument is IDL type LONG (32-bit), the C routine should use IDL_LONG,
rather than 'int' or 'long,' for the corresponding C declaration that will
reference that argument.

When the above compiler options are used, the C compiler generates 64-bit
integers for the 'long' data type; the C 'long' data type no longer matches
the IDL LONG data type in 64-bit mode.


 <<testext.c>>  <<testext.pro>>  <<testext_sol.mak>> 

I built and ran (with 64-bit IDL) the above example on a Solaris 7 and a
Solaris 8 system. It works perfectly on both systems.

Briefly, with the above compiler and linker options, the following C data
types have the indicated sizes:

  int           4 bytes
  long         8 bytes
  pointers    8 bytes

For details on the new 64-bit Sun systems, see the Sun Microsystems
SunWorkshop 5.0 Users Guide.

Let me know if you have any questions or problems building your sharable
object libraries for 64-bit IDL.

Thanks!


Doug Loucks
Technical Support Engineer
Research Systems Incorporated
Phone: (303)413-3920, Ext 407
FAX: (303)786-9909
Email: support@rsinc.com
Please include my name on the Subject line of email replies. Thanks!




------_=_NextPart_000_01C00E23.62CB8284
Content-Type: application/octet-stream;
	name='testext.c'
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename='testext.c'

#include <stdio.h>=0A=
#include 'export.h'=0A=
=0A=
#ifdef WIN32=0A=
#include <windows.h>=0A=
#define IDL_LONG_RETURN __declspec(dllexport) IDL_LONG=0A=
#else=0A=
#define IDL_LONG_RETURN IDL_LONG=0A=
#endif=0A=
=0A=
/* Since the size and shape of the IDL array are known at compile=0A=
time, we can declare a typedef here. Note that the C dimensions=0A=
are in the reverse order from IDL. */=0A=
=0A=
typedef IDL_LONG (idl_3_640_480_t)[480][640][3];=0A=
=0A=
IDL_LONG_RETURN testext(int argc, void *argv[]) {=0A=
  IDL_LONG a, b, c;=0A=
=0A=
  /* Declare a pointer variable to the C version of the IDL 3D array. =
*/=0A=
  idl_3_640_480_t *idl3darray; =0A=
=0A=
  /* IDL CALL_EXTERNAL passes a pointer to the array in argv[0] */=0A=
  idl3darray =3D argv[0];=0A=
=0A=
  a =3D *(IDL_LONG *) argv[1];=0A=
  b =3D *(IDL_LONG *) argv[2];=0A=
  c =3D *(IDL_LONG *) argv[3];=0A=
=0A=
  /* Put a number into the specified element of the IDL array. */=0A=
  (*idl3darray)[c][b][a] =3D -77;=0A=
=0A=
  return 0;=0A=
} /* End testext */=0A=

------_=_NextPart_000_01C00E23.62CB8284
Content-Type: application/octet-stream;
	name='testext.pro'
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename='testext.pro'

PRO testext=0A=
  a =3D 1L=0A=
  b =3D 413L=0A=
  c =3D 311L=0A=
=0A=
  tmp =3D strcompress(string(a,b,c, format=3D'(i0,',',i0,',',i0)'), =
/remove_all)=0A=
=0A=
  testarray =3D LONARR(3, 640, 480)=0A=
=0A=
; Put something into a particular element of the array.=0A=
  testarray[a, b, c] =3D 13=0A=
=0A=
  print, 'Before CALL_EXTERNAL, testarray['+ tmp +'] is'=0A=
  print, testarray[a, b, c]=0A=
=0A=
  status =3D CALL_EXTERNAL('testext.so', 'testext', testarray, a, b, =
c)=0A=
; status =3D CALL_EXTERNAL('testext.dll', 'testext', testarray, a, b, =
c)=0A=
=0A=
; Show that the value of the specific array element was changed in =
the=0A=
; C routine.=0A=
  print=0A=
  print, 'After CALL_EXTERNAL, testarray['+ tmp +'] is'=0A=
  print, testarray[a, b, c]=0A=
END=0A=

------_=_NextPart_000_01C00E23.62CB8284
Content-Type: application/octet-stream;
	name='testext_sol.mak'
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename='testext_sol.mak'

#IDL_DIR =3D /usr/local/rsi/idl_5.2=0A=
=0A=
MODULE =3D testext=0A=
=0A=
CFLAGS =3D -I$(IDL_DIR)/external -Kpic -G -xtarget=3Dultra -xarch=3Dv9 =
=0A=
#CFLAGS =3D -I$(IDL_DIR)/external -Kpic -G=0A=
=0A=
LD =3D cc=0A=
LD_FLAGS =3D -G -xtarget=3Dultra -xarch=3Dv9 =0A=
#LD_FLAGS =3D -G=0A=
=0A=
SO_EXT =3D so=0A=
=0A=
libs : $(MODULE).$(SO_EXT)=0A=
=0A=
$(MODULE).$(SO_EXT): $(MODULE).o=0A=
	$(LD) $(LD_FLAGS) -o $(MODULE).$(SO_EXT) $(MODULE).o=0A=
=0A=
$(MODULE).o : $(MODULE).c=0A=
	$(CC) $(CFLAGS) -c $(MODULE).c=0A=
=0A=
clean:=0A=
	rm *.o *.so=0A=

------_=_NextPart_000_01C00E23.62CB8284--


--------------705BDD4F135B68141ACC2138--
Prev by Date: mcaApp
Next by Date: NeXus'2001 Workshop, March 20-21, 2001, PSI, Switzerland
Index(es):
- Date