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
