I reinstalled gnuradio under cygwin from scratch, using the latest
subversion trunk.
Following http://gnuradio.org/trac/wiki/CygwinInstallMain, I
built/installed a minimal gnuradio setup, and that worked fine.
Then I tried to add a few extra parts of gnuradio (usrp, mblock, gpio,
etc.) and ran into what looks like a linker problem involving
inband/mblock code (possibly also involving boost?)
build log & build error file are attached…any ideas/workarounds?
On Fri, May 23, 2008 at 4:51 PM, Steven C. [email protected]
wrote:
I reinstalled gnuradio under cygwin from scratch, using the latest
subversion trunk.
Following http://gnuradio.org/trac/wiki/CygwinInstallMain, I
built/installed a minimal gnuradio setup, and that worked fine.
Then I tried to add a few extra parts of gnuradio (usrp, mblock, gpio,
etc.) and ran into what looks like a linker problem involving
inband/mblock code (possibly also involving boost?)
build log & build error file are attached…any ideas/workarounds?
Bump in case my email got lost in the weekend shuffle. The first error
encountered is:
.libs/qa_inband_usrp_server.o: In function
_ZN5boost6detail17sp_counted_impl_pI12qa_alloc_topE11get_deleterERKSt9type_info': /usr/include/boost-1_33_1/boost/detail/sp_counted_impl.hpp:(.text+0x9b): undefined reference to
mb_mblock::~mb_mblock()’
Any thoughts?
Steven C. wrote:
build log & build error file are attached…any ideas/workarounds?
Bump in case my email got lost in the weekend shuffle. The first error
encountered is:
.libs/qa_inband_usrp_server.o: In function
_ZN5boost6detail17sp_counted_impl_pI12qa_alloc_topE11get_deleterERKSt9type_info': /usr/include/boost-1_33_1/boost/detail/sp_counted_impl.hpp:(.text+0x9b): undefined reference to
mb_mblock::~mb_mblock()’
It looks like you are missing a patch (attachment:"makefiles6975.patch,
listed on the Cywin wiki page) needed to include the mblock library in
the
link of qa_inband_usrp_server.
– Don W.
On Tue, May 27, 2008 at 12:31:46PM -0400, Don W. wrote:
etc.) and ran into what looks like a linker problem involving
undefined reference to `mb_mblock::~mb_mblock()’
It looks like you are missing a patch (attachment:"makefiles6975.patch,
listed on the Cywin wiki page) needed to include the mblock library in the
link of qa_inband_usrp_server.
– Don W.
Thanks Don.
FYI, we haven’t applied this patch to the trunk because the real
problem is with libtool under cygwin. The patch replicates
information (always a bad idea) that libtool already knows on all
other systems.
Eric
On Tue, May 27, 2008 at 04:24:55PM -0400, Steven C. wrote:
It looks like you are missing a patch (attachment:"makefiles6975.patch,
listed on the Cywin wiki page) needed to include the mblock library in the
link of qa_inband_usrp_server.
– Don W.
Thanks for the reply. I did in fact try to apply both patches that are
mentioned on the page, but I think I may have done so incorrectly:
I suspect that they’re out of date.
We merged a lot of inband stuff into the trunk about a month ago.
Eric
It looks like you are missing a patch (attachment:"makefiles6975.patch,
listed on the Cywin wiki page) needed to include the mblock library in the
link of qa_inband_usrp_server.
– Don W.
Thanks for the reply. I did in fact try to apply both patches that are
mentioned on the page, but I think I may have done so incorrectly:
Administrator@AAZ042 ~/gnuradio
$ patch -p0 -b -i makefiles-3.1.2.patch
The next patch would create the file bootstrap,
which already exists! Assume -R? [n] n
Apply anyway? [n] y
patching file bootstrap
Patch attempted to create file bootstrap, which already exists.
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED – saving rejects to file bootstrap.rej
patching file Makefile.common
Hunk #1 succeeded at 65 (offset 8 lines).
Administrator@AAZ042 ~/gnuradio
$ patch -p0 -b -i makefiles6975.patch
patching file usrp/host/lib/inband/Makefile.am
Hunk #1 succeeded at 63 (offset -2 lines).
Hunk #2 FAILED at 104.
1 out of 2 hunks FAILED – saving rejects to file
usrp/host/lib/inband/Makefile.am.rej
patching file Makefile.common
Hunk #1 FAILED at 67.
1 out of 1 hunk FAILED – saving rejects to file Makefile.common.rej
patching file mblock/src/lib/Makefile.am
Hunk #1 succeeded at 131 (offset 1 line).
Are the patches out of date, or am I doing something wrong? I am not
very familiar with the patch command.
Eric B. wrote:
– Don W.
Thanks Don.
FYI, we haven’t applied this patch to the trunk because the real
problem is with libtool under cygwin. The patch replicates
information (always a bad idea) that libtool already knows on all
other systems.
Good news: libtool 2.2.2 is now available on Cygwin and seems to handle
the
interlibrary dependencies.
Bad news: (a) using the new libtool requires running bootstrap (to get
new
ltmain.sh, libtool.m4, …?), so it still requires a patch (to add
bootstrap) to work with the current release; and (b) autoconf (and/or
libtoolize?) produce a number of warnings, such as “LT_OUTPUT was called
before LT_LANG”. (I think there are some compatibility issues, but I
haven’t found any simple documentation on them yet.)
Unknowns: I don’t know if libtool 2.x runs on MinGW, and I haven’t
tried it
on Debian (to see if it gets the same warning messages).
– Don W.
On Thu, May 29, 2008 at 05:47:32PM -0400, Don W. wrote:
link of qa_inband_usrp_server.
other systems.
Unknowns: I don’t know if libtool 2.x runs on MinGW, and I haven’t tried
it on Debian (to see if it gets the same warning messages).
– Don W.
That’s great news. FWIW, the next release will have bootstrap
included in the tarballs.
Eric
Steven C. wrote:
mentioned on the page, but I think I may have done so incorrectly:
patching file Makefile.common
Hunk #1 succeeded at 65 (offset 8 lines).
This patch is needed for the 3.1.2 release, not for the svn version.
patching file mblock/src/lib/Makefile.am
Hunk #1 succeeded at 131 (offset 1 line).
Eric is correct; this patch worked at svn revision 6975, but doesn’t
work
now because of updates to the trunk. But if you look at the listing of
the
patch, you can see that it adds three lines to
usrp/host/lib/inband/Makefile.am, one of which has been added in the
trunk
since the patch was developed. The quickest solution is to edit the
file by
hand to include lines added by the patch. I should get around to
producing
an updated patch in a day or two.
– Don W.