Home.... | log in.... | Pub my question! | Sign-up....

Java-index >> Development Tools >> Solaris and Linux Development Tools

problems linking with log4cpp..

Hi all,

working on a T200 with solaris 10 and sunstudio 11,

I have a program that I have to compile with -library=stlport4 since it's being ported from gcc where it was using <hash_map>.

I succeeded building log4cpp-0.3.5-rc3 with SUN compiler both with standard STL and with stlport, but now it seems I cannot use neither one of these two version of liblog4cpp.so with my program, because when it comes to linking in sunstudio, it fails with a lot of messages like

undefined symbolfirst referenced in file

std::ostream &std::operator<<(...)liblog4cpp.so

std::ios::operator void *() const liblog4cpp.so

.........

The test application included in the log4cpp source distribution has been built and runs with no problems...

So I have no clue of what this could be, it seems like liblog4cpp.so _itself_ is missing some external library when it comes to linking with my app...

If I remove -library=stlport4 everything is ok, but then I cannot use hash_map in my program....

Any idea? Am I missing something particularly stupid?...

Thanks in advance.

Andrea.

[1155 byte] By [abigagli] at [2007-11-26 9:12:52]

«« Disabling Alarms? - include group actions checkbox
»» Assigning admin role with bulk action

# 1

Since you don't show the complete names of the missing symbols, I can't tell whether they are from the application or should be found in a system library.

When using the STLport option, you must use the option

-library=stlport4

on every CC command line, compiling and linking. DId you do that?

In addition, if any binary that you link into the program was built without that option (that is, if any binary depends on the default libCstd), you can't use STLport anywhere else in the program.

clamage45 at 2007-7-6 23:34:55 >

top of Java-index,Development Tools,Solaris and Linux Development Tools...

# 2

Sorry I couldn't write the full lines nor I can right now since I'm not in my coding place...

Anyway every undefined symbol is related in some way to iostream and the referrer is always liblog4cpp.so...

Yes, I put the -library=stlport4 on every line.

Also, I knew that every other library has to be linked with the stlport, but now that you make me think about that, my program uses libmysqlclient.so, which comes with mysql and I suppose it wouldn't satisfy such a requirement... Could it be the culprit?

But I anyway can't understand that type of error I'm receiving where everything seem to be in liblog4cpp.so not able to find some external symbols related to iostream...

Thanks again to whoever may shed some light on this...

Andrea.

abigagli at 2007-7-6 23:34:55 >

# 3

Here is an example of why you need to know the complete function signature: [code]

#include <iostream>

struct S { int a, b; };

std::ostream& operator << (std::ostream&, const S&);

int main()

{

S s;

std::cout << s;

} [/code]

If I don't show you the source code and tell you only that the linker complains about a missing

std::ostream &operator<<(...)

it looks like it might be a problem with a system library.

But if I give you the full function signature

std::ostream &operator<<(std::ostream &,const S&)

it becomes obvious that the problem is in user code, because the operator<< involves a user-defined type.

It is impossible to tell what is actually going on without seeing the full function signatures of missing functions.

Regarding libmysqlclient.so, you need to find out whether it was built for the default libCstd, or the optional STLport. If you can build it yourself, you can ensure it is built for STLport.

clamage45 at 2007-7-6 23:34:55 >

# 4

Thanks for the help, I finally managed to capture the output from the linking stage, so here it is:

[i]Undefinedfirst referenced

symbolin file

std::smanip::smanip(std::ios_base&(*)(std::ios_base&,int),int)/usr/loca l/lib/liblog4cpp.so

bool std::ios::operator!()const /usr/local/lib/liblog4cpp.so

std::basic_istream&std::getline<char,std::char_traits><char>,st d::allocator<char>>(std::basic_istream&,std::basic_string<__type _0,__type_1,__type_2>&,__type_0)/usr/local/lib/liblog4cpp.so

std::ios::operator void*()const /usr/local/lib/liblog4cpp.so

std::smanip_fill >::smanip_fill(std::ios &(*)(std::ios&,char),char)/usr/local/lib/liblog4cpp.so

int std::char_traits::eof()/usr/local/lib/liblog4cpp.so

std::basic_istream&std::ws<char,std::char_traits><char>>(std ::basic_istream&)/usr/local/lib/liblog4cpp.so

void std::__initialize(__type_0&,__type_0) /usr/local/lib/liblog4cpp.so

std::ostream &std::operator<<(std::ostream&,constchar*) /usr/local/lib/liblog4cpp.so

bool std::operator!=,std::allocator >(const std::basic_string&,const__type_0*) /usr/local/lib/liblog4cpp.so

