topic Re: Unsats during link in Operating System - HP-UX

Linking issue

slash_blog — Sun, 28 Feb 2016 21:54:30 GMT

Hi,

I built xerces-c and xalan-c using aCC compiler successfully.

Now I am trying to build my application which links against these two libraries using aCC. However I am getting the following linker error.

/opt/aCC/bin/aCC -AA -D__HP_NO_STRING_OVERLOADS -O -I../../../3rdParty/HP-UX/include -I/usr/local/include -I/usr/include -I../../../ovaldi-common -I../../src -I../../src/unix -I../../src/probes/unix -I../../src/probes/hpux -I../../src/probes/independent -c ../../src/probes/independent/VariableProbe.cpp -o objs/HP-UX/VariableProbe.o
/opt/aCC/bin/aCC -AA -D__HP_NO_STRING_OVERLOADS -O -I../../../3rdParty/HP-UX/include -I/usr/local/include -I/usr/include -I../../../ovaldi-common -I../../src -I../../src/unix -I../../src/probes/unix -I../../src/probes/hpux -I../../src/probes/independent -c ../../src/probes/independent/XmlFileContentProbe.cpp -o objs/HP-UX/XmlFileContentProbe.o
/opt/aCC/bin/aCC -AA -D__HP_NO_STRING_OVERLOADS -O -Wl,+s objs/HP-UX/CommonBase.o objs/HP-UX/Exception.o objs/HP-UX/Log.o objs/HP-UX/ProcessHelper.o objs/HP-UX/AbsCriteria.o objs/HP-UX/AbsDataCollector.o objs/HP-UX/AbsEntity.o objs/HP-UX/AbsEntityValue.o objs/HP-UX/AbsFileFinder.o objs/HP-UX/AbsObject.o objs/HP-UX/AbsObjectCollector.o objs/HP-UX/AbsProbe.o objs/HP-UX/AbsState.o objs/HP-UX/AbsSystemInfo.o objs/HP-UX/AbsVariable.o objs/HP-UX/Analyzer.o objs/HP-UX/ArithmeticFunction.o objs/HP-UX/BeginFunction.o objs/HP-UX/Behavior.o objs/HP-UX/CollectedObject.o objs/HP-UX/CollectedSet.o objs/HP-UX/Common.o objs/HP-UX/ComponentFactory.o objs/HP-UX/ComponentValue.o objs/HP-UX/ConcatFunction.o objs/HP-UX/ConstantVariable.o objs/HP-UX/CountFunction.o objs/HP-UX/Criteria.o objs/HP-UX/Criterion.o objs/HP-UX/Definition.o objs/HP-UX/Digest.o objs/HP-UX/Directive.o objs/HP-UX/DocumentManager.o objs/HP-UX/EndFunction.o objs/HP-UX/EntityComparator.o objs/HP-UX/EscapeRegexFunction.o objs/HP-UX/ExtendedDefinition.o objs/HP-UX/ExternalVariable.o objs/HP-UX/Filter.o objs/HP-UX/Item.o objs/HP-UX/ItemEntity.o objs/HP-UX/ItemFieldEntityValue.o objs/HP-UX/LiteralComponent.o objs/HP-UX/LocalVariable.o objs/HP-UX/Main.o objs/HP-UX/Object.o objs/HP-UX/ObjectComponent.o objs/HP-UX/ObjectEntity.o objs/HP-UX/ObjectFactory.o objs/HP-UX/ObjectReader.o objs/HP-UX/OvalEnum.o objs/HP-UX/OvalMessage.o objs/HP-UX/PossibleRestrictionType.o objs/HP-UX/PossibleValueType.o objs/HP-UX/REGEX.o objs/HP-UX/RegexCaptureFunction.o objs/HP-UX/RestrictionType.o objs/HP-UX/Set.o objs/HP-UX/SetObject.o objs/HP-UX/SplitFunction.o objs/HP-UX/State.o objs/HP-UX/StateEntity.o objs/HP-UX/StateOrObjectFieldEntityValue.o objs/HP-UX/StringEntityValue.o objs/HP-UX/SubstringFunction.o objs/HP-UX/Test.o objs/HP-UX/TestedItem.o objs/HP-UX/TimeDifferenceFunction.o objs/HP-UX/UniqueFunction.o objs/HP-UX/VariableComponent.o objs/HP-UX/VariableFactory.o objs/HP-UX/VariableValue.o objs/HP-UX/Version.o objs/HP-UX/XmlCommon.o objs/HP-UX/XmlProcessor.o objs/HP-UX/XslCommon.o objs/HP-UX/DataCollector.o objs/HP-UX/DirGuard.o objs/HP-UX/FileFinder.o objs/HP-UX/NetworkInterfaces.o objs/HP-UX/ObjectCollector.o objs/HP-UX/ProbeFactory.o objs/HP-UX/SocketGuard.o objs/HP-UX/SystemInfo.o objs/HP-UX/FileProbe.o objs/HP-UX/InetdProbe.o objs/HP-UX/InterfaceProbe.o objs/HP-UX/PasswordProbe.o objs/HP-UX/Process58Probe.o objs/HP-UX/ProcessProbe.o objs/HP-UX/RunLevelProbe.o objs/HP-UX/ShadowProbe.o objs/HP-UX/UnameProbe.o objs/HP-UX/XinetdProbe.o objs/HP-UX/GetconfProbe.o objs/HP-UX/NddProbe.o objs/HP-UX/Patch53Probe.o objs/HP-UX/SwlistProbe.o objs/HP-UX/TrustedProbe.o objs/HP-UX/EnvironmentVariable58Probe.o objs/HP-UX/EnvironmentVariableProbe.o objs/HP-UX/FamilyProbe.o objs/HP-UX/FileHash58Probe.o objs/HP-UX/FileHashProbe.o objs/HP-UX/FileMd5Probe.o objs/HP-UX/TextFileContent54Probe.o objs/HP-UX/TextFileContentProbe.o objs/HP-UX/VariableProbe.o objs/HP-UX/XmlFileContentProbe.o -L../../../3rdParty/HP-UX/lib -L/usr/lib -L/usr/local/lib -lxerces-c -lxalan-c -lxalanMsg -lpcre -lgpg-error -lgcrypt -lsec -o Release/HP-UX/bl-ovaldi
/usr/ccs/bin/ld: Unsatisfied symbols:
xalanc_1_11::OutputString(std::basic_ostream<char,std::char_traits<char>> &,const unsigned short *,xercesc_3_1::MemoryManager &) (first referenced in objs/HP-UX/XmlFileContentProbe.o) (code)
xalanc_1_11::XSLTResultTarget::XSLTResultTarget(std::basic_ostream<char,std::char_traits<char>> &,xercesc_3_1::MemoryManager &)%1 (first referenced in objs/HP-UX/XslCommon.o) (code)
make: *** [Release/HP-UX/bl-ovaldi] Error 1

