Hi! Well, that is the problem. It seems like the complaints mostly regards stuff from basic_istream, basic_ostream and std::vector and should normally not be a problem. Must be something wrong with my makefile, but it is generated from a imakefile which I have used before (with some small changes). Strange. I guess I have to do some more digging. A lot more...
//daniel Erik Rydgren (2003-07-16 14:02): >Short answer: Yes > >Most (well written) libraries only rely on standard libraries that come >with the compiler though. So it is usually not a problem. > >/ Erik > >> -----Original Message----- >> From: Gr�ndal Daniel [mailto:[EMAIL PROTECTED] >> Sent: den 16 juli 2003 13:50 >> To: [EMAIL PROTECTED]; [EMAIL PROTECTED] >> Subject: SV:RE: linkproblems >> >> Hi! >> >> I get your point and it sounds right. >> I that case, how am I supposed to know what libraries any external >> supplier >> might depend on when building there shared library? >> In this case the problem is that the dependencies comes from >libxerces- >> c.so.22, >> so I must know exactly what shared libary they depend on and make sure >> that I >> have them installed and that I can link with them? >> >> //daniel >> >> >> Erik Rydgren (2003-07-16 13:37): >> >A shared library never includes dependencies. It would go against its >> >very purpose, to provide a library of code that an application can >use >> >parts of. Which external libraries that is required for a specific >> >purpose is not known until you actually link a complete application. >> > >> >Just feed the linker the required libraries and these errors should >go >> >away. >> > >> >/ Erik >> > >> >> -----Original Message----- >> >> From: Gr�ndal Daniel [mailto:[EMAIL PROTECTED] >> >> Sent: den 16 juli 2003 13:09 >> >> To: [EMAIL PROTECTED] >> >> Subject: linkproblems >> >> >> >> Hi!! >> >> >> >> I downloaded a binary for Solaris >(xerces-c2_2_0-Sol2.7ForCC.tar.gz) >> >and >> >> built >> >> another shared library using some DOM stuff (and som additional >stuff >> >from >> >> Xalan). This shared library is then linked into a test client. >> >> >> >> When I compile this i get no compile errors, but link errors where >the >> >> complaints concern the downloaded libraries. >> >> >> >> Summary: >> >> 1. Developed a shared library using stuff from libxerces-c.so.22 >and >> >> libxalan-c1_5_0.so >> >> 2. Compiled and built a shared library of this (linking with the >two >> >> earlier >> >> mentioned libraries) >> >> 3. Developed a small test client to test my shared library. >> >> 4. Compiled the test client linking with my new shared library. >> >> >> >> I compile using CC: >> >> CC Cluster(nod1)% CC -V >> >> CC: Sun WorkShop 6 update 2 C++ 5.3 Patch 111685-08 2002/06/02 >> >> >> >> The error looks like this (somewhat modified for readability): >> >> Undefined first referenced >> >> symbol in file >> >> long std::basic_istream<char,std::char_traits<char> >>::gcount()const >> >> lib/libxalan-c1_5_0.so >> >> std::istrstream::~istrstream() lib/libxalan-c1_5_0.so >> >> std::basic_ostream<char,std::char_traits<char> >> >>&std::basic_ostream<char, >> >> std::char_traits<char> >::write(const char*,long) >> >lib/libxerces-c.so.22 >> >> std::ostrstream::~ostrstream() lib/libxalan-c1_5_0.so >> >> std::ostrstream::ostrstream() lib/libxalan-c1_5_0.so >> >> std::basic_istream<char,std::char_traits<char> >> >>&std::basic_istream<char, >> >> std::char_traits<char> >::read(char*,long) lib/libxalan-c1_5_0.so >> >> std::istrstream::istrstream(const char*,long) >> >lib/libxalan-c1_5_0.so >> >> char*std::ostrstream::str() lib/libxalan-c1_5_0.so >> >> void std::vector<bool,std::allocator<bool> >> >> >::__insert_aux(std::vector<bool, >> >> std::allocator<bool> >::iterator,bool) lib/libxalan-c1_5_0.so >> >> >std::fpos<__mbstate_t>std::basic_istream<char,std::char_traits<char> >> >> >::tellg() >> >> lib/libxalan-c1_5_0.so >> >> ld: fatal: Symbol referencing errors. No output written to >> >./bin/xmltest >> >> *** Error code 1 >> >> make: Fatal error: Command failed for target `bin/xmltest' >> >> >> >> Seems to me that the complaints regard STL stuff? I have noticed >> >before >> >> when a >> >> create shared library that these don't always include other >libraries >> >that >> >> it >> >> depends on. They rather depend on the mainprogram to include this. >I >> >guess >> >> this >> >> might be the case here. >> >> >> >> Any ideas on what to do to solve this minor problem? >> >> >> >> //daniel >> >> >> >> >--------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >--------------------------------------------------------------------- >> >To unsubscribe, e-mail: [EMAIL PROTECTED] >> >For additional commands, e-mail: [EMAIL PROTECTED] >> > >> >> ------------------------------------------------------------------ >> RFV Data E-post: [EMAIL PROTECTED] >> Utvecklingsenheten/Grupp 2 Tfn: 060-187126 >> S.a J�rnv�gsgatan 41 Mobil: 070-3016517 >> 851 93 Sundsvall Fax: 060-147870 >> ------------------------------------------------------------------ >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > ------------------------------------------------------------------ RFV Data E-post: [EMAIL PROTECTED] Utvecklingsenheten/Grupp 2 Tfn: 060-187126 S.a J�rnv�gsgatan 41 Mobil: 070-3016517 851 93 Sundsvall Fax: 060-147870 ------------------------------------------------------------------ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
