Created attachment 466632 [details, diff] nas-1.9.4-r1-LDLIBS-libfl.patch I got this failure on an ~amd64 box: gmake[3]: Leaving directory '/var/tmp/portage/media-libs/nas-1.9.4-r1/work/nas-1.9.4-abi_x86_64.amd64/server/os' x86_64-pc-linux-gnu-gcc -o nasd -O2 -pipe -g -mtune=native -march=native -Wl,-O1 -Wl,--as-needed -L../lib/audio -L/usr/lib64 -L/usr/lib64 dia/libdia.a dda/voxware/libvoxware.a os/libos.a dia/libdia.a(lex.o): In function `yylex': /var/tmp/portage/media-libs/nas-1.9.4-r1/work/nas-1.9.4-abi_x86_64.amd64/server/dia/<stdout>:1191: undefined reference to `yywrap' collect2: error: ld returned 1 exit status gmake[2]: *** [Makefile:1102: nasd] Error 1 gmake[2]: Leaving directory '/var/tmp/portage/media-libs/nas-1.9.4-r1/work/nas-1.9.4-abi_x86_64.amd64/server' gmake[1]: *** [Makefile:1060: all] Error 2 gmake[1]: Leaving directory '/var/tmp/portage/media-libs/nas-1.9.4-r1/work/nas-1.9.4-abi_x86_64.amd64' make: *** [Makefile:1087: World] Error 2 * ERROR: media-libs/nas-1.9.4-r1::gentoo failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=media-libs/nas-1.9.4-r1::gentoo'`, * the complete build log and the output of `emerge -pqv '=media-libs/nas-1.9.4-r1::gentoo'`. * The complete build log is located at '/var/tmp/portage/media-libs/nas-1.9.4-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/media-libs/nas-1.9.4-r1/temp/environment'. * Working directory: '/var/tmp/portage/media-libs/nas-1.9.4-r1/work/nas-1.9.4-abi_x86_64.amd64' * S: '/var/tmp/portage/media-libs/nas-1.9.4-r1/work/nas-1.9.4' comments at https://aur.archlinux.org/packages/nas/ suggest this is some kind of multilib problem and I do build this package with ABI_X86="64 32", but as can be seen above this happened in the abi_x86_64 portion of the build, so, I dunno. Anyhow I tried aping the Arch fix here: https://aur.archlinux.org/cgit/aur.git/commit/?h=nas&id=56684be63ef2428ea70a97aaaa910a356d08b003 using the attached change to the ebuild and it W4M.
Created attachment 467028 [details, diff] Add libfl if needed and revbump nas ebuild. This is all so horribly broken. Here's a patch to revbump nas and add a new patch that adds libfl if needed only - as autodetected through configure. If yywrap is not defined in libfl, LEXLIBS will be empty and we thus won't overlink. All this said - I think it should not be linking to libfl at all. But updating the configure script is a huge mess, since it was generated (and probably modified by hand) 9 years ago. Just autogenerating it again won't work, because there's no clear way of how it was generated in the first case - the m4 files and other stuff certainly is not enough to get this going. The proper way to fix this would be to remove the yywrap configure check completely and let it provide its own yywrap implementation. It already does so, but the internal yywrap function is disabled because it found yywrap in libfl at configure time. Again, huge mess.
(In reply to Mihai Moldovan from comment #1) > Created attachment 467028 [details, diff] [details, diff] > Add libfl if needed and revbump nas ebuild. > > This is all so horribly broken. [snip?] > Here's a patch to revbump nas and add a new patch that adds libfl if needed > only - as autodetected through configure. If yywrap is not defined in libfl, > LEXLIBS will be empty and we thus won't overlink. Obviously not perfect but clearly better than my "solution". > All this said - I think it should not be linking to libfl at all. But > updating the configure script is a huge mess, since it was generated (and > probably modified by hand) 9 years ago. I hate when projects do this. Kudos to you and whoever else is responsible for keeping such autoconf-abandonware projects working in Gentoo, your masochism is greatly appreciated!
(In reply to Greg Turner from comment #2) > I hate when projects do this. Kudos to you and whoever else is responsible > for keeping such autoconf-abandonware projects working in Gentoo, your > masochism is greatly appreciated! The autoconf system all by itself isn't so bad, mostly. If used in the way it is intended to be used. nas is a good example of how to NOT EVER use it. Proper, reproducible generation seems to be impossible. They started with an imake-based build system and hacked in some configure script for automatic environment detection. I have contributing to packaging projects for the past 7 years, mostly within MacPorts. Fortunately, seeing something as ugly as nas' build system is rare.
(In reply to Mihai Moldovan from comment #3) > (In reply to Greg Turner from comment #2) > > I hate when projects do this. Kudos to you and whoever else is responsible > > for keeping such autoconf-abandonware projects working in Gentoo, your > > masochism is greatly appreciated! > > The autoconf system all by itself isn't so bad, mostly. If used in the way > it is intended to be used. Agreed. Although autotools' sendmail.cf-style script-soup implementation can be /incredibly/ triggering, in practice, I feel it's almost always easier to consume and maintain than frameworks which try to make all the ugly stuff disappear by jamming it into a maze of OOP-ish black boxes. > nas is a good example of how to NOT EVER use it. Proper, reproducible > generation seems to be impossible. They started with an imake-based build > system and hacked in some configure script for automatic environment > detection. :) Usually I think this happens because somebody doesn't want to learn M4. Which I can relate to. But I presume if they'd understood the likely cost of a messy autotools divorce they'd have found some better way forward. Interestingly I find media and science projects to be the biggest perpetrators. But I massively digress! Thanks again for your hard work.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=751e74cd39901a3f71efadaaa201e51ea50eb775 commit 751e74cd39901a3f71efadaaa201e51ea50eb775 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2018-08-22 22:23:01 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2018-08-22 22:23:23 +0000 media-libs/nas: link against libfl Thanks-to: Mihai Moldovan <ionic@ionic.de> Closes: https://bugs.gentoo.org/612270 Package-Manager: Portage-2.3.48, Repoman-2.3.10 media-libs/nas/files/nas-1.9.4-libfl.patch | 12 ++++++++++++ media-libs/nas/nas-1.9.4-r2.ebuild | 1 + 2 files changed, 13 insertions(+)