Problem in Compiling Boost Blocking TCP Echo Client

Question

0.00/5 (No votes)

See more:

I am trying to compile The example of Boost Blocking TCP ECHO Client[^] using g++ compiler:

g++ -o test Simulator_main.cpp -I /home/ha/MIH/boost_1_49_0/ -L /usr/local/lib/ -lboost_system -lpthread

The compilation is success, but when I run the program I get the following errors

root@ubuntu:/home/ha/MIH/ODTONE/app/lte_sim# ./test
./test: error while loading shared libraries: libboost_system.so.1.49.0: cannot open shared object file: No such file or directory

So any suggestion how to solve the problem?

Also how can I use the the Boost.build b2 command to do the compilation?

Thanks a lot in advance.

Posted 27-Feb-14 9:32am

Mr.HA-AS

Updated 27-Feb-14 9:35am

v2

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Garth J Lancaster · Answer 1 · 2014-02-27T10:16:00

Solution 1

On windows you would either put libboost_system.so.1.49.0 in the same 'folder' as the compiled (exe) (not a good idea with big distro's like boost), or, make sure the directory where all the boost 'binary'/compiled libs/dlls is/are is on your path

Im not sure how Linux searches for libs/dll's, I'd go with adding the lib directory to your working path and trying that

assumption : you have compiled or are using a binary distro for boost, yes ? - iirc, boost has a deploy option, where you state where to deploy compiled libs/dlls to, so I'd look at that, and use that path

'g'

Posted 27-Feb-14 10:16am

Garth J Lancaster

Comments

Sergey Alexandrovich Kryukov 27-Feb-14 16:24pm

Not quite so in Linux. It has pretty rigid directory structure with customary spaced for libraries which are made accessible to all projects. Overall, some problem if Linux style of excessive accessibility of files. It can be changes, but hardly quickly or safely.
On Windows, the problem is similar, but different: low reuse of executable modules, a lot of ways leading to excessive redundant copies of the same executable modules and other files, no good control over different versions of that. This is commonly referred to as "DLL hell". The "perfect" solution?... it depends on the situation, but it's never perfect.
—SA

Garth J Lancaster 27-Feb-14 16:48pm

ta SAK - that doesn't help him/the op with /usr/local/lib/ though - good in concept, bad in implementation ? been a long time since I compiled anything for *nix (and that was on Solaris) .. sigh, those were the days - and yes, I do remember dll hell

Sergey Alexandrovich Kryukov 27-Feb-14 16:57pm

The DLL help, especially in native programming, hasn't gone. I think /urs/local/lib/... is still a viable option for Linux. I actually do just a bit of development for Linux, pretty rarely, mostly multiplatform kind, code which can be run on both .NET and Mono. A while ago, did a little contract for .NET to multuplatform migration, with compatibility with Max OS X — not so pleasant thing...
—SA

Mr.HA-AS 27-Feb-14 16:29pm

Thanks for your answer.

Currently I am working in Linux environment "Ubuntu x64". When I compiled Boost, it installed the binary libraries automatically in /usr/local/lib/ , and this is the path I am using in my command.

Also I already tried to copy the missing file into the current working directory, but I still get the same error.

markkuk 28-Feb-14 6:12am

Why did you compile Boost instead of using the Boost library provided by the Ubuntu distribution? Libraries installed through the distro's package management are found automatically.

Mr.HA-AS 28-Feb-14 9:58am

Because I need to use a specific version for Boost libraries, not the latest one. And as far as I know, you cannot do that when you install Boost library with the Ubuntu distribution