char*std::char_traits::move(char*,const char*,unsigned) /usr/local/lib/liblog4cpp.so

const __type_0&std::use_facet<std::ctype><char>>(const std::locale&,__type_0*)/usr/local/lib/liblog4cpp.so

std::istream &std::istream::getline(char*,long)/usr/local/lib/liblog4cpp.so

std::basic_stringstd::operator+,std::allocator >(const std::basic_string&,__type_0)/usr/local/lib/liblog4cpp.so

std::logic_error::logic_error #Nvariant 1(const std::string &)/usr/local/lib/liblog4cpp.so

std::ostream &std::operator<<(std::ostream&,char)/usr/local/lib/liblog4cpp.so

bool std::char_traits::eq_int_type(const int&,constint&)/usr/local/lib/liblog4cpp.so

std::string std::string::__sun_concat(const std::string &)const/usr/local/lib/liblog4cpp.so

std::string std::string::__sun_concat(const char*)const /usr/local/lib/liblog4cpp.so

bool std::ios::good()const /usr/local/lib/liblog4cpp.so

std::istream::sentry::operator bool() /usr/local/lib/liblog4cpp.so

ld: fatal: Symbol referencing errors. No output written to build/solaris/mspp

*** Error code 1

dmake: Fatal error: Command failed for target `build/solaris/mspp'[/i]

I understand what you explained in your mail, and it makes sense, but I find somewhat difficult to really understand, looking at the previous output, which is the scenario here....

Can you better see through it?...

Thanks,

Andrea.

abigagli at 2007-7-6 23:34:55 >

# 5

I suspect the problem here is that liblog4cpp was compiled by g++, not by Sun C++.

By default, the linker error output is run through a filter that demangles names so you can see the function signature approximately as it appears in source code. The demangler can demangle g++ names as well as Sun C++ names, so the demangled name obscures whether the code comes from g++ or Sun C++.

Add the option

-filt=%none

to the CC command that does the link step. The error message will contain the mangled names seen by the linker, instead of the demangled names you see here.

Sun C++ mangled names start with __1

g++ mangles names start with different characters, depending on the version of g++.

For example, g++ 3.4.3 starts mangled names with _Z

Apart from differences in mangled names, the binary interface used by g++ is not compatible with Sun C++, and you cannot mix g++ and Sun C++ binary code in the same program. If liblog4cpp was built by g++, you will have to get a version built by Sun C++ using STLport, or build it yourself.

If liblog4cpp has Sun C++ mangled names after all, please post the error output showing the mangled names. I can more easily diagnose the problem.

clamage45 at 2007-7-6 23:34:55 >

# 6

Sorry, I got confused about which library was which. I see that you built liblog4cpp yourself using STLport.My comments about a library built with g++ would apply to libmysqlclient.so

clamage45 at 2007-7-6 23:34:55 >

# 7

Thanks again,

but I'm now a little lost....

I confirm that I rebuilt liblog4cpp from scratch using Sun's CC with stlport, so how is it that all the linker's complains seem to be related to liblog4cpp.so?

I'm at a stop and I really don't know how to get back going...

Andrea.

abigagli at 2007-7-6 23:34:55 >

# 8

Please show the entire CC command line that you use to link the program.Please also add the option -filt=%None and show the linker error output.To make the output more readable, put it inside "code" brackets when you post it here

clamage45 at 2007-7-6 23:34:55 >

# 9

Ok, so here it is the output after I've added the -filt=%none flag to the linker command line...

[code]

Undefinedfirst referenced

symbolin file

__1cDstdGsmanip4Ci_2t6MpFrn0AIios_base_i_3i_v_ ./liblog4cpp_stlport.so

__1cDstdJbasic_ios4Ccn0ALchar_traits4Cc2C6kM_b_ ./liblog4cpp_stlport.so

__1cDstdHgetline4Ccn0ALchar_traits4Cc__n0AJallocator4Cc6Frn0ANbasic_istream3 CTACTB__rn0AMbasic_string3C1C2CTC__1_4_ ./liblog4cpp_stlport.so

__1cDstdJbasic_ios4Ccn0ALchar_traits4Cc2v6kM_pv_ ./liblog4cpp_stlport.so

__1cDstdLsmanip_fill4Ccn0ALchar_traits4Cc2t6MpFrn0AJbasic_ios4Ccn0Bc_3c_v _ ./liblog4cpp_stlport.so

__1cDstdLchar_traits4Cc_Deof6F_i_./liblog4cpp_stlport.so

__1cDstdCws4Ccn0ALchar_traits4Cc6Frn0ANbasic_istream3CTACTB4_ ./liblog4cpp_stlport.so

__1cDstdM__initialize4CI_6FrTA1_v_ ./liblog4cpp_stlport.so

__1cDstd2l6Frn0ANbasic_ostream4Ccn0ALchar_traits4Cc_pkc_2_ ./liblog4cpp_stlport.so

__1cDstd2E4Ccn0ALchar_traits4Cc__n0AJallocator4Cc6Frkn0AMbasic_string3CTACTB CTC__pk1_b_ ./liblog4cpp_stlport.so

__1cDstdLchar_traits4Cc_Emove6FpcpkcI_2_ ./liblog4cpp_stlport.so

__1cDstdJuse_facet4n0AFctype4Cc6Frkn0AGlocale_pTA_rk4_ ./liblog4cpp_stlport.so

__1cDstdNbasic_istream4Ccn0ALchar_traits4CcHgetline6Mpcl_r1_ ./liblog4cpp_stlport.so

__1cDstd2s4Ccn0ALchar_traits4Cc__n0AJallocator4Cc6Frkn0AMbasic_string3CTACTB CTC__1_4_ ./liblog4cpp_stlport.so

__1cDstdLlogic_error2t5B6Mrkn0AMbasic_string4Ccn0ALchar_traits4Cc__n0AJallocato r4Cc__v_ ./liblog4cpp_stlport.so

__1cDstd2l6Frn0ANbasic_ostream4Ccn0ALchar_traits4Cc_c_2_ ./liblog4cpp_stlport.so

__1cDstdLchar_traits4Cc_Leq_int_type6Frkir2_b_ ./liblog4cpp_stlport.so

__1cDstdMbasic_string4Ccn0ALchar_traits4Cc__n0AJallocator4CcM__sun_concat6kM rk1_1_ ./liblog4cpp_stlport.so

__1cDstdMbasic_string4Ccn0ALchar_traits4Cc__n0AJallocator4CcM__sun_concat6kM pkc_1_ ./liblog4cpp_stlport.so

__1cDstdJbasic_ios4Ccn0ALchar_traits4CcEgood6kM_b_ ./liblog4cpp_stlport.so

__1cDstdNbasic_istream4Ccn0ALchar_traits4CcGsentry2v6M_b_ ./liblog4cpp_stlport.so

ld: fatal: Symbol referencing errors. No output written to build/solaris/mspp

*** Error code 1

[/code]

Note that I've explicitily renamed the liblog4cpp.so compiled with CC and stlport as liblog4cpp_stlport, so that I avoid confusing myself when I try different combinations...

As you explained me, I understand from the "__1" prefix, all these symbols are mangled as per CC conventions...

Does this let you help me in some way?

Thanks,

Andrea.

abigagli at 2007-7-6 23:34:55 >

# 10

The missing symbols are in libCstd, but not in libstlport.

Apparently some binary in liblog4cpp_stlport.so was not compiled using the stlport option.

Check your build logs for liblog4cpp_stlport.so and be sure that every CC command uses -library=stlport4.

As I requested before, please show the entire command line you used to link the executable. (It should also include the -library=stlport4 option.)

clamage45 at 2007-7-6 23:34:55 >

# 11

Yes,

I've checked that liblog4cpp.so has been built with -library=stlport4 both on the compile and on the linker command line.

And here I'm showing you the full output during the compile and linking stage:

[code]

CC -g-c -library=stlport4 -I./include -I/usr/sfw/include/mysql -I/usr/local/include -I../rps/mc_receive/source -I../rps/common/include -I../common/include -L. -Lbuild/solaris -L/usr/local/mysql/lib -L/usr/local/lib -o build/solaris/cmd.o source/cmd.cpp

CC -g-filt=%none -library=stlport4 -I./include -I/usr/sfw/include/mysql -I/usr/local/include -I../rps/mc_receive/source -I../rps/common/include -I../common/include -L. -Lbuild/solaris -L/usr/local/mysql/lib -L/usr/local/lib -o build/solaris/mspp build/solaris/cmd.o build/solaris/dbmgr.o build/solaris/Feeder.o build/solaris/IndexedMap.o build/solaris/main.o build/solaris/Monitor.o build/solaris/mspp_config.o build/solaris/mspp_utils.o build/solaris/NSMapper.o build/solaris/patterns.o build/solaris/PDUSequencer.o build/solaris/processor.o build/solaris/Status.o -lmc_receive -llog4cpp_stlport -lmysqlclient_r -lsocket