I am not sure why this is coming since I am used aCC to compile both the libraries and my application. And only xalan-c seems to give this linking error. Can somebody please suggest what could be the problem.

-SB

Re: Unsats during link for PA-RISC

Dennis Handly — Mon, 29 Feb 2016 15:03:16 GMT

>xalanc_1_11::OutputString(...) (XmlFileContentProbe.o)

>xalanc_1_11::XSLTResultTarget::XSLTResultTarget(...)%1 (XslCommon.o)

Where is this function and this constructor suppose to be defined? Which object and shlib?

Leave this off "-L/usr/lib", it will be added by default.

Re: Unsats during link

slash_blog — Mon, 29 Feb 2016 14:25:53 GMT

Thanks Dennis for your response.

I did some more analysis. First to answer your question these two are part of xalanc library. I can see a file DOMStringHelper.hpp which has the following code:

XALAN_PLATFORMSUPPORT_EXPORT_FUNCTION(void)
OutputString(
#if defined(XALAN_NO_STD_NAMESPACE)
            ostream&                theStream,
#else
            std::ostream&           theStream,
#endif
            const XalanDOMChar*     theString,
            MemoryManager&          theMemoryManager);

And XSLTResultTarget.hpp,

#if defined(XALAN_NO_STD_NAMESPACE)
    typedef ostream         StreamType;
