Forum: GNU Radio Build errors

E16be4811324adf8f26be26d77e9d29d?d=identicon&s=25 Robert McGwier (Guest)
on 2007-01-16 04:48
(Received via mailing list)
I am getting build errors on 3 different machines which heretofore have
worked perfectly.  It involves the pmt/mblock code.

The failure to build comes in the last step of building the libmblock.so
and libmblock-qa.so.   pmt_nth, pmt_intern,
pmt_wrong_type::pmt_wrong_type,   .... are all listed as undefined
references in the mblock library link statements and the build fails.
Is anyone else experiencing this and have you fixed it?

Eric and others are NOT experiencing this so I am trying to figure out
what is going wrong on my 3 Ubuntu 6.1 machines with the problem.


Bob



--
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
"If you board the wrong train, it is no use running along the
corridor in the other direction. " - Dietrich Bonhoeffer
Cec0a4bf0e0575f3a3171892e6097e59?d=identicon&s=25 Johnathan Corgan (Guest)
on 2007-01-16 04:54
(Received via mailing list)
On Mon, 2007-01-15 at 22:47 -0500, Robert McGwier wrote:

> Eric and others are NOT experiencing this so I am trying to figure out
> what is going wrong on my 3 Ubuntu 6.1 machines with the problem.

Just FYI, using Ubuntu 6.1 (32-bit) here with no issues.

--
Johnathan Corgan, AE6HO
Corgan Enterprises LLC
jcorgan@aeinet.com
8ed451a2cb11bd91872717754867fd12?d=identicon&s=25 Bob McGwier (Guest)
on 2007-01-16 17:25
(Received via mailing list)
Those machines I described,  all running Ubuntu 6.1 32bit,  exhibit the
problem.  This is 3 independent machines.  I svn fresh copies of the
source and did

./bootstrap;./configure --enable-doxygen;make

and the make fails on all three machines.   HP laptop,   Mini-ITX P4-HT,
and old dual Athlon-MP SMP machine.

Bob




Johnathan Corgan wrote:
> On Mon, 2007-01-15 at 22:47 -0500, Robert McGwier wrote:
>
>
>> Eric and others are NOT experiencing this so I am trying to figure out
>> what is going wrong on my 3 Ubuntu 6.1 machines with the problem.
>>
>
> Just FYI, using Ubuntu 6.1 (32-bit) here with no issues.
>
>


--
Robert W. McGwier, Ph.D.
Center for Communications Research
805 Bunn Drive
Princeton, NJ 08540
(609)-924-4600
(sig required by employer)
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-01-16 17:36
(Received via mailing list)
On Tue, Jan 16, 2007 at 11:24:55AM -0500, Robert W McGwier wrote:
> Those machines I described,  all running Ubuntu 6.1 32bit,  exhibit the
> problem.  This is 3 independent machines.  I svn fresh copies of the
> source and did
>
> ./bootstrap;./configure --enable-doxygen;make
>
> and the make fails on all three machines.   HP laptop,   Mini-ITX P4-HT,
> and old dual Athlon-MP SMP machine.
>
> Bob

Bob,

If you send me output from the set of command's I sent in the
off-list message I'll take a look at it.  I need more info to sort
this out.

Eric
69cb0c0b019771cbc7ee2d95065eafbb?d=identicon&s=25 Illix (Guest)
on 2007-01-17 23:46
(Received via mailing list)
I'm getting the same problem (as far as I can tell) on an Ubuntu
6.10machine.  The build fails with undefined references in
libmblock.so and libmblock-qa.so.

--Illix
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-01-18 03:13
(Received via mailing list)
On Wed, Jan 17, 2007 at 05:45:33PM -0500, Illix wrote:
> I'm getting the same problem (as far as I can tell) on an Ubuntu
> 6.10machine.  The build fails with undefined references in
> libmblock.so and libmblock-qa.so.
>


OK, I've looked at the log file that Bob sent me and compared it to
what I see on my machines.  The difference appears to be something in
libtool.

My machine (works):

