Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

compilation errors - ubuntu 9.10

2009-11-09
2013-04-18
  • James Bonfield
    James Bonfield
    2009-11-09

    Under Debian (and so probably Ubuntu) the curl package is split into libcurl3 and libcurl3-dev (actually libcurl3-openssl-dev on this system it looks - an old Debian etch one).

    The curl-config program is supplied by the dev package and it tells the configure script what libraries and include paths to add during compilation. So try searching for the -dev package in synaptic.

    It's likely you'll need something similar for tcl, tk, itcl, itk etc. I ought to try and get the canonical list for the most common operating systems and put them all in a README file.

    James

     
  • James Bonfield
    James Bonfield
    2009-11-09

    I just noticed the -fPIC issues too.

    So this comes when building a shared library and linking in code that wasn't built with -fPIC. Note that this ALSO includes building a shared library that links against a static .a file, which in your example is /usr/local/lib/libz.a.

    It's fine to build a static libz.a, but given that it'll be linked into a dynamic library you should recompile libz using CFLAGS=-fPIC (or editing the Makefile manually for it) so it's compatible with being used within a dynamic library.

    If you have a working system libz (which is probably the case) then maybe you can manually specify -with-zlib to pick up the .so version in the system directories.

    James

     
  • Thanks for the quick response James - the curl issue is fixed. I'm still stuck with the zlib thing though: I have /lib/libz.so.1.2.3.3 but trying '../configure -with-zlib=/lib' made no difference. And I tried recompiling zlib1g (and zlib1g-dev) using -fPIC according to the instructions here:

    http://www.cmiss.org/cmgui/wiki/BuildingUbuntuPackagesFromSource

    then reinstalled with dpkg. But I still get the same error when I then try and build staden again (ie /usr/bin/ld: /usr/local/lib/libz.a(crc32.o) etc).

    Did I recompile the wrong package?

    Gareth

     
  • James Bonfield
    James Bonfield
    2009-11-10

    Possibly. I'm not sure why it's preferring to link against the copy in /usr/local/lib instead. Perhaps because of io_lib? What is "/usr/local/bin/iolib-config -libs" telling you? My guess is it has "-L/usr/local/lib
    -lstaden-read  -lm   -lcurl -lz" and the presence of -L/usr/local/lib (to find the path for libstaden-read.so) is also causing the compiler to find the /usr/local/lib/libz.a in preference to the system one.

    The ubuntu package itself was almost certainly already using -fPIC as it's the .so file in /lib. I don't know where your copy in /usr/local came from, but it's that which is causing the problems.

    I'm not sure on the best solution to prevent it from linking against the zlib in /usr/local. Perhaps adding an explicit -L/lib  to your CFLAGS will get it to look there before /usr/local/lib. Messy. Alternatively if you don't know why the /usr/local/lib/libz.a is there, just rename it temporarily :-)

     
  • Renaming that libz.a did the trick! Thanks for your help.