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.
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.
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.22.214.171.124 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?
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.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.