[libRETS-users] Installing on Ubuntu 12.04 64 bit

284 views
Skip to first unread message

Thomas Hibbard

unread,
Oct 19, 2012, 1:05:55 PM10/19/12
to libret...@crt.realtors.org
Has anyone had any difficulties getting librets to compile on Ubuntu 12.04 x64? I've compiled before with no real issues on previous 32 bit versions but this is the first 64 bit install I've tried it on. Here's the error I'm getting:

/usr/bin/ld: /usr/lib/libexpat.a(xmlparse.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/lib/libexpat.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
error: command 'g++' failed with exit status 1
make[1]: *** [build/swig/python/_librets.so] Error 1
make[1]: Leaving directory `/home/env/cwh/build/librets/librets-1.5.3'
make: *** [all] Error 2

My configuration options are as follows:
./configure --enable-shared_dependencies --disable-perl

If anyone has any suggestions I'd appreciate it.

Thanks,
Thomas
_______________________________________________
libRETS-users mailing list
libRET...@crt.realtors.org
http://mail.crt.realtors.org/mailman/listinfo/librets-users

Keith T. Garner

unread,
Oct 19, 2012, 2:11:10 PM10/19/12
to For discussion and help for and by the users of the libRETS C++ library
The big problem here is that you're trying to link against the expat static library, which isn't compiled with -fPIC. FOr some reason it looks like --enable-shared_dependencies didn't work. Can you show some the output of configure as well as some more lines of the compilation before the failure?
--
Keith T. Garner - kga...@realtors.org - 312-329-3294 - http://realtor.org/
National Association of REALTORS® - VP - Information Technology Services

Keith T. Garner

unread,
Oct 19, 2012, 2:16:18 PM10/19/12
to For discussion and help for and by the users of the libRETS C++ library
I just did a test build on my x86_64 12.04 box and haven't been able to recreate your issue. (After I installed all the dependency packages, that is. I hadn't done librets dev since I reinstalled it a few months ago.)

Thomas Hibbard

unread,
Oct 19, 2012, 4:15:39 PM10/19/12
to For discussion and help for and by the users of the libRETS C++ library
Here's the output from my attempted build this afternoon:


(cwh)vicad@app:/home/env/cwh/build/librets/librets-1.5.3$ ./configure --enable-shared_dependencies --disable-perl
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for ranlib... ranlib
checking for ar... ar
checking for csc... no
checking for perl... perl
checking librets version... 1.5.3
checking for doxygen... no
checking for curl >= 7.18.2... 7.22.0
checking for /usr/include/expat.h... yes
checking for XML_ParserCreate in -lexpat... yes
checking for /usr/include/boost/version.hpp... yes
checking for boost >= 1_44... 1_46_1
checking for /usr/include/boost/system/system_error.hpp... yes
checking for java... java
checking for antlr... antlr
checking whether linking with -lantlr in /usr works... yes
checking for cppunit-config... no
checking for swig... swig
checking for swig >= 1.3.33... 2.0.4
checking for mcs... no
checking for gmcs... no
checking for csc... (cached) no
checking for java... java
checking for javac... no
checking for php... php
checking for /usr/php/main/php.h... no
checking for /usr/php/Zend/zend.h... no
checking for /usr/include/php/main/php.h... no
checking for /usr/include/php/Zend/zend.h... no
checking for /usr/local/php/main/php.h... no
checking for /usr/local/php/Zend/zend.h... no
checking for /usr/local/include/php/main/php.h... no
checking for /usr/local/include/php/Zend/zend.h... no
checking for /opt/php/main/php.h... no
checking for /opt/php/Zend/zend.h... no
checking for /opt/include/php/main/php.h... no
checking for /opt/include/php/Zend/zend.h... no
checking for /opt/local/php/main/php.h... no
checking for /opt/local/php/Zend/zend.h... no
checking for /opt/local/include/php/main/php.h... no
checking for /opt/local/include/php/Zend/zend.h... no
checking for python... python
checking for /home/env/cwh/include/python2.7/Python.h... yes
checking for ruby... no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating project/build/Doxyfile
config.status: creating librets-config
config.status: creating librets-config-inplace
config.status: creating project/librets/src/config.h

Option summary:

Use ccache .................: no
Use dependency checking ....: no
Use -fPIC...................: yes
Use shared dependencies.....: yes
Compile type................: Normal
Compile examples............: no
Compile SQL compiler........: yes
Compile SWIG bindings.......: yes
With DotNet...............: no
With Java.................: no
With PERL.................: no
With PHP..................: no
With Python...............: yes
With Ruby.................: no
Enable Maintainer Docs......: no


Here's a sample of the output from make:


ar: creating build/librets/lib/librets.a
swig -c++ -python -o build/swig/python/librets_wrap.cpp \
-outdir build/swig/python /home/env/cwh/build/librets/librets-1.5.3/project/swig/librets.i
cd build/swig/python ; \
CC="gcc" CXX="g++" CFLAGS="-g -O2 -fPIC -DHAVE_CONFIG_H -DTARGET_UNIX -DLIBRETS_VERSION='"1.5.3"'" CXXFLAGS="" \
python setup.py build
sys.platform: linux2
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.7
copying librets.py -> build/lib.linux-x86_64-2.7
running build_ext
building '_librets' extension
creating build/temp.linux-x86_64-2.7
creating build/temp.linux-x86_64-2.7/home
creating build/temp.linux-x86_64-2.7/home/env
creating build/temp.linux-x86_64-2.7/home/env/cwh
creating build/temp.linux-x86_64-2.7/home/env/cwh/build
creating build/temp.linux-x86_64-2.7/home/env/cwh/build/librets
creating build/temp.linux-x86_64-2.7/home/env/cwh/build/librets/librets-1.5.3
creating build/temp.linux-x86_64-2.7/home/env/cwh/build/librets/librets-1.5.3/project
creating build/temp.linux-x86_64-2.7/home/env/cwh/build/librets/librets-1.5.3/project/swig
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -g -O2 -fPIC -DHAVE_CONFIG_H -DTARGET_UNIX -DLIBRETS_VERSION=1.5.3 -fPIC -I/usr/include/python2.7 -c librets_wrap.cpp -o build/temp.linux-x86_64-2.7/librets_wrap.o -I/home/env/cwh/build/librets/librets-1.5.3/project/librets/include -I/usr/include -I/usr/include -I. -fPIC
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for Ada/C/ObjC but not for C++ [enabled by default]
librets_wrap.cpp: In function ‘PyObject* _wrap_SearchRequestAPtr_LIMIT_DEFAULT_get(PyObject*, PyObject*)’:
librets_wrap.cpp:13767:35: warning: variable ‘arg1’ set but not used [-Wunused-but-set-variable]
librets_wrap.cpp: In function ‘PyObject* _wrap_SearchRequestAPtr_LIMIT_NONE_get(PyObject*, PyObject*)’:
librets_wrap.cpp:13789:35: warning: variable ‘arg1’ set but not used [-Wunused-but-set-variable]
librets_wrap.cpp: In function ‘PyObject* _wrap_SearchRequestAPtr_OFFSET_NONE_get(PyObject*, PyObject*)’:
librets_wrap.cpp:13850:35: warning: variable ‘arg1’ set but not used [-Wunused-but-set-variable]
librets_wrap.cpp: In function ‘PyObject* _wrap_UpdateRequestAPtr_UPDATE_OK_get(PyObject*, PyObject*)’:
librets_wrap.cpp:16339:35: warning: variable ‘arg1’ set but not used [-Wunused-but-set-variable]
librets_wrap.cpp: In function ‘PyObject* _wrap_UpdateRequestAPtr_AUTO_POPULATE_get(PyObject*, PyObject*)’:
librets_wrap.cpp:16361:35: warning: variable ‘arg1’ set but not used [-Wunused-but-set-variable]
librets_wrap.cpp: In function ‘PyObject* _wrap_UpdateRequestAPtr_VALIDATE_ONLY_get(PyObject*, PyObject*)’:
librets_wrap.cpp:16383:35: warning: variable ‘arg1’ set but not used [-Wunused-but-set-variable]
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -g -O2 -fPIC -DHAVE_CONFIG_H -DTARGET_UNIX -DLIBRETS_VERSION=1.5.3 -fPIC -I/usr/include/python2.7 -c /home/env/cwh/build/librets/librets-1.5.3/project/swig/librets_bridge.cpp -o build/temp.linux-x86_64-2.7/home/env/cwh/build/librets/librets-1.5.3/project/swig/librets_bridge.o -I/home/env/cwh/build/librets/librets-1.5.3/project/librets/include -I/usr/include -I/usr/include -I. -fPIC
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for Ada/C/ObjC but not for C++ [enabled by default]
g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -Wl,-z,relro -g -O2 -fPIC -DHAVE_CONFIG_H -DTARGET_UNIX -DLIBRETS_VERSION=1.5.3 build/temp.linux-x86_64-2.7/librets_wrap.o build/temp.linux-x86_64-2.7/home/env/cwh/build/librets/librets-1.5.3/project/swig/librets_bridge.o -o build/lib.linux-x86_64-2.7/_librets.so /home/env/cwh/build/librets/librets-1.5.3/build/librets/lib/librets.a -L/usr/lib -lboost_filesystem-mt -lboost_system-mt -L/usr/lib/x86_64-linux-gnu -lcurl -Wl,-Bsymbolic-functions -Wl,-z,relro -lexpat -L/usr/lib -lantlr
/usr/bin/ld: /usr/lib/libexpat.a(xmlparse.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/lib/libexpat.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
error: command 'g++' failed with exit status 1
make[1]: *** [build/swig/python/_librets.so] Error 1
make[1]: Leaving directory `/home/env/cwh/build/librets/librets-1.5.3'
make: *** [all] Error 2


On Oct 19, 2012, at 1:11 PM, Keith T. Garner <kga...@crt.realtors.org> wrote:

Keith T. Garner

unread,
Oct 19, 2012, 4:48:06 PM10/19/12
to For discussion and help for and by the users of the libRETS C++ library
What does a "locate libexpat.so" and again for libexpat.a look like for you?

kgarner@lithium [503]:locate libexpat.so ~
/lib/i386-linux-gnu/libexpat.so.1
/lib/i386-linux-gnu/libexpat.so.1.5.2
/lib/x86_64-linux-gnu/libexpat.so.1
/lib/x86_64-linux-gnu/libexpat.so.1.5.2
/usr/lib/x86_64-linux-gnu/libexpat.so

kgarner@lithium [509]:locate libexpat.a ~
/usr/lib/x86_64-linux-gnu/libexpat.a

Oh, and I didn't notice its the python bindings that's throwing that. I didn't try to build those the first time. I just did, and that went through fine for me. We need to figure out why you seem to be missing the expat shared libraries.

Thomas Hibbard

unread,
Oct 19, 2012, 5:07:23 PM10/19/12
to For discussion and help for and by the users of the libRETS C++ library
Here's what my locate output is:

(cwh)vicad@app:~$ locate libexpat.so
/lib/x86_64-linux-gnu/libexpat.so.1
/lib/x86_64-linux-gnu/libexpat.so.1.5.2
/usr/lib/x86_64-linux-gnu/libexpat.so

(cwh)vicad@app:~$ locate libexpat.a
/usr/lib/libexpat.a
/usr/lib/x86_64-linux-gnu/libexpat.a


I tried manually linking the libraries to "/usr/lib/x86_64-linux-gnu" to see if it would even compile. I did get a version to actually finish but it's displaying the following error:

"ImportError: /usr/local/lib/python2.7/dist-packages/_librets.so: undefined symbol: GSS_C_NT_HOSTBASED_SERVICE"

Not sure where the GSS error comes from either.


On Oct 19, 2012, at 3:48 PM, "Keith T. Garner" <kga...@crt.realtors.org>

Mark Klein

unread,
Oct 19, 2012, 7:01:20 PM10/19/12
to For discussion and help for and by the users of the libRETS C++ library
On Oct 19, 2012, at 2:07 PM, Thomas Hibbard wrote:

> Here's what my locate output is:
>
> (cwh)vicad@app:~$ locate libexpat.so

What does "objdump --headers /usr/lib/x86_64-linux-gnu/libexpat.so |
fgrep "file format" and
objdump --headers /usr/lib/x86_64-linux-gnu/libexpat.a | fgrep "file
format" say?
>>> prototypes -g -O2 -fPIC -DHAVE_CONFIG_H -DTARGET_UNIX -
>>> prototypes -g -O2 -fPIC -DHAVE_CONFIG_H -DTARGET_UNIX -
>>> DLIBRETS_VERSION=1.5.3 -fPIC -I/usr/include/python2.7 -c /home/env/
>>> cwh/build/librets/librets-1.5.3/project/swig/librets_bridge.cpp -o
>>> build/temp.linux-x86_64-2.7/home/env/cwh/build/librets/
>>> librets-1.5.3/project/swig/librets_bridge.o -I/home/env/cwh/build/
>>> librets/librets-1.5.3/project/librets/include -I/usr/include -I/

Mark Klein

unread,
Oct 19, 2012, 7:12:00 PM10/19/12
to For discussion and help for and by the users of the libRETS C++ library
On Oct 19, 2012, at 2:07 PM, Thomas Hibbard wrote:

> I tried manually linking the libraries to "/usr/lib/x86_64-linux-
> gnu" to see if it would even compile. I did get a version to
> actually finish but it's displaying the following error:
>
> "ImportError: /usr/local/lib/python2.7/dist-packages/_librets.so:
> undefined symbol: GSS_C_NT_HOSTBASED_SERVICE"

Oh, that's from OpenSSL, IIRC. Sounds like you might have a path
problem ... some machines with a stock OpenSSL included in the normal
distro have problems if the OpenSSL from your favorite package manager
is also installed. It can also show up if the libcurl you're using
references the wrong libssl in the binding order. You can overcome
that at times by making sure you're explicit about paths (e.g.
LDFLAGS="-L/your/explicit/path") in LDFLAGS and CURL_LDFLAGS.

