Good morning, David,
I'm reasonably certain that I'm running the correct
dxexec. Below is the script I'm using to start DX and
as you can see, the -exec parameter is in place.
Further evidence is in the message window; after the
"server: accepted connection from client" line, I get a
series of "ignoring redefinition of module <name>"
lines. I've never liked the appearance of those lines,
let alone the wording, but at least it indicates that
the desired dxexec is getting picked up and the
messages are not new.
#! /bin/csh -f
#
set OTI_DX = ~ned/dx-spin/DX_MODS
dx -edit -macros . -mdf $OTI_DX/OTI_inboard.mdf -exec $OTI_DX/dxexec &
exit
On the broader question; no, I'm not wedded to the use
of inboard modules. I used loadables on the DEC ALPHA
under OSF1 but the last time I visited this question
for linux, sharable modules were not an option. Below
are the linker options that I used for the ALPHA, can
you tell me what the syntax is for linux?
BASE = /usr/lpp/dx
LDFLAGS = -shared -all -e DXEntry -expect_unresolved main
-expect_unresolved DX*
CFLAGS= -O -Dalphax -I$(BASE)/include
LIBS = -lDX -ly -ll -lm -lX11
SYSLIBS = -lm -lc
CC = cc
OTI_loadable: $(OBJ)
$(CC) $(LDFLAGS) $(OBJ) $(SYSLIBS) -o OTI_loadable
Best,
Ned
David Thompson wrote:
>
> Ned,
>
> I'm not sure anybody is compiling inboard modules due to the size of
> the resultant replacement executive. Are you sure that your new
> executive is being used and not the old one? Why use inboards instead
> of loadable modules?
>
> I'll look into the reason that the dxfHWload function is not included.
>
> David
>
> >I am running the latest CVS updates (libtool branch)
> >under Red Hat version 8.0. Many thanks to David
> >Thompson for the clues to make that happen. I am now
> >running into a problem with my user-defined inboard
> >modules. I notice that the top level README caries a
> >note about user defined modules being a known problem.
> >But the date on the file is July 1999; is this
> >relevant?
> >
> >I'm now getting a clean load (except for a message
> >about sys_errlist). Initially there was an unsatisfied
> >external reference called dxfHWload. I suspect that
> >dxfHWload should be coming from libDX.a. I satisfied
> >the reference by forcing the link from the source
> >directory
> >/dx/src/exec/hwrender/opengl/.libs/libOPENGL.a.
> >
> >The user interface is displaying the added module names
> >and configuration dialog boxes (so mdf2c is working).
> >But as soon as I try to use one of the modules I get
> >"<module name>: function does not exist. Operation not
> >implemented". I've been using some of these modules for
> >well over five years so I doubt that there are code
> >problems with _all_ the modules (besides, I'm not even
> >starting to execute the code in my routines). Has a
> >step been added since 4.2.0 to the procedure for
> >linking in modules that I missed? Perhaps the MDF file
> >is missing a new field?
> >
> >Thanks for your time,
> >Ned Piburn
>
> --
> .............................................................................
> David L. Thompson Visualization and Imagery Solutions, Inc.
> mailto:[EMAIL PROTECTED] 5515 Skyway Drive, Missoula, MT 59804
> Phone : (406)756-7472
