RPM build problem with bind-9.2.3 on ancient RedHat 6 system

Rule, Ted Ted_Rule at flextech.co.uk
Fri Jan 9 14:04:04 UTC 2004


I've just had recourse to try and build a bind-9.2.3 RPM for an old RedHat =
6.2
system, and came across a glitch in the RPM build sequence which may or may
not be a portability issue for the overall bind source tree.

Using a reworking of an old 9.2.1 RPM SPEC file, I tried to build 9.2.3 RPM=
s from
the source tree, but the overall RPM build sequence failed.=20

Looking at the build sequence, this step appears to be the first that
really fails, showing "cannot find -lisc"

cd /usr/src/redhat/BUILD/bind-9.2.3/lib/isccc; /bin/sh /usr/src/redhat/BUIL=
D/bind-9.2.3/libtool --mode=3Drelink
i386-redhat-linux-gcc -O2 -march=3Di386 -mcpu=3Di686 -I/usr/src/redhat/BUIL=
D/bind-9.2.3
-I. -I/usr/src/redhat/BUILD/bind-9.2.3/lib/dns/include
-I../../lib/dns/include -I../../lib/dns/sec/dst/include
-I/usr/src/redhat/BUILD/bind-9.2.3/lib/isc/include
-I../../lib/isc -I../../lib/isc/include=20
-I../../lib/isc/unix/include
-I../../lib/isc/pthreads/include
-I/usr/src/redhat/BUILD/bind-9.2.3/lib/isccc/include
-I../../lib/isccc/include
-D_REENTRANT -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wfo=
rmat -o libisccc.la -rpath /usr/lib
-version-info 1:0:1
alist.lo base64.lo cc.lo ccmsg.lo lib.lo result.lo sexpr.lo symtab.lo versi=
on.lo -lnsl -lpthread ../../lib/isc/libisc.la
i386-redhat-linux-gcc -shared  alist.lo base64.lo cc.lo ccmsg.lo lib.lo res=
ult.lo sexpr.lo symtab.lo version.lo  -lnsl -lpthread
-L/usr/lib -lisc   -Wl,-soname -Wl,libisccc.so.0 -o .libs/libisccc.so.0.1.0
/usr/bin/ld: cannot find -lisc
collect2: ld returned 1 exit status
libtool: install: error: relink `libisccc.la' with the above command before=
 installing it
libtool: install: warning: remember to run `libtool --finish /usr/lib'


For the same build sequence building 9.2.1 instead, the same step is Ok as =
per below, but it is just possible
to see that the 9.2.3 sequence significantly differs in containing:

"-L/usr/lib -lisc"


/bin/sh /usr/src/redhat/BUILD/bind-9.2.1/libtool --mode=3Dlink \
        gcc  -O2 -march=3Di386 -mcpu=3Di686 -I/usr/src/redhat/BUILD/bind-9.=
2.1
-I. -I/usr/src/redhat/BUILD/bind-9.2.1/lib/dns/include
-I../../lib/dns/include -I../../lib/dns/sec/dst/include
-I/usr/src/redhat/BUILD/bind-9.2.1/lib/isc/include
-I../../lib/isc -I../../lib/isc/include
-I../../lib/isc/unix/include
-I../../lib/isc/pthreads/include
-I/usr/src/redhat/BUILD/bind-9.2.1/lib/isccc/include
-I../../lib/isccc/include
-D_REENTRANT    -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings  =
-o libisccc.la -rpath /usr/lib \
        -version-info 0:1:0 \
        alist.lo base64.lo cc.lo ccmsg.lo lib.lo result.lo sexpr.lo symtab.=
lo version.lo -lnsl -lpthread
rm -fr .libs/libisccc.la .libs/libisccc.* .libs/libisccc.*
gcc -shared  alist.lo base64.lo cc.lo ccmsg.lo lib.lo result.lo sexpr.lo sy=
mtab.lo version.lo  -lnsl -lpthread  -Wl,-soname -Wl,libi
sccc.so.0 -o .libs/libisccc.so.0.0.1
(cd .libs && rm -f libisccc.so.0 && ln -s libisccc.so.0.0.1 libisccc.so.0)
(cd .libs && rm -f libisccc.so && ln -s libisccc.so.0.0.1 libisccc.so)
/usr/bin/ar cru .libs/libisccc.a  alist.o base64.o cc.o ccmsg.o lib.o resul=
t.o sexpr.o symtab.o version.o
ranlib .libs/libisccc.a
creating libisccc.la
(cd .libs && rm -f libisccc.la && ln -s ../libisccc.la libisccc.la)


I reasoned that the build issue was because the build of the some of the IS=
C shared libraries requires
access to other shared libraries which are built earlier in the sequence, a=
nd that 9.2.1 perhaps
didn't require one ISC library to depend on another. Under normal circumsta=
nces,
make install would install these in /usr/lib, but RPM building adds a wrapp=
er which means they are=20
temporarily built in /var/tmp/bind-root/usr/lib instead.

As a truly horrid workround to this, therefore, I tried creating a whole bu=
nch of symlinks
from /usr/lib to /var/tmp/bind-root/usr/lib for the 9.2.3 shared libraries.=
 Note that the build
