Unsolved
This post is more than 5 years old
4 Posts
0
2761
August 21st, 2009 13:00
SDK 3.2 unresolved symbols problem on Solaris 10
Any attempt to compile on Solaris 10 with the most recent SDK 3.2 will result in a list of unresolved symbols.
I tried my own code as well as several samples included in SKD.
compilation with CC will work file. Unfortunately I have to use c compiler and no c++. According to release notes c compiler should work fine. Using c compiler I will end up with:
cc -mt -DPOSIX -I/opt/Centera_SDK/include -L/opt/Centera_SDK/lib/32 BackupContent.c -lFPLibrary
will result with
Undefined first referenced
symbol in file
__1cG__CrunKpure_error6F_v_ /opt/Centera_SDK/lib/32/libFPXML32.so
__1cG__CrunIex_alloc6FI_pv_ /opt/Centera_SDK/lib/32/libFPLibrary.so
__1cG__CrunIex_throw6Fpvpkn0AQstatic_type_info_pF1_v_v_ /opt/Centera_SDK/lib/32/libFPLibrary.so
__1cDstdPset_new_handler6FpF_v_2_ /opt/Centera_SDK/lib/32/libFPUtils32.so
__1cG__CrunKvector_del6FpvIpF1_v_1_ /opt/Centera_SDK/lib/32/libFPUtils32.so
__1cG__CrunGex_get6F_pv_ /opt/Centera_SDK/lib/32/libFPLibrary.so
__1cG__CrunMex_rethrow_q6F_v_ /opt/Centera_SDK/lib/32/libFPLibrary.so
__1cG__CrunKvector_new6FpvIIpF1_vp2_1_ /opt/Centera_SDK/lib/32/libFPUtils32.so
__1cG__CrunSregister_exit_code6FpG_v_v_ /opt/Centera_SDK/lib/32/libFPLibrary.so
__1cG__CrunHex_skip6F_b_ /opt/Centera_SDK/lib/32/libFPLibrary.so
__1cG__CrunIex_clean6F_v_ /opt/Centera_SDK/lib/32/libFPLibrary.so
__1cG__CrunKex_rethrow6F_v_ /opt/Centera_SDK/lib/32/libFPStreams32.so
__1c2N6FI_pv_ /opt/Centera_SDK/lib/32/libFPLibrary.so
__1c2n6FI_pv_ /opt/Centera_SDK/lib/32/libFPXML32.so
__1c2K6Fpv_v_ /opt/Centera_SDK/lib/32/libFPLibrary.so
__1c2k6Fpv_v_ /opt/Centera_SDK/lib/32/libFPXML32.so
ld: fatal: Symbol referencing errors. No output written to a.out
ANY HELP?
Vojtech
danko1
4 Posts
0
August 26th, 2009 10:00
Weston,
Thanks for binding clarification. It would be nice if the API documentation was as exact. Previous API releases fully supported C and C binding and new 3.2 documentation is not mentioning any new differences or requirements. Considering that 3.2 is just a minor release to 3.1 I would expect more compatibility in building the code not just in the code functionality. The Centera is for our product just one of possible storage options and the API is linked with several dozen executables. We are supporting 5 different flavors of Unix OS, and changes in make files and building process is not trivial.
Well, it is a call for our management whether we want continuing supporting new Centera API releases or not.
Vojtech