David Thompson:
|What about rewriting a _dxfImportBin_FP function just for DXL that
|would not be dependent on all the other code in libdx. I think it
|might be possible without too much trouble but I haven't dug really
|deep into it. This is the function that is causing the hub-bub. It
|seems that it would make sense that since DXL gives one a way to talk
|with the executive that it should be fairly independent of the dx
|internals.
|
|Greg and Randall, let me know what you think. If you think it is a
|good idea I will look at trying to implement it tomorrow.
Well, I'd suggest not writing any code that duplicates functionality
(eventually, it bites back). Moving or linking functionality would be
better.
Linking libDXlite.so with libDXL.so as a transitive dependency would be the
simplest solution, ...except libDXlite in-turn leaves DXReadyToRunNoExecute
undefined (been there, done that). libDXcallm and libDX define it.
Considering libDXcallm, it leaves another set of symbols undefined (some 9
or more), so I'm not at all confident that that's the solution.
And linking the full libDX or libDXcallm for that matter to libDXL (which
is what I've done in the past) is a real waste of space:
-rw-r--r-- 1 root sys 205412 May 22 07:09 libDXL.a
-rw-r--r-- 1 root sys 1332372 May 22 07:08 libDXlite.a
-rw-r--r-- 1 root sys 12353988 May 22 07:09 libDXcallm.a
-rw-r--r-- 1 root sys 13215524 May 22 07:09 libDX.a
Some possibilities:
1) Pull the DXlite and DXL common code into separate .o's and either link
them into both libs, or put them a third library that is linked with
both DXLite and DXL (the former if DXlite and DXL shouldn't ever be
linked into the same app; the latter if not).
2) Make DXlite stand-alone (i.e. fix DXReadyToRunNoExecute), and
have DXL linked with with DXlite.
Randy
--
Randall Hopper (mailto:[EMAIL PROTECTED])
Lockheed Martin Operation Support
EPA Scientific Visualization Center
US EPA N127-01; RTP, NC 27711
