Hi all, does anyone else get this error message when compiling
GnuRadio? This is with latest code from today’s master git tree, on
Ubuntu 11.04, boost 1.42
I can bypass this by manually adding -lboost_system -lboost_filesystem
make[7]: Entering directory `/home/azimout/gnuradio/gruel/src/lib’
/bin/bash …/…/…/libtool --tag=CXX --mode=link g++ -g -O2 -Wall
-Woverloaded-virtual -pthread -o test_gruel test_gruel.o
pmt/libpmt-qa.la libgruel.la -lltdl
libtool: link: g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o
.libs/test_gruel test_gruel.o pmt/.libs/libpmt-qa.a -L/usr/lib
-lboost_thread-mt /usr/lib/libcppunit.so -ldl ./.libs/libgruel.so
/usr/lib/libltdl.so -pthread
/usr/bin/ld: test_gruel.o: undefined reference to symbol
‘boost::system::get_system_category()’
/usr/bin/ld: note: ‘boost::system::get_system_category()’ is defined
in DSO /usr/lib64/libboost_system.so.1.42.0 so try adding it to the
linker command line
/usr/lib64/libboost_system.so.1.42.0: could not read symbols:
Invalid operation
Dimitrios S.
“If you think you’re too small to make a difference, try sleeping with
a mosquito!” - Amnesty International
On Wed, Mar 30, 2011 at 08:18, [email protected] [email protected]
wrote:
Hi all, does anyone else get this error message when compiling
GnuRadio? This is with latest code from today’s master git tree, on
Ubuntu 11.04, boost 1.42
I can bypass this by manually adding -lboost_system -lboost_filesystem
This looks like another instance of the new Debian DSO linking policy
show us where we’ve been making assumptions in our linker commands.
Your fix is correct; we’ll need to figure out how to put it in the
appropriate Makefile.am.
Here we’ve been sticking to the Ubuntu 10.04 LTS release for most of
our development and testing. Looks like we need to add 10.10 and
11.04 VMs to the build farm so we can start catching this earlier.
Johnathan
On Wed, Mar 30, 2011 at 11:18 AM, [email protected]
[email protected]wrote:
Hi all, does anyone else get this error message when compiling
GnuRadio? This is with latest code from today’s master git tree, on
Ubuntu 11.04, boost 1.42
Oh come on! It’s still March, what are you doing on 11.04?
So this is the same problem that people running the latest Debian are
running into, and it’s basically based on a new policy for linking. They
are
being more strict, and we’ve been lazy.
I can bypass this by manually adding -lboost_system -lboost_filesystem
You’ve identified the solution. I will try to find time tonight to work
out
the right way to incorporate this into our build structure.
Tom
On Wed, Mar 30, 2011 at 11:59 AM, Johnathan C. <
[email protected]> wrote:
show us where we’ve been making assumptions in our linker commands.
Your fix is correct; we’ll need to figure out how to put it in the
appropriate Makefile.am.
Here we’ve been sticking to the Ubuntu 10.04 LTS release for most of
our development and testing. Looks like we need to add 10.10 and
11.04 VMs to the build farm so we can start catching this earlier.
Johnathan
Just a data point: one of my machines runs 10.10 without this problem
(unless it’s a brand new update). I think this has been introduced in
11.04.
Tom
On Wed, Mar 30, 2011 at 6:07 PM, Tom R. [email protected]
wrote:
I can bypass this by manually adding -lboost_system -lboost_filesystem
Johnathan
Just a data point: one of my machines runs 10.10 without this problem
(unless it’s a brand new update). I think this has been introduced in 11.04.
Tom
I haven’t seen this issue on Ubuntu 10.10 either, but I think this
policy is being introduced in other distributions as well, e.g.
https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking
Alex
Thanks guys. Here’s the latest update on errors and solutions:
==========================
gruel/src/lib needs:
-lboost_system -lboost_filesystem
gr-usrp/apps needs:
…/…/gnuradio-core/src/lib/.libs/libgnuradio-core-3.4.0git.so.0
…/…/usrp/host/lib/.libs/libusrp-3.4.0git.so.0
(twice: both for usrp_rx_cfile and for usrp_siggen)
gr-gsm-fr-vocoder/src/lib:
make[7]: Entering directory
/home/azimout/gnuradio/gr-gsm-fr-vocoder/src/lib' make[7]: *** No rule to make targetgsm_full_rate.cc’, needed by
`_gsm_full_rate_la-gsm_full_rate.lo’. Stop.
==========================
Dimitrios S.
“If you think you’re too small to make a difference, try sleeping with
a mosquito!” - Amnesty International
On 31-03-11 11:54, [email protected] wrote:
(twice: both for usrp_rx_cfile and for usrp_siggen)
Tom, when are you going to apply my patch?
Gr. Sim
Correction:
Distro GCC binutils
Ubuntu 10.04 4.4 2.20
Ubuntu 10.10 4.4 2.20
Ubuntu 11.04 4.5 2.21
Fedora 15 4.6 2.21
What I’m saying is, 10.04 == 10.10, so you shouldn’t see much
difference (only boost went from 1.40 to 1.42), but you should see
some errors in 11.04 and even more in Fedora 15
Dimitrios S.
“If you think you’re too small to make a difference, try sleeping with
a mosquito!” - Amnesty International
PS
Distro GCC binutils
Ubuntu 10.04 4.4 2.21
Ubuntu 10.10 4.4 2.20
Ubuntu 11.04 4.5 2.21
Fedora 15 4.6 2.21
Dimitrios S.
“If you think you’re too small to make a difference, try sleeping with
a mosquito!” - Amnesty International
Four more errors of the same type (no rule to make xyz). The work
arounds are obviously not the solution, but I have no time to look
into this more deeply:
gr-gsm-fr-vocoder/src/lib needs:
ln -s {python/,}gsm_full_rate.cc
gr-noaa/swig needs:
ln -s {python/,}noaa_swig.cc
gr-trellis/src/lib needs:
ln -s {python/,}trellis.cc
gr-video-sdl/src needs:
ln -s {python/,}video_sdl.cc
Dimitrios S.
“If you think you’re too small to make a difference, try sleeping with
a mosquito!” - Amnesty International
On 31-03-11 11:54, [email protected] wrote:
Thanks guys. Here’s the latest update on errors and solutions:
gr-usrp/apps needs:
…/…/gnuradio-core/src/lib/.libs/libgnuradio-core-3.4.0git.so.0
…/…/usrp/host/lib/.libs/libusrp-3.4.0git.so.0
(twice: both for usrp_rx_cfile and for usrp_siggen)
This problem should be solved when you have applied the patch i posted
in:
Re: [Discuss-gnuradio] compiling gnuradio with gcc-4.5
On Thu, Mar 31, 2011 at 06:01, [email protected] [email protected]
wrote:
Four more errors of the same type (no rule to make xyz). The work
arounds are obviously not the solution, but I have no time to look
into this more deeply:
This sounds like something different from the DSO linking issue.
Johnathan
On Thu, Mar 31, 2011 at 06:09, Sim IJskes [email protected] wrote:
This problem should be solved when you have applied the patch i posted in:
Thanks for your patch; it shows how to correct the problem in one area.
Tom and I are trying to work out how to solve this in a more general
way so it doesn’t require as many individual edits to Makefile.am
linker flags definitions in the different places the problem occurs.
Part of the delay as well is for me to setup the appropriate test
environment to both verify the problem and regression test the fixes.
For those just joining, what’s happened is that the Debian project
(and hence Ubuntu and other derivatives) has finally pulled the
trigger on a change in linking options:
http://wiki.debian.org/ToolChain/DSOLinking
…and in several places in our build we are relying on the old
behavior.
The Fedora project has also done this (thanks Alex for the link):
https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking
Tom–this is also going to affect 3.3.1. We might as well fix things
on the old master-3.3 branch and merge up to the current master, then
produce a 3.3.2 alongside 3.4.0.
Johnathan
On 31-03-11 16:40, Johnathan C. wrote:
environment to both verify the problem and regression test the fixes.
OK, thats fine. No problem. I’m happy. No pressure! 
My patch did allow for a complete package build from the debian package
in git.gag.com based on the 3.3.1 branch. I’m not sure what was done
before i attempted to build an updated debian package. (I still need to
diff the git from gag.com with the 3.3.1 tag branch of gnuradio, there
are some changes that haven’t been applied to upstream yet).
I still have some python binding problems that need to be solved. I will
try to work on that soon. Maybe i can find a way to backport only the
linking fixes to 3.3.1-debian.
Gr. Sim
I have been able to work on this tonight, and I think the solution is
that
we just needed to be more specific in our LDADDs in a few places.
Mostly,
it’s where we are building programs (noinst_PROGRAMS = xxxx), but we
were
only passing an LDADD of a few libraries and not everything. I was
wondering
if there wasn’t something more globally we could do, but I’m not sure
that’s
necessary.
Johnathan and I will work on applying these changes where necessary
tomorrow. In the meantime, the patch attached to the end of this email
was
what I needed to do in order to build under Ubuntu 11.04 beta.
On Thu, Mar 31, 2011 at 9:01 AM, [email protected]
[email protected]wrote:
gr-trellis/src/lib needs:
ln -s {python/,}trellis.cc
gr-video-sdl/src needs:
ln -s {python/,}video_sdl.cc
Dimitrios S.
I’m really confused why you would need to do this. What OS are you
working
on again?
Tom
PATCH (against current master):
diff --git a/gr-usrp/apps/Makefile.am b/gr-usrp/apps/Makefile.am
index 0f3a21b…c3955ad 100644
— a/gr-usrp/apps/Makefile.am
+++ b/gr-usrp/apps/Makefile.am
@@ -33,6 +33,8 @@
GR_USRP_LA=$(top_builddir)/gr-usrp/src/libgnuradio-usrp.la
For compiling outside the tree, these will get fished out by
pkgconfig
LDADD = \
diff --git a/gruel/src/lib/Makefile.am b/gruel/src/lib/Makefile.am
index f37ab27…773f3ae 100644
— a/gruel/src/lib/Makefile.am
+++ b/gruel/src/lib/Makefile.am
@@ -60,5 +60,9 @@ libgruel_la_LIBADD = \
----------------------------------------------------------------
test_gruel_SOURCES = test_gruel.cc
-test_gruel_LDADD = pmt/libpmt-qa.la libgruel.la
+test_gruel_LDADD = \