/bin/sh ../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall
-Woverloaded-virtual -pthread   -o test_mblock  test_mblock.o
libmblock-qa.la libmblock.la
g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o .libs/test_mblock
test_mblock.o  ./.libs/libmblock-qa.so
/home/eb/gr/trunk/mblock/src/lib/.libs/libmblock.so
/usr/lib/libcppunit.so -ldl ./.libs/libmblock.so
/home/eb/gr/trunk/pmt/src/lib/.libs/libpmt.so /usr/lib/libstdc++.so


Bob's machine (doesn't work):

/bin/bash ../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall
-Woverloaded-virtual -pthread   -o test_mblock  test_mblock.o
libmblock-qa.la libmblock.la
g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o .libs/test_mblock
test_mblock.o  ./.libs/libmblock-qa.so ./.libs/libmblock.so -Wl,--rpath
-Wl,/usr/local/lib


Although they both make the same call to libtool, libtool spits out a
different command line on the two systems.  On Bob's (and I assume
Illix's) machine, the output of libtool contains --rpath (pointing to
the install, not build directory!), whereas my machine lists the
actual paths needed to find the pieces.

Bob's machine is using

  ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-4 (1.1220.2.365
2005/12/18 22:14:06)

I'm using (SuSE 10.1)

  ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06)

It looks like the Debian folks may have applied some kind of a patch to
libtool 1.5.22 that could be causing the problem.

Can any debian/ubuntu users figure out the difference?  That is,
what's the debian/ubuntu patch, and when and why was it applied?

Thanks,
Eric
E16be4811324adf8f26be26d77e9d29d?d=identicon&s=25 Robert McGwier (Guest)
on 2007-01-18 05:20
(Received via mailing list)
Agreed


Eric Blossom wrote:
> what I see on my machines.  The difference appears to be something in
> libtool.
>
>
>

---snip----
> Although they both make the same call to libtool, libtool spits out a
> different command line on the two systems.  On Bob's (and I assume
> Illix's) machine, the output of libtool contains --rpath (pointing to
> the install, not build directory!), whereas my machine lists the
> actual paths needed to find the pieces.
>
I did a test before I read this note.  I ran make install in the pmt
directory after the mblock make fails.  After this bandaid step,   if I
run make in the trunk directory,  the make succeeds.  I concur with your
analysis. Don't you hate these kinds of issues?

>
> Can any debian/ubuntu users figure out the difference?  That is,
> what's the debian/ubuntu patch, and when and why was it applied?
>
> Thanks,
> Eric
>
>

Bob


--
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
"Taking fun as simply fun and earnestness in earnest shows
how thoroughly thou none of the two discernest." - Piet Hine
3719f4fea703e38bcbf8de6fe6bcdf55?d=identicon&s=25 Martin Dvh (Guest)
on 2007-01-18 05:56
(Received via mailing list)
Robert McGwier wrote:
>>> libmblock.so and libmblock-qa.so.
>>
>
>>
>>   ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06)
>>
>> It looks like the Debian folks may have applied some kind of a patch to
>> libtool 1.5.22 that could be causing the problem.
>>
>> Can any debian/ubuntu users figure out the difference?  That is,
>> what's the debian/ubuntu patch, and when and why was it applied?
I found this on the debian buglist for libtool:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=320698
Message received at 320698@bugs.debian.org (full text, mbox):

From: Philip Martin <philip@codematters.co.uk>
To: Loïc Minier <lool@dooz.org>, 320698@bugs.debian.org
Subject: Re: Bug#320698: Debian-specific binary deps patch
Date: Thu, 06 Oct 2005 01:24:03 +0100

> It seems that Debian's libtool has a patch which will reduce
> dependencies in binaries it produces.

One of the knock-on effects of this patch is bug 291641 where ld
resolves symbols using installed libraries instead of libraries in the
build directory.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291641

Subversion 1.2 has a Build-Conflicts with Subversion 1.1 to avoid
this problem.


