compilation errors - ubuntu 9.10

  • 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 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.


  • Nobody/Anonymous

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

    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?


  • 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 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 :-)

  • Nobody/Anonymous

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


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks