Investigating the problems reported by users running build-gnuradio on
Ubuntu, I was able to reproduce on Fedora 14 as well!
The ‘configure’ portion has problems:
./configure: line 17496: test: too many arguments
./configure: line 17496: test: too many arguments
./configure: line 17496: test: too many arguments
./configure: line 17496: test: too many arguments
./configure: line 17496: test: too many arguments
./configure: line 17496: test: too many arguments
./configure: line 17496: test: too many arguments
./configure: line 17496: test: too many arguments
./configure: line 17496: test: too many arguments
./configure: line 17496: test: too many arguments
./configure: line 17496: test: too many arguments
./configure: line 17496: test: too many arguments
./configure: line 17496: test: too many arguments
./configure: line 17496: test: too many arguments
./configure: line 17496: test: too many arguments
./configure: line 17502: test: too many arguments
./configure: line 17502: test: too many arguments
./configure: line 17502: test: too many arguments
./configure: line 17502: test: too many arguments
./configure: line 17502: test: too many arguments
./configure: line 17502: test: too many arguments
./configure: line 17502: test: too many arguments
./configure: line 17502: test: too many arguments
./configure: line 17502: test: too many arguments
./configure: line 17502: test: too many arguments
./configure: line 17502: test: too many arguments
./configure: line 17502: test: too many arguments
./configure: line 17502: test: too many arguments
./configure: line 17502: test: too many arguments
./configure: line 17502: test: too many arguments
On Sat, Sep 3, 2011 at 6:19 PM, Marcus D. Leech [email protected]
wrote:
./configure: line 17496: test: too many arguments
./configure: line 17502: test: too many arguments
./configure: line 17502: test: too many arguments
libgnuradio-uhd.la -rpath /usr/local/lib64 gr_uhd_usrp_source.lo
.libs/gr_uhd_amsg_source.o -Wl,-rpath
-Wl,/home/mleech/gnuradio/**gnuradio-core/src/lib/.libs
-lusb-1.0 -L/usr/lib/gcc/x86_64-redhat-**linux/4.5.1
/usr/bin/ld: cannot find -l/usr/lib64/libboost_system-**mt.so
make[3]: Leaving directory `/home/mleech/gnuradio/gr-uhd’
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org
Those configure warnings aren’t a problem. They’ve been there for a
while. I
haven’t bothered to correct it since it’s not an actual problem; it’s
just
ugly, and we’ll fix it when we can.
The error you’re getting, however, is strange. I’ve been built
everything
from scratch in maint, master, and next this past week on ubuntu 10.04
and
11.04 and haven’t had a problem.
Anyone else having issues? I’m on a mini vacation this weekend, so no
real
time to look into this closely until Monday.
./configure: line 17496: test: too many arguments
./configure: line 17496: test: too many arguments
./configure: line 17502: test: too many arguments
-l/usr/lib64/libboost_program_options-mt.so
-Wl,/home/mleech/gnuradio/gruel/src/lib/.libs
-l/usr/lib64/libboost_system-mt.so
/usr/bin/ld: cannot find -l/usr/lib64/libboost_date_time-mt.so
make[5]: *** [libgnuradio-uhd.la <http://libgnuradio-uhd.la>] Error 1
Anyone else having issues? I’m on a mini vacation this weekend, so no
real time to look into this closely until Monday.
Tom
Well, I just did a fresh “git clone”, and the usual
bootstrap/configure/make, and it’s still flaking out, on my F14 system.
I’ll note that the error given indicates some kind of weirdness in the
the generated Makefiles, since it’s unusual (and not, as far as I can
tell,
even legal) to specify a full pathname in the -l option to ‘ld’. So something is probably generating borked Makefiles.
/usr/bin/ld: cannot find -l/usr/lib64/libboost_unit_test_framework-mt.so
This looks suspiciously like the contents of Libs.private which I added
to the uhd.pc file in 31cdaa9feb4009885d8b4e90d5fddff3565a9257
Can edit the uhd.pc file and remove the Libs.private and see if that
makes this build issue go away?
/usr/bin/ld: cannot find -l/usr/lib64/libboost_unit_test_framework-mt.so
This looks suspiciously like the contents of Libs.private which I added
to the uhd.pc file in 31cdaa9feb4009885d8b4e90d5fddff3565a9257
Can edit the uhd.pc file and remove the Libs.private and see if that
makes this build issue go away?
-josh
That appears to be exactly the cause! And would explain why
rolling-back my local gnuradio clone to before 2011-08-22 had no
effect, since it was caused by pkg-config (via the
autoconf/automake/configure chain) putting all that extra (and wrong)
goop
into UHD_LIBS.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
That appears to be exactly the cause! And would explain why
rolling-back my local gnuradio clone to before 2011-08-22 had no
effect, since it was caused by pkg-config (via the
autoconf/automake/configure chain) putting all that extra (and wrong) goop
into UHD_LIBS.
It looks like autotools is sucking Libs.private and Requires.private
to determine the flags. Is that the correct behavior?
I suppose that its up the build system, but on your platform (most linux
i assume), explicit linking of nested dependencies isnt needed. So that
why I think the pc files *.private stuff should be left out in this
case.
The contents of Boost_LIBRARIES was being dumped into the pc file,
but thats not actually correct w/o some “sanitizing”. For now, I have
removed that part and pushed the change to uhd master.
The build script should be fine again w/ regards to uhd.
I suppose that its up the build system, but on your platform (most linux
i assume), explicit linking of nested dependencies isnt needed. So that
why I think the pc files *.private stuff should be left out in this case.
It looks like the autotools emit the --static option on pkg-config
–libs, which
will always include the Libs.private stuff from the .pc file, it
seems.
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
On Sun, Sep 4, 2011 at 12:37 AM, Marcus D. Leech [email protected]
wrote:
It looks like autotools is sucking Libs.private and Requires.private
will always include the Libs.private stuff from the .pc file, it seems.
Glad that’s been cleared up for now. With the conference coming up and
everything else I need to do, this is going to have to go onto the stack
for
now. Might wait until we see about the cmake switch-over, too, before
revisting these issues and working them out.
Tom
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.