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. 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.
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). Pete Randall Hopper wrote: > Thanks for the reply. > > |perhaps you could link libAnyDX.so instead of libDXL.a > > I'm not sure what you mean. Could you clarify? > > I verified that I could link in libDX too (along with libDXL) to satisfy > the undefined symbol, but then I also need to link cdf, hdf5, Magick, png, > etc. -- all the libDX dependencies which are just extra baggage and > DX-compilation-specific (I'm packaging a DXL-only Python extension module > here). > > DXL's dependencies, as you mentioned, are just libXt and libc (excepting > _dxfImportBin_FP), which is much simpler to maintain and to have folks > compile for. > > Do you think it makes sense to link the object import code into DXL so DXL > is stand-alone again? > > Randy > > (BTW, I found I couldn't just link with libDXcallm to resolve DXL's missing > symbol because it in-turn leaves DXGetVariable undefined...) > > DXLOutput object parsing > > Peter Daniel Kirchner: > |I think this is just dxlink and samples being out of sync. Of course how to > |bring them into a consistent state is open, awaiting consensus or fiat. At > |some point dxlink was enhanced to allow dx objects to be transferred over > the > |wire, perhaps the dependency comes from there (also, I think an X dependency > |creeps in). If memory serves, the src/uipp/java build gets around this by > |linking everything but src/uipp/dxl/object.o into its native library, > perhaps > |you could link libAnyDX.so instead of libDXL.a > | > |Pete > | > |Randall Hopper wrote: > | > |> DXL apps fail to link (with yesterday's CVS and 4.1.0) using -lDXL. > |> The symbol _dxfImportBin_FP is left undefined. > |> > |> Is this cross-dependency a bug, or is it expected that DXL apps also > |> be linked with libDX or libDXcallm now? This is the only unresolved DX > |> symbol referenced in libDXL, so the former appears more likely. > |> > |> More info: the dxlink samples only link -lDXL, so it appears this > |> cross-dependency was added at some point. And FWIW the unresolved ref is > |> in src/uipp/dxl/object.c:SystemObjectHandler() with the matching > definition > |> in src/exec/libdx/rwobject.c. > > -- > Randall Hopper (mailto:[EMAIL PROTECTED]) > Lockheed Martin Operation Support > EPA Scientific Visualization Center > US EPA MD/24 ERC-1A; RTP, NC 27711
