Project Home
Project Home
Trackers
Trackers
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - libcpp.so.3 error: (17 Items)
   
libcpp.so.3 error  
Hi,

I am compiling a c++ application and it gets compiled successfully on PE 6.3.0 SP2 and can easily be run by downloading 
to x86 target thro' IDE. The problem arises when I want to launch the application remotely thro' Target File Navigator 
and it does'nt run but raise an exception "libcpp.so.3 not found", where as the libcpp.so.3 file is in /proc/boot.

Can anybody look into it? Thanks.

Thanks

Balwant
Re: libcpp.so.3 error  
Looks like loader cannot find it in /proc/boot, can you try to copy it to /tmp (just to test this assumption)
If it is the case you need to modify LD_LIBRARY_PATH env var before starting qconn on target to include this path.
Re: libcpp.so.3 error  
Even if the libcpp.so.3 is copied into /tmp, which we assume is the working location of the application, the program 
launches but fails as soon as it encounters the first function which uses the said dll. 

Surprisingly the same application works fine when used with telnet or local shell. I am forced to think whether it 
requires some kind of terminal as parent to launch it.

balwant
Re: libcpp.so.3 error  
To work from /tmp it is still has to have "." in LD_LIBRARY_PATH unless it is empty. Please check what is it set to for 
qconn process.

Balwant Singh wrote:
> Even if the libcpp.so.3 is copied into /tmp, which we assume is the working location of the application, the program 
launches but fails as soon as it encounters the first function which uses the said dll. 
> 
> Surprisingly the same application works fine when used with telnet or local shell. I am forced to think whether it 
requires some kind of terminal as parent to launch it.
> 
> balwant
> 
> _______________________________________________
> QNX Momentics Community Support
> http://community.qnx.com/sf/go/post15616
> 
Re: libcpp.so.3 error  
On Tue, Oct 28, 2008 at 12:08:07PM -0400, Elena Laskavaia wrote:
> To work from /tmp it is still has to have "." in LD_LIBRARY_PATH unless it is empty. Please check what is it set to 
for qconn process.

That's a bug.  Should be fixed in 6.4.  Should have to add
/tmp to LD_LIBRARY_PATH or _CS_LIBPATH.

-seanb
Re: libcpp.so.3 error  
LD_LIBRARY_PATH=:/proc/boot:/lib:/lib/dll:/root/prog:/opt/Mozilla/mozilla

I assume /proc/boot and as well as /root/prog which is /tmp in our case both are listed here. Also the C applications 
work fine in all cases
Re: libcpp.so.3 error  
Hmm. What does ldd say with your binary? You sure LD_LIBRARY_PATH has this value for "qconn" process? Try to slay qconn 
and run again from this shell and try to launch app again.

Balwant Singh wrote:
> LD_LIBRARY_PATH=:/proc/boot:/lib:/lib/dll:/root/prog:/opt/Mozilla/mozilla
> 
> I assume /proc/boot and as well as /root/prog which is /tmp in our case both are listed here. Also the C applications 
work fine in all cases
> 
> _______________________________________________
> QNX Momentics Community Support
> http://community.qnx.com/sf/go/post15619
> 
Re: libcpp.so.3 error  
I think the problem is not with qconn, because when I reboot the target and launch the application thro' startup script,
 it displays the same behaviour. I must say here that after using all the various permutations and combinations to work 
around the problem the only success I get in running the application is either thro' IDE or thro' some kind of shell 
whether it's telnet or local sh.

The other way of workaround is to change the application to C, which I have done and already tested with the same 
functionality, but the future developments will not be as scalable.
Re: libcpp.so.3 error  
The only 2 possible explanations are:
- LD_LIBRARY_PATH is not set correctly
- file libcpp.so.3 is not what you think it is (i.e. it can  be broken link, it can be different library etc)

If you want to launch it from startup it is the same thing - you have to fix LD_LIBRARY_PATH before you launching it.