#else
    typedef std::ostream    StreamType;
#endif

    XSLTResultTarget(StreamType*    theStream,
                    MemoryManager& theManager XALAN_DEFAULT_CONSTRUCTOR_MEMMGR);

Further, I checked that during xalan-c build it executes aCC something like:

aCC +O2 -DNDEBUG     +Z -DHPUX -D_THREAD_SAFE +W849,930 -mt  -Wc,-koenig_lookup,on -Wc,-ansi_for_scope,on -DXALAN_INMEM_MSG_LOADER

In other words, -AA parameter is not being used (which we are using in the build of our product). I presume when aCC is executed without -AA command line argument, it sets XALAN_NO_STD_NAMESPACE and that is causing problems, since now I am compiling with -AA and it is picking different signature of function and constructor than what is in the xalan-c library.

At this point I am not sure what to do about this. Any suggestions? Porting either is not an option at this stage, since it would involve big efforts. Any workaround?

Further while doing a searcb from strings command output I can see the following:

$strings libxalan-c.sl.111.0 libxalanMsg.sl.111.0 | egrep 'xalanc_1_11.*OutputString'
$ strings libxalan-c.sl.111.0 libxalanMsg.sl.111.0 | egrep 'xalanc_1_11.*XSLTResultTarget.*XSLTResultTarget'
{$RATBL$__ct__Q2_11xalanc_1_1116XSLTResultTargetFRCQ2_11xalanc_1_1116XSLTResultTargetRQ2_11xercesc_3_113MemoryManager$RANGE$
y$AUX_ACTION$__ct__Q2_11xalanc_1_1116XSLTResultTargetFRCQ2_11xalanc_1_1116XSLTResultTargetRQ2_11xercesc_3_113MemoryManager
m__ct__Q2_11xalanc_1_1116XSLTResultTargetFRCQ2_11xalanc_1_1116XSLTResultTargetRQ2_11xercesc_3_113MemoryManager
o__ct__Q2_11xalanc_1_1116XSLTResultTargetFRCQ2_11xalanc_1_1116XSLTResultTargetRQ2_11xercesc_3_113MemoryManager_1
o__ct__Q2_11xalanc_1_1116XSLTResultTargetFRCQ2_11xalanc_1_1116XSLTResultTargetRQ2_11xercesc_3_113MemoryManager_2
__ct__Q2_11xalanc_1_1116XSLTResultTargetFRCQ2_11xalanc_1_1116XSLTResultTargetRQ2_11xercesc_3_113MemoryManager
__ct__Q2_11xalanc_1_1116XSLTResultTargetFRCQ2_11xalanc_1_1116XSLTResultTargetRQ2_11xercesc_3_113MemoryManager_2
__ct__Q2_11xalanc_1_1116XSLTResultTargetFRCQ2_11xalanc_1_1116XSLTResultTargetRQ2_11xercesc_3_113MemoryManager_1

I am not sure what I can deduce from above since there is no matching string for OutputString search.

To give background, same code compiles on Linux/AIX/Solaris where xalan-c is built using g++. On HP-UX we earlier were using xalan-c built on a machine which was version 11.00 using gcc-3.4.6, and it was working fine. We explicitly ported Makefile to work with g++ since xalan-c by default supports aCC build only on HP-UX.

Now we have moved to HP-UX 11.23 build machine and there xalan-c build is failing with the ported Makefile and giving core during build, really not sure why. The compiler on this machine is gcc-4.5.4. This is what happens:

../../../bin/MsgCreator
/home/tuser/build/3rdParty-build/HP-UX/xalan-c-1.11/c/src/xalanc/NLS/en_US/XalanMsg_en_US.xlf
-TYPE inmem -LOCALE en_US
/usr/lib/dld.sl: Unresolved symbol:
_ZNK11xercesc_3_113XMLBigDecimal10getRawDataEv (data)  from
/home/tuser/build/3rdParty/HP-UX/lib/libxerces-c-3.1.sl
[HP ARIES32]: Core file for 32-bit PA-RISC application
[HP ARIES32]:
/home/tuser/build/3rdParty-build/HP-UX/xalan-c-1.11/c/bin/MsgCreator
saved to /home/tuser/build/3rdParty-build/HP-UX/xalan-c-1.11/c/src/xalanc/Utils/core.MsgCreator
make[2]: *** [../../../nls/include/LocalMsgData.hpp] IOT trap (core dumped)
make[2]: Leaving directory
`/home/tuser/build/3rdParty-build/HP-UX/xalan-c-1.11/c/src/xalanc/Utils'

When I run it from command line by setting SHLIB_PATH I get rid of Unresolved symbol issue from xerces library (which is a prerequisite for xalan-c), but I still get a core dump, so can't really proceed with the xalan-c build:

SHLIB_PATH=/home/tuser/build/3rdParty/HP-UX/lib
../../../bin/MsgCreator
/home/tuser/build/3rdParty-build/HP-UX/xalan-c-1.11/c/src/xalanc/NLS/en_US/XalanMsg_en_US.xlf
-TYPE inmem -LOCALE en_US
[HP ARIES32]: Core file for 32-bit PA-RISC application
[HP ARIES32]:
/home/tuser/build/3rdParty-build/HP-UX/xalan-c-1.11/c/bin/MsgCreator
saved to /home/tuser/build/3rdParty-build/HP-UX/xalan-c-1.11/c/src/xalanc/Utils/core.MsgCreator
ABORT instruction (core dumped)

Sorry if I have confused you guys. Just wanted to find your opinion as to how to proceed.

Re: Unsats during link

Dennis Handly — Mon, 29 Feb 2016 15:20:09 GMT

>I can see a file DOMStringHelper.hpp which has the following code:

You need to mention you're using aCC3 for PA-RISC.

You need to find a .cpp that contains the definition, unless it is inline.

Is there a DOMStringHelper.cpp and XSLTResultTarget.cpp?

>I presume when aCC is executed without -AA command line argument, it sets XALAN_NO_STD_NAMESPACE

You'll need to check your code to see if it does that.

>since now I am compiling with -AA and it is picking different signature of function and constructor than what is in the xalan-c library.

Yes, the mangled symbol will be different.

>Porting either is not an option at this stage, since it would involve big efforts.

You can't mix an application using -AA with one using -AP.

>while doing a search from strings command output I can see the following:

$ strings libxalan-c.sl.111.0 libxalanMsg.sl.111.0 | egrep 'xalanc_1_11.*OutputString'
$ strings libxalan-c.sl.111.0 libxalanMsg.sl.111.0 | egrep 'xalanc_1_11.*XSLTResultTarget.*XSLTResultTarget'

The proper command is "nm -pxAN objects... | c++filt -o"

>I still get a core dump, so can't really proceed with the xalan-c build:

>[HP ARIES32]: Core file for 32-bit PA-RISC application ABORT instruction (core dumped)

Have you used gdb to figure out why you are getting signal 6?

Re: Unsats during link

slash_blog — Tue, 01 Mar 2016 14:09:44 GMT

Thanks Dennis. I should have mentioned the compiler version.

I did some further analysis and found that it was indeed the case that not using -AA with aCC would cause the XALAN_NO_STD_NAMESPACE to be defined and it was the cause behind all the problems. So I tried my luck and built both xerces and xalan with -AA against the default of it being otherwise, and with a few changes that I had to do in the code, now everything works. Thanks again for your help.