Menu
▾
▴
cpp-netlib-devel
|
From: Gregory S. <gs...@dr...> - 2011-02-15 15:42:23
|
Hi, I'm trying to build the tests using gcc 4.4 on linux, and I can't seem to figure out what's going wrong. Running cmake works fine, and the boost libraries are all found correctly, but when I run make, it fails to link on the first test: Linking CXX executable ../../../build/tests/cpp-netlib-http_1_0_test /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status make[2]: *** [build/tests/cpp-netlib-http_1_0_test] Error 1 make[1]: *** [libs/network/test/CMakeFiles/cpp-netlib-http_1_0_test.dir/all] Error 2 make: *** [all] Error 2 My boost has everything built as shared libraries, so I've tried adding BOOST_TEST_DYN_LINK and BOOST_TEST_MAIN to CXXFLAGS, but that doesn't seem to have an effect. Any ideas? -- Gregory Symons <gs...@dr...> Developer DrillingInfo <http://www.drillinginfo.com> |
|
From: Dean M. B. <mik...@gm...> - 2011-02-15 17:17:57
|
Hi Gregory, On Tue, Feb 15, 2011 at 11:42 PM, Gregory Symons <gs...@dr...> wrote: > Hi, > > I'm trying to build the tests using gcc 4.4 on linux, and I can't seem > to figure out what's going wrong. Running cmake works fine, and the > boost libraries are all found correctly, but when I run make, it fails > to link on the first test: > > Linking CXX executable ../../../build/tests/cpp-netlib-http_1_0_test > /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o: In function > `_start': > (.text+0x20): undefined reference to `main' > collect2: ld returned 1 exit status > make[2]: *** [build/tests/cpp-netlib-http_1_0_test] Error 1 > make[1]: *** > [libs/network/test/CMakeFiles/cpp-netlib-http_1_0_test.dir/all] Error 2 > make: *** [all] Error 2 > > My boost has everything built as shared libraries, so I've tried adding > BOOST_TEST_DYN_LINK and BOOST_TEST_MAIN to CXXFLAGS, but that doesn't > seem to have an effect. > > Any ideas? > Actually, currently the unit tests require that Boost.Test be linked in statically. I haven't added in the capability for configuring the testing system through CMake to accept these or additional settings. HTH -- Dean Michael Berris about.me/deanberris |
|
From: Gregory S. <gs...@dr...> - 2011-02-15 17:38:41
|
On Wed, 2011-02-16 at 01:17 +0800, Dean Michael Berris wrote: > Hi Gregory, > > On Tue, Feb 15, 2011 at 11:42 PM, Gregory Symons [snip] > > > > My boost has everything built as shared libraries, so I've tried adding > > BOOST_TEST_DYN_LINK and BOOST_TEST_MAIN to CXXFLAGS, but that doesn't > > seem to have an effect. > > > > Any ideas? > > > > Actually, currently the unit tests require that Boost.Test be linked > in statically. > > I haven't added in the capability for configuring the testing system > through CMake to accept these or additional settings. That would explain it. I'm not terribly familiar with CMake, and looking through the FindBoost documentation, I didn't see an easy way to determine that things should be dynamically linked. After hacking CMakelists.txt to have the BOOST_TEST_DYN_LINK in the compile flags, I was able to get everything to build. But I'm pretty sure that's not the "right" way to do it. Once they built, I had several test failures: The following tests FAILED: 14 - cpp-netlib-hello_world (Failed) 15 - cpp-netlib-http_async_server (Failed) 16 - cpp-netlib-http_server_async_less_copy (Failed) 17 - mime-roundtrip (Failed) Looking closely at the verbose test output, it looks like they all failed because the address they were trying to bring up the server on was still in use. -- Gregory Symons <gs...@dr...> Developer DrillingInfo <http://www.drillinginfo.com> |
|
From: Dean M. B. <mik...@gm...> - 2011-02-15 17:57:11
|
On Wed, Feb 16, 2011 at 1:38 AM, Gregory Symons <gs...@dr...> wrote: > On Wed, 2011-02-16 at 01:17 +0800, Dean Michael Berris wrote: >> Hi Gregory, >> >> On Tue, Feb 15, 2011 at 11:42 PM, Gregory Symons > [snip] >> > >> > My boost has everything built as shared libraries, so I've tried adding >> > BOOST_TEST_DYN_LINK and BOOST_TEST_MAIN to CXXFLAGS, but that doesn't >> > seem to have an effect. >> > >> > Any ideas? >> > >> >> Actually, currently the unit tests require that Boost.Test be linked >> in statically. >> >> I haven't added in the capability for configuring the testing system >> through CMake to accept these or additional settings. > > That would explain it. I'm not terribly familiar with CMake, and looking > through the FindBoost documentation, I didn't see an easy way to > determine that things should be dynamically linked. After hacking > CMakelists.txt to have the BOOST_TEST_DYN_LINK in the compile flags, I > was able to get everything to build. But I'm pretty sure that's not the > "right" way to do it. > Well, that would one way to do it -- but there's a more generic way which should allow users to define variables on the cmake command-line to give more information to cmake and allow the generated build files to contain the correct directives. That requires some cmake kung fu that I haven't the time to deal with yet. ;) > Once they built, I had several test failures: > > The following tests FAILED: > 14 - cpp-netlib-hello_world (Failed) > 15 - cpp-netlib-http_async_server (Failed) > 16 - cpp-netlib-http_server_async_less_copy (Failed) > 17 - mime-roundtrip (Failed) > > Looking closely at the verbose test output, it looks like they all > failed because the address they were trying to bring up the server on > was still in use. > Yes, which since you've mentioned you're on Ubuntu, is actually expected. I haven't found a solution to this problem yet though, feedback and suggestions would be most appreciated. Short of installing a signal handler on the server code (which would not be easy to make cross-platform), I don't see a way to make this easily done unless I use different ports for each server (or take the port as an argument on the command-line). Pull requests for those would be greatly appreciated. :D Thanks Gregory for reporting! :) -- Dean Michael Berris about.me/deanberris |
|
From: Oleg M. <ole...@gm...> - 2011-02-16 02:39:10
Attachments:
socket_reuse_address.patch
|
On 16.02.2011 03:38, Gregory Symons wrote: > The following tests FAILED: > 14 - cpp-netlib-hello_world (Failed) > 15 - cpp-netlib-http_async_server (Failed) > 16 - cpp-netlib-http_server_async_less_copy (Failed) > 17 - mime-roundtrip (Failed) > > Looking closely at the verbose test output, it looks like they all > failed because the address they were trying to bring up the server on > was still in use. > Will you please try it with the following patch? -- Best regards, Oleg Malashenko. |
|
From: Dean M. B. <mik...@gm...> - 2011-02-16 02:52:00
|
On Wed, Feb 16, 2011 at 10:38 AM, Oleg Malashenko <ole...@gm...> wrote: > On 16.02.2011 03:38, Gregory Symons wrote: >> The following tests FAILED: >> 14 - cpp-netlib-hello_world (Failed) >> 15 - cpp-netlib-http_async_server (Failed) >> 16 - cpp-netlib-http_server_async_less_copy (Failed) >> 17 - mime-roundtrip (Failed) >> >> Looking closely at the verbose test output, it looks like they all >> failed because the address they were trying to bring up the server on >> was still in use. >> > > Will you please try it with the following patch? > Why isn't this a pull request Oleg? :D -- Dean Michael Berris about.me/deanberris |
|
From: Oleg M. <ole...@gm...> - 2011-02-16 03:28:43
Attachments:
socket_reuse_address-v2.patch
|
On 16.02.2011 12:46, Dean Michael Berris wrote: > On Wed, Feb 16, 2011 at 10:38 AM, Oleg Malashenko > <ole...@gm...> wrote: >> On 16.02.2011 03:38, Gregory Symons wrote: >>> The following tests FAILED: >>> 14 - cpp-netlib-hello_world (Failed) >>> 15 - cpp-netlib-http_async_server (Failed) >>> 16 - cpp-netlib-http_server_async_less_copy (Failed) >>> 17 - mime-roundtrip (Failed) >>> >>> Looking closely at the verbose test output, it looks like they all >>> failed because the address they were trying to bring up the server on >>> was still in use. >>> >> >> Will you please try it with the following patch? >> > > Why isn't this a pull request Oleg? :D > Because I don't know if it is going to work. In fact, terminating test applications is not the best way to close network sockets (see http_server_async_less_copy). If test suite doesn't actually try to run several tests simultaneously and they all try bind to the same port, than I think we hit TIME_WAIT problem here. http://hea-www.harvard.edu/~fine/Tech/addrinuse.html Oh, and Gregory, I almost forgot about sync server. Here is the new patch, that sets SO_REUSEADDR in sync_server as well as in async_server. -- Best regards, Oleg Malashenko. |
|
From: Dean M. B. <mik...@gm...> - 2011-02-16 03:59:38
|
On Wed, Feb 16, 2011 at 11:28 AM, Oleg Malashenko <ole...@gm...> wrote: > On 16.02.2011 12:46, Dean Michael Berris wrote: >> On Wed, Feb 16, 2011 at 10:38 AM, Oleg Malashenko >> <ole...@gm...> wrote: >>> On 16.02.2011 03:38, Gregory Symons wrote: >>>> The following tests FAILED: >>>> 14 - cpp-netlib-hello_world (Failed) >>>> 15 - cpp-netlib-http_async_server (Failed) >>>> 16 - cpp-netlib-http_server_async_less_copy (Failed) >>>> 17 - mime-roundtrip (Failed) >>>> >>>> Looking closely at the verbose test output, it looks like they all >>>> failed because the address they were trying to bring up the server on >>>> was still in use. >>>> >>> >>> Will you please try it with the following patch? >>> >> >> Why isn't this a pull request Oleg? :D >> > > Because I don't know if it is going to work. Actually, you're right. It won't work... > In fact, terminating test > applications is not the best way to close network sockets (see > http_server_async_less_copy). If test suite doesn't actually try to run > several tests simultaneously and they all try bind to the same port, > than I think we hit TIME_WAIT problem here. > http://hea-www.harvard.edu/~fine/Tech/addrinuse.html > ... because there's no cross-platform reliable way to run the test from Python and tell the spawned process to die -- unless you want to deal with pipes and all that (not-so-)goodness. Unless someone wants to maintain a signal handler for Windows and various flavors of Unix just for the test servers (I don't), it's better to have the port be a runtime parameter to the application, and use one port for each test. Also maybe making a test-specific "kill handler", like a special URL that would actually trigger a call to a server's stop method would be a good way to do it. Even then though the TIMED_WAIT problem would still be there on the server port in which case we'll still need the runtime port number option. > Oh, and Gregory, I almost forgot about sync server. Here is the new > patch, that sets SO_REUSEADDR in sync_server as well as in async_server. > This will only work if it's the same binary trying to re-use the address. In 0.9-devel I already have this as a constructor parameter. Also, this has some serious weirdness on Windows too as reported by Erik a while back -- which is why the SO_REUSEADDR setting was removed from the server core and moved into a Boost.Parameter option in 0.9-devel. HTH -- Dean Michael Berris about.me/deanberris |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X