Balwant Singh wrote:
> I think the problem is not with qconn, because when I reboot the target and launch the application thro' startup 
script, it displays the same behaviour. I must say here that after using all the various permutations and combinations 
to work around the problem the only success I get in running the application is either thro' IDE or thro' some kind of 
shell whether it's telnet or local sh.
> 
> The other way of workaround is to change the application to C, which I have done and already tested with the same 
functionality, but the future developments will not be as scalable.
> 
> _______________________________________________
> QNX Momentics Community Support
> http://community.qnx.com/sf/go/post15623
> 
Re: libcpp.so.3 error  
What you say makes sense , because "std::cout" works fine and then it fails in the function which uses a library 
function from other lib which is statically linked. Can you figure out why it's running when launched from a shell ?
Re: libcpp.so.3 error  
I already said, it is running from the shell because LD_LIBRARY_PATH is set correctly. Just for fun include printf("%s\n
", getenv("LD_LIBRARY_PATH"));
in your app and compare two runs where it does correctly and incorrectly. I still don't understand how it can run 
partially though. Are you doing dlopen?

Balwant Singh wrote:
> What you say makes sense , because "std::cout" works fine and then it fails in the function which uses a library 
function from other lib which is statically linked. Can you figure out why it's running when launched from a shell ?
> 
> _______________________________________________
> QNX Momentics Community Support
> http://community.qnx.com/sf/go/post15625
> 
Re: libcpp.so.3 error  
Both the cases gets fail on printf, getenv("LD_LIBRARY_PATH") returns 0x0.

Process 172053 (FuzzyTest_gBalwant1225216990531) terminated SIGSEGV code=1 fltno=11 ip=b033fff6 mapaddr=0003fff6. ref=
00000000

Process 176149 (FuzzyTest) terminated SIGSEGV code=1 fltno=11 ip=b033fff6 mapaddr=0003fff6. ref=00000000

and am not using dlopen
Re: libcpp.so.3 error  
So why don't you set it??? I already said that you have to set this var and export for loader to read it. And restart 
qconn with this var set.

And add check for null so it does not crash for this test.

Balwant Singh wrote:
> Both the cases gets fail on printf, getenv("LD_LIBRARY_PATH") returns 0x0.
> 
> Process 172053 (FuzzyTest_gBalwant1225216990531) terminated SIGSEGV code=1 fltno=11 ip=b033fff6 mapaddr=0003fff6. ref=
00000000
> 
> Process 176149 (FuzzyTest) terminated SIGSEGV code=1 fltno=11 ip=b033fff6 mapaddr=0003fff6. ref=00000000
> 
> and am not using dlopen
> 
> _______________________________________________
> QNX Momentics Community Support
> http://community.qnx.com/sf/go/post15639
> 
Re: libcpp.so.3 error  
But how do i do it, should i use explicitly "setenv" because am already using "LD_LIBRARY_PATH =..." in startup script.

Thanks
Re: libcpp.so.3 error  
LD_LIBRARY_PATH=...
export LD_LIBRARY_PATH

if it is "sh". I don't know how to set it in "ksh"

Balwant Singh wrote:
> But how do i do it, should i use explicitly "setenv" because am already using "LD_LIBRARY_PATH =..." in startup script
.
> 
> Thanks
> 
> _______________________________________________
> QNX Momentics Community Support
> http://community.qnx.com/sf/go/post15641
> 
Re: libcpp.so.3 error  
Yes I did that and now the app does'nt fail, but it still gives wrong results in two different launching

thro' IDE it's correct--->
Welcome to the Fuzzy c++
:/proc/boot:/lib:/lib/dll:/root/prog
Kp-1.26048Ki-0.260479Kd-0.260479
kp : -1.26, Ki : -0.26 , kd : -0.26
Ending Fuzzy c++


thro' remote launching--->
Welcome to the Fuzzy c++
:/proc/boot:/lib:/lib/dll:/root/prog
Kp-6.51398e-10Ki-6.51398e-10Kd-6.51398e-10
kp : -0.00, Ki : -0.00 , kd : -0.00
Ending Fuzzy c++

I suspected the libcpp.so.3 because of the reporting when it was'nt present, but std:cout is working so it is not libcpp
.so.3
Re: libcpp.so.3 error  
Well friends, anybody can act stupid at anytime...and am not any exception :)

The problem turned out to be the silly one "current working directory" is the main culprit, some of the files being 
accessed were not in the scope when running thro' qconn, however the same files were on the same directory as app, and 
when accessed thro' any shell sets the cwd as the same.

Thanks for your time and specially elena

By the way y'day was Diwali - the festival of lights in India, Happy Diwali to all the community members