system already had bind-9.2.1 shared libraries in /usr/lib anyway, and henc=
e I had to be
somewhat careful in only including symlinks to some of the contents of /var=
/tmp/bind-root/usr/lib

The required kludge symlinks are shown below.


$ ls -l /usr/lib/libdns\.*
lrwxrwxrwx    1 root     root           35 Jan  9 13:34 /usr/lib/libdns.a -=
> /var/tmp/bind-root/usr/lib/libdns.a
lrwxrwxrwx    1 root     root           36 Jan  9 13:34 /usr/lib/libdns.la =
-> /var/tmp/bind-root/usr/lib/libdns.la
lrwxrwxrwx    1 root     root           43 Jan  9 13:35 /usr/lib/libdns.so =
-> /var/tmp/bind-root/usr/lib/libdns.so.11.0.2
lrwxrwxrwx    1 root     root           15 Nov 21  2002 /usr/lib/libdns.so.=
5 -> libdns.so.5.3.0
-rwxr-xr-x    1 root     root      1032753 Nov 15  2002 /usr/lib/libdns.so.=
5.3.0

$ ls -l /usr/lib/libisc\.*
lrwxrwxrwx    1 root     root           35 Jan  9 09:50 /usr/lib/libisc.a -=
> /var/tmp/bind-root/usr/lib/libisc.a
lrwxrwxrwx    1 root     root           36 Jan  9 09:50 /usr/lib/libisc.la =
-> /var/tmp/bind-root/usr/lib/libisc.la
lrwxrwxrwx    1 root     root           36 Jan  9 09:50 /usr/lib/libisc.so =
-> /var/tmp/bind-root/usr/lib/libisc.so
lrwxrwxrwx    1 root     root           15 Nov 21  2002 /usr/lib/libisc.so.=
4 -> libisc.so.4.1.0
-rwxr-xr-x    1 root     root       242575 Nov 15  2002 /usr/lib/libisc.so.=
4.1.0
lrwxrwxrwx    1 root     root           38 Jan  9 09:51 /usr/lib/libisc.so.=
7 -> /var/tmp/bind-root/usr/lib/libisc.so.7

$ ls -l /usr/lib/libisccc\.*
lrwxrwxrwx    1 root     root           37 Jan  9 13:33 /usr/lib/libisccc.a=
 -> /var/tmp/bind-root/usr/lib/libisccc.a
lrwxrwxrwx    1 root     root           38 Jan  9 13:33 /usr/lib/libisccc.l=
a -> /var/tmp/bind-root/usr/lib/libisccc.la
lrwxrwxrwx    1 root     root           44 Jan  9 13:34 /usr/lib/libisccc.s=
o -> /var/tmp/bind-root/usr/lib/libisccc.so.0.1.0
lrwxrwxrwx    1 root     root           17 Nov 21  2002 /usr/lib/libisccc.s=
o.0 -> libisccc.so.0.0.1
-rwxr-xr-x    1 root     root        32053 Nov 15  2002 /usr/lib/libisccc.s=
o.0.0.1

$ ls -l /usr/lib/liblwres\.*
lrwxrwxrwx    1 root     root           37 Jan  9 13:32 /usr/lib/liblwres.a=
 -> /var/tmp/bind-root/usr/lib/liblwres.a
lrwxrwxrwx    1 root     root           38 Jan  9 13:32 /usr/lib/liblwres.l=
a -> /var/tmp/bind-root/usr/lib/liblwres.la
lrwxrwxrwx    1 root     root           44 Jan  9 13:32 /usr/lib/liblwres.s=
o -> /var/tmp/bind-root/usr/lib/liblwres.so.1.1.1
lrwxrwxrwx    1 root     root           17 Nov 21  2002 /usr/lib/liblwres.s=
o.1 -> liblwres.so.1.1.0
-rwxr-xr-x    1 root     root        65289 Nov 15  2002 /usr/lib/liblwres.s=
o.1.1.0
$=20


With this kludge in place, the 9.2.3 RPM Build Sequence completed Ok.

I would imagine there are possibly more correct modifications to the RPM SP=
EC file which
would avoid the horrid symlinks during the build process, but I was getting=
 slightly=20
desperate for a quick solution.

I have yet to actually install the RPMs on a machine to prove whether they =
actually work, but I
have reasonable confidence that they will.


Do some additional changes need to be made to the bind source tree configur=
e/make sequence to work
properly under an RPM build environment? Or is it just that the combination=
 of autoconf/libtool
( libtool-1.4-8 / autoconf-2.13-5 ) is so old and cranky that libtool will =
never get it right?


Thanks in advance for any suggestions.




Ted







***************************************************************************=
*********************
This E-mail message, including any attachments, is intended only for the pe=
rson
or entity to which it is addressed, and may contain confidential informatio=
n.
If you are not the intended recipient, any review, retransmission, disclosu=
re,
copying, modification or other use of this E-mail message or attachments is
strictly forbidden.
If you have received this E-mail message in error, please contact the autho=
r and
delete the message and any attachments from your computer.
You are also advised that the views and opinions expressed in this E-mail
message and any attachments are the author's own, and may not reflect the v=
iews
and opinions of FLEXTECH Television Limited.
***************************************************************************=
*********************



More information about the bind-workers mailing list