[SOLVED] BIND fail compilation under slackware64

StreamThreader · 12-14-2012, 03:11 AM

Hello!
I compile bind under slackware64 14.0 and have error.
I think compiler search libraries in wrong places (in compat dirs(multilib system))
logfile - ftp://ifconfig.com.ua/incoming/bindbuild.log

wildwizard · 12-14-2012, 03:54 AM

Fastest way to work out how you broke it is to get you to post the output from "export"

Mike_M · 12-14-2012, 04:08 PM

Based on the snippet below, it looks like you're trying to build on a multilib enabled 64-bit system:

Code:

gcc -O2 -fPIC -I/usr/include/libxml2 -o .libs/dig .libs/dig.o .libs/dighost.o  ../../lib/lwres/.libs/liblwres.so ../../lib/dns/.libs/libdns.so ../../lib/bind9/.libs/libbind9.so /bind-b29356bcad88ebcf1052a5fd085ce468/bind-9.9.2-P1/lib/isccfg/.libs/libisccfg.so ../../lib/isccfg/.libs/libisccfg.so /bind-b29356bcad88ebcf1052a5fd085ce468/bind-9.9.2-P1/lib/dns/.libs/libdns.so -lcrypto /bind-b29356bcad88ebcf1052a5fd085ce468/bind-9.9.2-P1/lib/isccc/.libs/libisccc.so /bind-b29356bcad88ebcf1052a5fd085ce468/bind-9.9.2-P1/lib/isc/.libs/libisc.so ../../lib/isc/.libs/libisc.so /usr/lib64/libxml2.so /usr/lib64/liblzma.so -L/usr/lib /usr/lib64/libidnkit.so -lcap -lpthread /usr/lib/libxml2.so -ldl /usr/lib/liblzma.so -lz -lm  -Wl,--rpath -Wl,/usr/lib64
/usr/lib64/gcc/x86_64-slackware-linux/4.7.1/../../../../x86_64-slackware-linux/bin/ld: skipping incompatible /usr/lib/libcrypto.so when searching for -lcrypto
/usr/lib64/gcc/x86_64-slackware-linux/4.7.1/../../../../x86_64-slackware-linux/bin/ld: skipping incompatible /usr/lib/libcrypto.a when searching for -lcrypto
/usr/lib64/gcc/x86_64-slackware-linux/4.7.1/../../../../x86_64-slackware-linux/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread
/usr/lib64/gcc/x86_64-slackware-linux/4.7.1/../../../../x86_64-slackware-linux/bin/ld: skipping incompatible /usr/lib/libpthread.a when searching for -lpthread
/usr/lib/libxml2.so: could not read symbols: File in wrong format

Try setting "LDFLAGS="-L/usr/lib64" when you run the configure script. For example, if using the bind.SlackBuild that comes with slackware64-14.0, change

Code:

# Configure:
CFLAGS="$SLKCFLAGS" \
./configure \

to

Code:

# Configure:
LDFLAGS="-L/usr/lib${LIBDIRSUFFIX}" \
CFLAGS="$SLKCFLAGS" \
./configure \

and rerun the script.

StreamThreader · 12-14-2012, 04:29 PM

Thanks you Mike_M !
With this fix, all works.

wildwizard · 12-15-2012, 01:01 AM

Quote:

Originally Posted by Mike_M

Based on the snippet below, it looks like you're trying to build on a multilib enabled 64-bit system:

There are plenty of us with multilib enabled systems that compile code on a regular basis but never have these sorts of problems.

Which is why I asked for the output from export as it would show what he has done to his systems environment to cause this error. And setting yet another environment variable is not a fix, it is just covering up the problem further and may result in even more failures in the long term.

Mike_M · 12-15-2012, 06:23 AM

Quote:

Originally Posted by wildwizard

There are plenty of us with multilib enabled systems that compile code on a regular basis but never have these sorts of problems.

Which is why I asked for the output from export as it would show what he has done to his systems environment to cause this error. And setting yet another environment variable is not a fix, it is just covering up the problem further and may result in even more failures in the long term.

And how about the people with multilib enabled systems who compile code on a regular basis who do have these sorts of problems?

I maintain a few hundred of my own SlackBuild scripts for the software I use. Most software builds fine without the need of adding an LDFLAGS env variable to force the linker to look in the correct place. Very few of them don't work correctly, most likely because of something amiss in their configure scripts.

This isn't necessarily due to user error or a broken environment. The issue pops up from time to time here and elsewhere. I'm not the first person to suggest this, and I doubt I'll be the last.