Summary: | >=net-dns/bind-tools-9.16.13 rlibtool: error: --mode must be specified (when using MAKEFLAGS='LIBTOOL=rlibtool') | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alessandro Barbieri <lssndrbarbieri> |
Component: | Current packages | Assignee: | Patrick McLean <chutzpah> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | chutzpah, ionen, sam, toralf |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=778479 https://bugs.gentoo.org/show_bug.cgi?id=799842 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 765709 | ||
Attachments: | bind-tools-9.16.13:20210320-034145.log |
Description
Alessandro Barbieri
2021-03-21 01:14:07 UTC
Created attachment 692619 [details]
bind-tools-9.16.13:20210320-034145.log
buildlog
fails for me with rlibtool, libtool, lld, bfd, bash and dash (In reply to Alessandro Barbieri from comment #2) > fails for me with [...] libtool [...] When testing this, should just not set LIBTOOL instead of LIBTOOL=libtool In this case it's failing because LIBTOOL is set at all, otherwise it works just fine. Technically not a slibtool issue, but I'll mark it as such as it's only a problem if trying to use alternate libtool. Haven't tried but I assume this affects net-dns/bind as well. I can't unset variables in /etc/portage/env > I can't unset variables in /etc/portage/env
I set it in make.conf:
MAKEFLAGS='LIBTOOL=rlibtool'
And if needed in /etc/portage/env/libtool.conf:
MAKEFLAGS=''
Seems fixed in the bind upstream git repo already. I bisected it to the following to commits. https://gitlab.isc.org/isc-projects/bind9/-/commit/1628f5865acb2d472ce4adf71fc78ac99094fa1c https://gitlab.isc.org/isc-projects/bind9/-/commit/37b9511ce1dd9ba66a6620c5ff617016eb81188f *** Bug 781182 has been marked as a duplicate of this bug. *** *** Bug 789798 has been marked as a duplicate of this bug. *** *** Bug 913562 has been marked as a duplicate of this bug. *** *** Bug 925501 has been marked as a duplicate of this bug. *** |