Build errors

GNU Radio
1

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

2

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 C., AE6HO
Corgan Enterprises LLC
[email protected]

3

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 C. 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)

4

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

5

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

6

Agreed

Eric B. 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

7

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 [email protected] (full text, mbox):

From: Philip M. [email protected]
To: Loïc Minier [email protected], [email protected]
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

8

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

9

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#Linking-executables

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

10

Hmm, it was a new copy, last one one hour ago…or any changes since
then?

Ralph.

From: [email protected] [mailto:[email protected]] On Behalf Of Kurtis
Heimerl
Sent: Wednesday, 14 August, 2013 18:52
To: Ralph A. Schmid
Cc: [email protected]; 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 [email protected]
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$