Take a look at the Makefile ... there are a number of FLAGS settings
that you can override and as I said above, on some platforms you must.
For example, on FreeBSD, I need to do this in order to make sure I
pick up all of the libraries in /usr/local/lib in preference to those
in /usr/lib:

CPPFLAGS="-L/home/mklein/Boost/lib -L/usr/local/lib -I/home/mklein/
Boost/include/boost-1.51 -I/usr/local/include" \
./configure --enable-examples \
--enable-debug \
--enable-depends \
--enable-maintainer-documentation \
--enable-shared-dependencies \
--with-expat-prefix=/usr/local \
--with-boost-prefix=/home/mklein/Boost \
--with-java-prefix=/usr/local/diablo-jdk1.6.0/include

Thomas Hibbard

unread,
Nov 9, 2012, 5:21:19 PM11/9/12
to For discussion and help for and by the users of the libRETS C++ library
Thanks for previous suggestions, I was out for awhile and came back to see I still hadn't overcome this hurdle with getting librets 1.5.3 to correctly install on Ubuntu 12.04 x64.

I checked to make sure I have the openssl version of libcurl and I did. I also tried forcing my Makefile to point to "/usr/lib/x86_64-linux-gnu/" but it didn't seem to work. I am still receiving the same import error in Python complaining about "GSS_C_NT_HOSTBASED_SERVICE" being defined. If anyone has anything else I could try I'd appreciate it

Thanks,
Thomas
Reply all
Reply to author
Forward
0 new messages