Greetings,
Martin
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-01-19 16:31
(Received via mailing list)
> >>
> Date: Thu, 06 Oct 2005 01:24:03 +0100
> Subversion 1.2 has a Build-Conflicts with Subversion 1.1 to avoid
> this problem.
>
>
> Greetings,
> Martin

Looks like this change is flat-out wrong.  It prevents anybody that's
building libraries _and_ executables in the same build from testing
them before installing them.

It also disables a feature specifically designed into libtool: the
ability to test before installation

http://www.gnu.org/software/libtool/manual.html#Li...


I agree that http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291641
describes a similar problem in January 2005.  It appears that we are
just now seeing a similar problem.  AFAIK ubuntu prior to 6.10 didn't
exhibit the problem.  They must have recently made some change.


Martin, or somebody else, can you say exactly how Ubuntu users should
work around this problem?  Can they just install libtool from Ubuntu
6.06?  When this is sorted out, can somebody please add directions to
the Ubuntu install wiki page?
http://gnuradio.org/trac/wiki/UbuntuInstall

Thanks,
Eric
0c86c3b09550eaad22e8a35a3a189672?d=identicon&s=25 Ralph A. Schmid, dk5ras (Guest)
on 2013-08-15 12:51
(Received via mailing list)
Hmm, it _was_ a new copy, last one one hour ago...or any changes since
then?


Ralph.



From: munncha@gmail.com [mailto:munncha@gmail.com] On Behalf Of Kurtis
Heimerl
Sent: Wednesday, 14 August, 2013 18:52
To: Ralph A. Schmid
Cc: openbts-discuss@lists.sourceforge.net; Kurtis Heimerl
Subject: Re: build errors



Try pulling a new copy of the repo, I'd guess you had conflicts merging
and
ignored them. For example, can you share lines 39-44 of SIPMessage.cpp?



On Wed, Aug 14, 2013 at 4:49 AM, Ralph A. Schmid <ralph@schmid.xxx>
wrote:

OK, this one from smqueue:

ras@dk5ras:~/public/smqueue/trunk$ make
make  all-recursive
make[1]: Entering directory `/home/ras/public/smqueue/trunk'
Making all in config
make[2]: Entering directory `/home/ras/public/smqueue/trunk/config'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/ras/public/smqueue/trunk/config'
Making all in sqlite3
make[2]: Entering directory `/home/ras/public/smqueue/trunk/sqlite3'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/ras/public/smqueue/trunk/sqlite3'
Making all in CommonLibs
make[2]: Entering directory `/home/ras/public/smqueue/trunk/CommonLibs'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/ras/public/smqueue/trunk/CommonLibs'
Making all in Globals
make[2]: Entering directory `/home/ras/public/smqueue/trunk/Globals'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/ras/public/smqueue/trunk/Globals'
Making all in SR
make[2]: Entering directory `/home/ras/public/smqueue/trunk/SR'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/ras/public/smqueue/trunk/SR'
Making all in GSM
make[2]: Entering directory `/home/ras/public/smqueue/trunk/GSM'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/ras/public/smqueue/trunk/GSM'
Making all in SMS
make[2]: Entering directory `/home/ras/public/smqueue/trunk/SMS'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/ras/public/smqueue/trunk/SMS'
Making all in doc
make[2]: Entering directory `/home/ras/public/smqueue/trunk/doc'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/ras/public/smqueue/trunk/doc'
Making all in tools
make[2]: Entering directory `/home/ras/public/smqueue/trunk/tools'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/ras/public/smqueue/trunk/tools'
Making all in smqueue
make[2]: Entering directory `/home/ras/public/smqueue/trunk/smqueue'
g++ -DHAVE_CONFIG_H -I. -I..  -D'SVN_REV="6173"' -I../CommonLibs
-I../GSM -
I../SMS -I../Globals -I../SR -I../sqlite3  -O3 -g -lpthread -g -O2 -MT
smcommands.o -MD -MP -MF .deps/smcommands.Tpo -c -o smcommands.o
smcommands.cpp
In file included from smqueue.h:36:0,
                 from smcommands.cpp:24:
smnet.h: In member function 'void SMqueue::SMnet::add_socket(int, short
int,
int, int, int, const sockaddr*, socklen_t)':
smnet.h:125:54: error: 'memcpy' was not declared in this scope
smnet.h:144:52: error: 'memcpy' was not declared in this scope
make[2]: *** [smcommands.o] Error 1
make[2]: Leaving directory `/home/ras/public/smqueue/trunk/smqueue'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/ras/public/smqueue/trunk'
make: *** [all] Error 2
ras@dk5ras:~/public/smqueue/trunk$



