Getting ASIO application to link (undefined reference to `boost::system::generic_category())
Hi,
Trying to get an ASIO example (udp_echo_client) to build on an Ubuntu
12.04 machine.
It looks like both 1.46 and 1.48 can be installed. (I have installed 1.48).
The libboost*.so all are linked vs 1.48,
and the /usr/include/boost/version.hpp contains
#define BOOST_LIB_VERSION "1_48"
so I think that there should not be a version mismatch,
I can build some really simple examples but,
as soon as I add "asio" with the statement below, the build fails.
using boost::asio::ip::udp;
Fiirst problem is that `boost::system::generic_category()' is missing.
When I grep the libboost libraries, they are only found in
"libboost_[file]system[-mt].so"
but these files are included in the link.
Searching on Internet, also tells me to link with those libraries, which
is not a help.
Tried with "-mt" version as well.
Added
#include
Solved!
The Libraries need to be at the end during the link phase.
$ g++ -c -I/usr/include -Iinclude -std=c++0x -o udp_echo_client.o
udp_echo_client.cpp
$ g++ -o udp_echo_client udp_echo_client.o -L/usr/lib -lboost_filesystem
-lboost_system -lpthread
works
BR
Ulf
-------- Original Message --------
Subject: Getting ASIO application to link (undefined reference to
`boost::system::generic_category())
Date: Tue, 17 Sep 2013 16:58:55 +0200
From: Ulf Samuelsson
On Tue, 17 Sep 2013 19:20:54 +0200, Ulf Samuelsson
Solved! The Libraries need to be at the end during the link phase.
$ g++ -c -I/usr/include -Iinclude -std=c++0x -o udp_echo_client.o udp_echo_client.cpp $ g++ -o udp_echo_client udp_echo_client.o -L/usr/lib -lboost_filesystem -lboost_system -lpthread
works
BR Ulf
... what means that the linker uses static libraries (.a). Use -t linker flag (-Wl,-t to gcc) to debug which libraries linker finds and which it takes. // The *.so are in -dev packages in some distributions. Maybe you need boost*dev package(s) installed in ubuntu? Regards, Slava
On 2013-09-18 08:32, Slava wrote:
On Tue, 17 Sep 2013 19:20:54 +0200, Ulf Samuelsson
wrote: Solved! The Libraries need to be at the end during the link phase.
$ g++ -c -I/usr/include -Iinclude -std=c++0x -o udp_echo_client.o udp_echo_client.cpp $ g++ -o udp_echo_client udp_echo_client.o -L/usr/lib -lboost_filesystem -lboost_system -lpthread
works
BR Ulf
... what means that the linker uses static libraries (.a). Use -t linker flag (-Wl,-t to gcc) to debug which libraries linker finds and which it takes. // The *.so are in -dev packages in some distributions. Maybe you need boost*dev package(s) installed in ubuntu?
No, the solution is simple. The -l<library> must be AFTER the reference to the object files. FAIL: g++ -lboost_system myfile.o OK: g++ myfile.o -lboost_system Maybe there is a good reason for this. BR Ulf
Regards, Slava
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 09/18/2013 08:40 AM, Ulf Samuelsson wrote:
No, the solution is simple. The -l<library> must be AFTER the reference to the object files.
FAIL: g++ -lboost_system myfile.o OK: g++ myfile.o -lboost_system
Maybe there is a good reason for this.
Many linkers are single-pass linkers because that gives better linking speed. See "The linking process" section of: http://eli.thegreenplace.net/2013/07/09/library-order-in-static-linking/
On Wed, Sep 18, 2013 at 12:47:12PM +0200, Bjorn Reese wrote:
On 09/18/2013 08:40 AM, Ulf Samuelsson wrote:
No, the solution is simple. The -l<library> must be AFTER the reference to the object files.
FAIL: g++ -lboost_system myfile.o OK: g++ myfile.o -lboost_system
Maybe there is a good reason for this.
Many linkers are single-pass linkers because that gives better linking speed. See "The linking process" section of:
http://eli.thegreenplace.net/2013/07/09/library-order-in-static-linking/
As touched on in the article linked, the ability to override functions by sneaking in a library providing the function before the usual provider is considered a feature by some. If you want arbitrary ordering on the linker command line, some linkers offer --start-group and --end-group directives that spin the libraries bounded by the directives enough times to satisfy as many symbols as possible. Otherwise, the short form of the linker command line order advice is: Stuff that needs stuff needs to be before stuff that provides stuff. -- Lars Viklund | zao@acc.umu.se
On 2013-09-18 12:47, Bjorn Reese wrote:
On 09/18/2013 08:40 AM, Ulf Samuelsson wrote:
No, the solution is simple. The -l<library> must be AFTER the reference to the object files.
FAIL: g++ -lboost_system myfile.o OK: g++ myfile.o -lboost_system
Maybe there is a good reason for this.
Many linkers are single-pass linkers because that gives better linking speed. See "The linking process" section of:
http://eli.thegreenplace.net/2013/07/09/library-order-in-static-linking/
That still does not mean that you cannot parse a command line before starting the actual link process. Maybe in obscure cases you want tighter control when a library can be used, but it should IMHO be the exception. BR Ulf
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 9/19/2013 3:20 AM, Quoth Ulf Samuelsson:
That still does not mean that you cannot parse a command line before starting the actual link process.
It's not about the command line parsing, it's about the order that the objects and libraries themselves are parsed in. The order in which objects are linked can be critically important for certain designs (eg. if you do want a symbol in your application to override one provided by a library, or if you're building a multi-object data structure in a special shared data section). And so that order has been defined as the order that they're listed on the command line, which just makes sense. Sure, it can be a little surprising when you're not used to it, but it's not hard to get it "right" thereafter. And while it's possible to tell the linker to loop through multiple times until it's found everything, this is generally a bad idea as it hides circular dependencies, which are usually a sign of a bad design. And it's slower than just listing things in the correct order to begin with.
participants (5)
-
Bjorn Reese
-
Gavin Lambert
-
Lars Viklund
-
Slava
-
Ulf Samuelsson