Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 612270 - media-libs/nas-1.9.4-r1[abi_x86_32]: undefined reference to `yywrap'
Summary: media-libs/nas-1.9.4-r1[abi_x86_32]: undefined reference to `yywrap'
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Sound Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-11 03:09 UTC by Greg Turner
Modified: 2018-08-22 22:23 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
nas-1.9.4-r1-LDLIBS-libfl.patch (nas-1.9.4-r1-LDLIBS-libfl.patch,354 bytes, patch)
2017-03-11 03:09 UTC, Greg Turner
Details | Diff
Add libfl if needed and revbump nas ebuild. (nas.patch,3.39 KB, patch)
2017-03-14 18:08 UTC, Mihai Moldovan
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Greg Turner 2017-03-11 03:09:08 UTC
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.
Comment 1 Mihai Moldovan 2017-03-14 18:08:16 UTC
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.
Comment 2 Greg Turner 2017-03-14 18:16:28 UTC
(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!
Comment 3 Mihai Moldovan 2017-03-14 18:40:47 UTC
(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.
Comment 4 Greg Turner 2017-03-14 19:10:07 UTC
(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.
Comment 5 Larry the Git Cow gentoo-dev 2018-08-22 22:23:47 UTC
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(+)