Peter D. Kirchner:
|Hi Randy,
|
|I meant simply the expediency that if you also built the uipp/java tree, you
could
|link the equivalent of libDXL.a that skipped the DX Object dependencies.
Oh, I see what you mean now. There literally is a libAnyDX.so built
there. I thought your .so name was just "hypothetically speaking".
Linking with this library instead of DXL for the DXL interface works --
thanks. A bit of a hack though for my problem (not linking with DXL
directly, that is).
|I needed a shared lib, not an ar-built archive, so I haven't investigated
|how far the object.o dependencies reach. Certainly if they don't reach
|far adding those pieces to the dxlink lib is a great suggestion. JNI
|needs a shared lib... building DXL both static and shared would work then
|for your, my, and legacy purposes.
Python too needs a shared lib for dynamic loading of the module, so that's
what I've been working on. It's been revealing these few cross-library
dependency breakages that have crept up on us over time.
I think if, as you suggest, we built .a's and .so's for the DX libs, and
also linked trivial test progs in the DX build, that would prevent these
cross-dependencies from creeping in. The build would fail when a symbol
was added incorrectly.
And with the cross-dependencies fixed, we could both (or at least I could)
just link our .so's with libDXL, since it would work.
|Did you look at libDXlite? I believe that has the data model code without
all the
|rest (I really doubt it would pull in Magick as a dependency).
It would have worked (and I'd prefer it to AnyDX since it's a .a) but it
in-turn leaves DXReadyToRunNoExecute undefined.
I added a stub to outglue.c, which fixes the problem (attached) ...but that
causes this symbol to be defined twice in libDXcallm (in cmoutglue.o --
presumably cooked on-the-fly when building the DXcallm lib).
I'm not familiar with how DX scavanges for .o's, so I don't know the best
place for this patch to go. And with no docs on this function anywhere I
can find, I don't even know if my stub is correct. The question rests on
whether an outboard module should send a message to the exec when
"ReadyToRunNoExecute", and what that message should be (No message? Same
as ReadyToRun? Other?). I don't know.
--
Randall Hopper (mailto:[EMAIL PROTECTED])
Lockheed Martin Operation Support
EPA Scientific Visualization Center
US EPA MD/24 ERC-1A; RTP, NC 27711
--- src/exec/libdx/ORIG/outglue.c Mon Jun 12 01:45:35 2000
+++ src/exec/libdx/outglue.c Fri Jan 19 12:14:10 2001
@@ -823,6 +823,11 @@
return OK;
}
+Error DXReadyToRunNoExecute(Pointer id)
+{
+ return OK;
+}
+
/* private version */
static Error DXInternalReadyToRun()
{
