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
