x86_64-pc-linux-gnu-g++: error: unrecognized command-line option ‘-noundefined’ rdlibtool: exec error upon slbt_exec_link_create_library(), line 1446: (see child process error messages). rdlibtool: < returned to > slbt_exec_link(), line 1868. make[3]: *** [Makefile:471: _dippy.la] Error 2 ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_no-multilib-20210315-144814 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-10.2.0 * clang version 11.1.0 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/11/bin /usr/lib/llvm/11 11.1.0 Python 3.8.8 Available Ruby profiles: [1] ruby26 (with Rubygems) [2] ruby27 (with Rubygems) * Available Rust versions: [1] rust-bin-1.50.0 [2] rust-1.50.0 * The following VMs are available for generation-2: *) AdoptOpenJDK 8.282_p08 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-bin-8 system-vm The Glorious Glasgow Haskell Compilation System, version 8.10.4 timestamp(s) of HEAD at this tinderbox image: /var/db/repos/gentoo Sat Mar 27 14:35:45 UTC 2021 emerge -qpvO sci-libs/coinor-dip [ebuild N ] sci-libs/coinor-dip-0.95.0-r1 USE="-doc -test"
Created attachment 695565 [details] emerge-info.txt
Created attachment 695568 [details] emerge-history.txt
Created attachment 695571 [details] environment
Created attachment 695574 [details] etc.portage.tar.bz2
Created attachment 695577 [details] logs.tar.bz2
Created attachment 695580 [details] sci-libs:coinor-dip-0.95.0-r1:20210327-163350.log
Wondered what this was about given the ebuild isn't wired to build dippy, turns out only happens when python:2.7 is installed, and then fails if using slibtool. This is bad automagic so I'll have a look myself to prevent this.
*** Bug 792894 has been marked as a duplicate of this bug. ***
Why is not not part of the slibtool meta issue? Without trying myself I suspect GNU libtool just silently ignores -noundefined when it should be -no-undefined. (Although it would ignore that too...)
(In reply to orbea from comment #9) > Why is not not part of the slibtool meta issue? Without trying myself I > suspect GNU libtool just silently ignores -noundefined when it should be > -no-undefined. (Although it would ignore that too...) I was more seeing is a "installs python2.7 stuff when it shouldn't" issue and didn't think to add the blocker here, but yes it does happen to cause issues for slibtool at same time (didn't think to add the blocker back then, for the duplicate I just didn't want to have duplicates on the tracker). If the python2 stuff isn't run, then this -noundef part is never used.
Yea I see your point, but also most of these slibtool issues are not problems with slibtool, but problems exposed by slibtool which exist regardless. In this case preventing the usage of python2 is probably the best fix as you said.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6606838b0dedc4fe7916e0341671884ab9478085 commit 6606838b0dedc4fe7916e0341671884ab9478085 Author: Ionen Wolkens <sudinave@gmail.com> AuthorDate: 2021-03-28 22:36:44 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-05-31 08:15:46 +0000 sci-libs/coinor-dip: prevent python-2.7 automagic When python-2.7 is installed it attempts to build dippy which fails with slibtool due a typo that GNU libtool ignored. Rather than fix, since it installs some unsupported 2.7 site-packages, block it and revbump to clear these. Closes: https://bugs.gentoo.org/778965 Signed-off-by: Ionen Wolkens <sudinave@gmail.com> Closes: https://github.com/gentoo/gentoo/pull/20171 Signed-off-by: Sam James <sam@gentoo.org> .../{coinor-dip-0.95.0-r1.ebuild => coinor-dip-0.95.0-r2.ebuild} | 3 +++ 1 file changed, 3 insertions(+)
