custom transform routine - undefined symbol

Post questions here relative to DataStage Enterprise/PX Edition for such areas as Parallel job design, Parallel datasets, BuildOps, Wrappers, etc.

Moderators: chulett, rschirm, roy

Post Reply
asorrell
Posts: 1707
Joined: Fri Apr 04, 2003 2:00 pm
Location: Colleyville, Texas

custom transform routine - undefined symbol

Post by asorrell »

We're working on a custom transformer routine that calls a custom C++ function. The C++ function has been compiled with the same compiler options as DataStage.

We've got the lib path in the LD_LIBRARY_PATH, and in also put in the source and include paths just in case.

The DataStage job fails at runtime with:

Code: Select all

Error when checking composite operator: Failed to load the library "V0S130_TestJob_xfm_Protect.so"; 
either the directory containing the library file is not on the library search path, or the library was compiled on a system that is incompatible with this system: 
Could not load "V0S130_TestJob_xfm_Protect": 
/InformationServer/Server/Projects/EDW2020_DEV/RT_BP9555.O/V0S130_TestJob_xfm_Protect.so: undefined symbol: ProtectParamsDefaults_v1.
ProtectParamsDefaults_v1 is defined in one of the include files that is correctly referenced in our C++ program.

We are puzzled as to why the transformer won't compile, saying it can't find that symbol.

Any thoughts?
Andy Sorrell
Certified DataStage Consultant
IBM Analytics Champion 2009 - 2020
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

Did you ever figure this out? I couldn't think of anything sensible to contribute, except maybe moving the components into RT_SCnnnn directory.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
asorrell
Posts: 1707
Joined: Fri Apr 04, 2003 2:00 pm
Location: Colleyville, Texas

Post by asorrell »

The error was misleading. We had several problems that apparently combined to confuse the situation.

The C routine had arguments that were unsigned char* and the parallel routine definition only supported char*. The same mismatch occurred for the return value. We used casting in the C routine to switch the data type to a supported value (char*).

We also added "-shared" to the compile / link options for the C routine.

With those done, the routine started working. It is orders of magnitude faster than the Java version we were using.
Andy Sorrell
Certified DataStage Consultant
IBM Analytics Champion 2009 - 2020
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

I feel that an enhancement request is in the offing.

There is no good reason not to support unsigned char* (there are many of them out there). And the parallel routine definition is not much more than a mechanism for checking arguments.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Post Reply