On Thu, 7 Feb 2002 12:50:53 -0600 (CST) john beamon <[EMAIL PROTECTED]> wrote:
> I'm trying to build proftpd-1.2.5rc1 (also tried v1.2.2) on Solaris 8 with > mysql authentication. I'm getting errors in the proftpd make. The > environment is Solaris 8 + 8_Recommended.zip + GNU make and gcc (both > compiled from source). mysql-3.23.47 compiled into /usr/local/mysql and > running. proftpd otherwise comiled successfully on the same box. > gcc/libc updates brought in /usr/lib/sparcv9 libraries, which have been > referenced specifically in some attempts. [...snip...] > # ./proftpd > ld.so.1: ./proftpd: fatal: relocation error: file ./proftpd: symbol > __register_frame_info: referenced symbol not found > Killed Urgh....I have seen this before. It's a common problem, and it's related to GNU tools. On Linux, it's often triggered with C++ programs. The best explaination of the cause is a binary incompatibility between compiler versions. I.e. you're using libraries, some compiled with one version of gcc, some with another. There was a version of egcs (1.1.2) that was notorious for this, and, as I've read it bit sparc platforms too. There may (depending on wether your linker allows it) be some cheap, ugly workarounds: you can look inside the libs in /lib (or wherever you have gcc-compiled libs) and find one that has that symbol - you could use # LD_PRELOAD=somerandomlibrary.so ./proftpd ...where somerandomlibrary has the symbol. And that _might_ get it going. I've had that work before. Another way is to alter the makefile (or cut and paste the final link) to link "somerandomlibrary.so" into it. (even tho that library is just being linked for that one stupid hanging symbol) (when I say "look inside" a library, you can do that with GNU grep - it can do searches within binaries, otherwise use strings file.so | grep __register_frame_info) A better solution is to use "ldd" (or it's solaris equivalent) and find which exact libs the proftpd binary requires, and get the source and compile them yourself, with your own compiler. (i.e. the OTHER libs) You practically never have problems when everything is compiled with the same compiler version. >From the looks of your compiler output, it's linked against some from glibc (nsl, socket, libm) - some other libs (zlib, PAM), mysql, and probably some Sun-specific ones. nsl is often tossed in for no reason, so that can usually be eliminated, you can try compiling w/o libm, zlib is easy to get and recompile, not sure if PAM is different on Solaris. -- Mark Orr [EMAIL PROTECTED] ================================================ BRLUG - The Baton Rouge Linux User Group Visit http://www.brlug.net for more information. Send email to [EMAIL PROTECTED] to change your subscription information. ================================================
