0

I've been trying to run the following code taken from the boost site. It compiles, but when I try and run it, I get the following error: ./a: error while loading shared libraries: libboost_system.so.1.57.0: cannot open shared object file: No such file or directory

I've looked at all the similar answers on here, I've tried compiling with all, and each of the following:

g++ boost_server.cpp -o a -I /usr/local/include -L /usr/local/lib/ -lboost_system -lboost_filesystem

The headers and libraries are located in usr/local/include and /usr/local/lib respectively on my machine, which is running CentOS

It's the first time I've used it and I don't know what I"m doing wrong

#include <ctime>
#include <iostream>
#include <string>
#include <boost/asio.hpp>

using boost::asio::ip::tcp;

std::string make_daytime_string()
{
  using namespace std; // For time_t, time and ctime;
  time_t now = time(0);
  return ctime(&now);
}

int main(){
  try
  {
    boost::asio::io_service io_service;

    tcp::endpoint endpoint(tcp::v4(), 13);
    tcp::acceptor acceptor(io_service, endpoint);

    for (;;)
    {
      tcp::iostream stream;
      boost::system::error_code ec;
      acceptor.accept(*stream.rdbuf(), ec);
      if (!ec)
      {
        stream << make_daytime_string();
      }
   }
}
 catch (std::exception& e)
{
std::cerr << e.what() << std::endl;

}

return 0; } ~

jewfro
  • 253
  • 1
  • 5
  • 15

1 Answers1

1

Tell the dynamic linker where your libraries are

LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/lib/" ./a

Either that, or use linker options to "bake in" the hint-paths (not recommended for deployments)

See also

Community
  • 1
  • 1
sehe
  • 374,641
  • 47
  • 450
  • 633
  • This will be for a deployment when I've finished. So the first option, setting library path I should use? And would I put that in the make file, eventually – jewfro Apr 02 '15 at 09:26
  • It didn't work. I figure I was meant to use library path code first. Then ./a. I did this and still got the same error message – jewfro Apr 02 '15 at 09:28
  • It's customary to have wrapper scripts that add the proper LD_LIBRARY_PATH value(s) dynamically. Of course you would not put that into the makefile, because the makefile is (typically) not around in deployments. You might have the makefile generate the wrapper script, but I don't currently see why you would. – sehe Apr 02 '15 at 09:29
  • @jewfro Re. "It didn't work", check that you used the correct path (I had to guess, obviously, but the linker command doesn't fail, so it should be there). Your "Then `./a`." makes me wonder whether you split up the commands? You shouldn't (use `export` if you really need to). – sehe Apr 02 '15 at 09:31
  • I did split the commands, because it just froze when I put them in together, so I thought maybe they should be separate. That is the right library path, I've checked where everything is already. My question about make is related the fact I'm going to be compiling on the same machine, so the compile command in make is going to need whatever fix I'm using now I assume? – jewfro Apr 02 '15 at 09:32
  • Why would you compile it again?! You said compilation/linking already succeeded. – sehe Apr 02 '15 at 09:33
  • I didn't compile again, I just tried setting the variable first, then ./a – jewfro Apr 02 '15 at 09:36
  • Friend. You don't "set the variable first" and then "./a". You enter the command line as shown – sehe Apr 02 '15 at 09:36
  • Sorry, it has worked, it's a server, please ignore my comments *bangs head on desk. Thank you :) – jewfro Apr 02 '15 at 09:37
  • If it hangs that probably just means your program is "working" (fix that next). Try with `ldd ./a` instead of just `./a` to see whether libs are found – sehe Apr 02 '15 at 09:38
  • I know, that's why I wrote bangs head on table, ha ha. I'll try that too, thanks – jewfro Apr 02 '15 at 09:53