Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • BIND BIND
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 525
    • Issues 525
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 96
    • Merge requests 96
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source Projects
  • BINDBIND
  • Issues
  • #588
Closed
Open
Created Oct 11, 2018 by Håvard Eidnes@he32

build failure related to libtool on NetBSD

Summary

Configured with

./configure --with-libxml2=yes --with-tuning=large --with-libtool

run on NetBSD/amd64 7.1_STABLE, BIND fails to build.

BIND version used

BIND 9.12.2-P2 <id:b2bf278>
running on NetBSD amd64 7.1_STABLE NetBSD 7.1_STABLE (GENERIC) #0: Mon Feb  5 12:42:24 CET 2018  he@xxxxxxxx:/usr/obj/sys/arch/amd64/compile/GENERIC
built by make with '--with-libxml2=yes' '--with-tuning=large' '--with-libtool'
compiled by GCC 4.8.4
compiled with OpenSSL version: OpenSSL 1.0.1t  3 May 2016
linked to OpenSSL version: OpenSSL 1.0.1t  3 May 2016
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with zlib version: 1.2.3
linked to zlib version: 1.2.3
threads support is enabled

Steps to reproduce

Try to build BIND after configuring.

Watch it fail with libtool-related issues in either

bin/tests/system/dyndb/driver/ or bin/tests/system/dlzexternal/

What is the current bug behavior?

Out of the box, this happens:

CLEANED=`echo "../../../../../lib/dns/libdns.la  -lgssapi ../../../../../lib/isc/libisc.la  -lcrypto  -lgssapi ../../../../../lib/dns/libdns.la  -lgssapi ../../../../../lib/isc/libisc.la  -lcrypto -lpthread  -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -lxml2 -L/usr/lib -lz -L/usr/lib -llzma -L/usr/lib -lm" | sed -e s/-Wl,//g`;  /bin/sh /usr/local/src/bind-9.12.2-P2/libtool --mode=link --tag=CC ld -Bshareable -x -o sample.so db.lo driver.lo instance.lo  lock.lo log.lo syncptr.lo zone.lo  ${CLEANED}
libtool: link: ld -Bshareable -x -o .libs/sample.so .libs/db.o .libs/driver.o .libs/instance.o .libs/lock.o .libs/log.o .libs/syncptr.o .libs/zone.o  -L/usr/pkg/lib -L/usr/lib ../../../../../lib/dns/.libs/libdns.so /usr/local/src/bind-9.12.2-P2/lib/isc/.libs/libisc.so -lgssapi ../../../../../lib/isc/.libs/libisc.so -lcrypto -lpthread /usr/pkg/lib/libxml2.so -lz -llzma -lm  -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/pkg/lib
ld: unrecognized option '-Wl,-rpath'
ld: use the --help option for usage information
*** Error code 1

Stop.
make[5]: stopped in /usr/local/src/bind-9.12.2-P2/bin/tests/system/dyndb/driver

It appears that libtool adds the "-Wl,-rpath" entries, as if it was talking to the C compiler instead of 'ld'.

So I patched configure.in to use "${CC}" and "-shared -Wl,-x" as SO_LD and SO_LDFLAGS respectively for NetBSD.

This is however not sufficient -- the person coding the Makefile.in in the above mentioned directories is apparently somewhere half-way between actually using libtool and doing the linking "by hand".

What is the expected correct behavior?

The build should complete...

The combined diff file attached here acheives that (but the required renaming of the shared library objects may require other code to adapt). Libtool insists that things it should link into a library must start with "lib" and end in ".la", and adding "-rpath somedir" automagically triggers the creation of a shared library object.

Relevant configuration files

This is not a run-time issue, so no relevant config files.

Relevant logs and/or screenshots

None, above the excerpt above.

Possible fixes

Diff attached. diff

Oh, yes, and the SO_STRIP construct looks extremely sketchy; it only processes the arguments given to libtool, not the arguments libtool as a result might emit, such as "-Wl,-rpath,/dir"... It looks like a bad band-aid which should be removed.

Assignee
Assign to
Time tracking