And this one from OpenBTS:


ras@dk5ras:~/public/openbts/trunk$ make
make  all-recursive
make[1]: Entering directory `/home/ras/public/openbts/trunk'
Making all in config
make[2]: Entering directory `/home/ras/public/openbts/trunk/config'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/ras/public/openbts/trunk/config'
Making all in sqlite3
make[2]: Entering directory `/home/ras/public/openbts/trunk/sqlite3'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/ras/public/openbts/trunk/sqlite3'
Making all in CommonLibs
make[2]: Entering directory `/home/ras/public/openbts/trunk/CommonLibs'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/ras/public/openbts/trunk/CommonLibs'
Making all in Globals
make[2]: Entering directory `/home/ras/public/openbts/trunk/Globals'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/ras/public/openbts/trunk/Globals'
Making all in SR
make[2]: Entering directory `/home/ras/public/openbts/trunk/SR'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/ras/public/openbts/trunk/SR'
Making all in CLI
make[2]: Entering directory `/home/ras/public/openbts/trunk/CLI'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/ras/public/openbts/trunk/CLI'
Making all in SIP
make[2]: Entering directory `/home/ras/public/openbts/trunk/SIP'
/bin/bash ../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I.
-I..
-D'SVN_REV="6173"'  -I../CommonLibs -I../Control -I../GSM -I../GPRS -
I../SGSNGGSN -I../SIP -I../SMS -I../TRXManager -I../Globals -I../CLI
-I../SR
-
I../Peering -I../sqlite3 -I  -I   -Wall -Wextra -g -O2 -MT SIPMessage.lo
-MD
-
MP -MF .deps/SIPMessage.Tpo -c -o SIPMessage.lo SIPMessage.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -DSVN_REV=\"6173\" -
I../CommonLibs -I../Control -I../GSM -I../GPRS -I../SGSNGGSN -I../SIP
-I../SMS
-I../TRXManager -I../Globals -I../CLI -I../SR -I../Peering -I../sqlite3
-I
-I
-Wall -Wextra -g -O2 -MT SIPMessage.lo -MD -MP -MF .deps/SIPMessage.Tpo
-c
SIPMessage.cpp  -fPIC -DPIC -o .libs/SIPMessage.o
SIPMessage.cpp: In function 'void
openbts_message_init(osip_message_t**)':
SIPMessage.cpp:39:44: error: expected ',' or ';' before 'VERSION'
SIPMessage.cpp: In function 'osip_message_t*  <SIP::sip_message(const>
SIP::sip_message(const char*,
const char*, short int, const char*, const char*, const char*, const
char*,
const char*, int, const char*, const char*)':
SIPMessage.cpp:332:39: warning: format '%u' expects argument of type
'unsigned
int', but argument 3 has type 'size_t {aka long unsigned int}'
[-Wformat]
SIPMessage.cpp: At global scope:
SIPMessage.cpp:667:18: warning: unused parameter 'proxy_ip' [-Wunused-
parameter]
SIPMessage.cpp:1027:18: warning: unused parameter 'sip_username'
[-Wunused-
parameter]
SIPMessage.cpp:1027:18: warning: unused parameter 'local_ip' [-Wunused-
parameter]
SIPMessage.cpp:1070:18: warning: unused parameter 'rtp_port' [-Wunused-
parameter]
make[2]: *** [SIPMessage.lo] Error 1
make[2]: Leaving directory `/home/ras/public/openbts/trunk/SIP'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/ras/public/openbts/trunk'
make: *** [all] Error 2
ras@dk5ras:~/public/openbts/trunk$
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.