Bug 625508 – sys-devel/flex-2.6.4: fails to build ../lib/malloc.o when required for target (Prefix) platform (automake bug)

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Michael Haubenwallner (RETIRED) 2017-07-18 12:30:13 UTC]

Created attachment 485382 [details, diff]
workaround: explicitly create top_builddir/lib/

Upstream report: https://github.com/westes/flex/issues/244

In Prefix on AIX I do have all the situations as described in the upstream report:
* Use flex-2.6.4, where lib/ contains only malloc.c and realloc.c, but no Makefile as in 2.6.3.
* Build out-of-source, so $top_builddir/lib/ does not exist before running configure.
* Use --disable-dependency-tracking to render config.status: executing depfiles commands a no-op. This would create .lib/.deps/*.Po otherways.
* Build for some target platform (like AIX) which requires (one of) the malloc/realloc replacements.
    (To reproduce this on Linux, use ac_cv_func_malloc_0_nonnull=no instead.)

[Comment 1 Michael Haubenwallner (RETIRED) 2017-08-18 09:43:43 UTC]

As this turns out to be an automake bug[1], question now is:
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27781

Where best to work around it until the fix ships with new package releases after they upgraded to new automake release once available?

I can think of:

* econf:
do something like:
 eval $(grep ^ac_config_libobj_dir= "${ECONF_SOURCE}/configure")
 mkdir -p "./${ac_config_libobj_dir:-.}"

pro: Would not require any additional ebuild to be modified.
con: Will be applied even when the package ships with the automake fix.


* elt-patches:
patch configure to write [\$MKDIR_P "$ac_config_libobj_dir"] into config.status, like http://lists.gnu.org/archive/html/autoconf-patches/2017-07/msg00002.html

con: Would require any ebuild suffering from this bug to run elibtoolize - even if the package doesn't use libtool.
con: Will be applied when elibtoolize is used even when the package ships with the automake fix.


* flex.ebuild:
apply attachment#485382 [details, diff], because flex is the only package (for now?) suffering from this automake bug

con: Would require any ebuild suffering from this bug to apply this workaround.
pro: Can easily be dropped once the package ships with the automake fix.


To me, attachment#485382 [details, diff] feels most simple and least intrusive here, as I do not expect hundreds of packages to suffer from this automake bug.

[Comment 2 Michael Haubenwallner (RETIRED) 2017-09-13 12:07:02 UTC]

Created attachment 494352 [details, diff]
ebuild patch to apply upstream commit working around automake bug

This patch will be part of flex-2.6.5 release.

[Comment 3 Larry the Git Cow 2017-10-13 20:19:31 UTC]

The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=aa6c077d00c3a21b75ae646421aefadcad527f80

commit aa6c077d00c3a21b75ae646421aefadcad527f80
Author:     Thomas Deutschmann <[e-mail]>
AuthorDate: 2017-10-13 20:16:10 +0000
Commit:     Thomas Deutschmann <[e-mail]>
CommitDate: 2017-10-13 20:19:23 +0000

    sys-devel/flex: Rev bump to fix multiple problems
    
    Closes: https://bugs.gentoo.org/628744
    Closes: https://bugs.gentoo.org/625508
    See: https://bugs.gentoo.org/632523
    Package-Manager: Portage-2.3.10, Repoman-2.3.3

 .../flex-2.6.4-fix-build-with-glibc2.6+.patch      | 767 +++++++++++++++++++++
 sys-devel/flex/files/flex-2.6.4-libobjdir.patch    |  26 +
 sys-devel/flex/flex-2.6.4-r1.ebuild                |  85 +++
 3 files changed, 878 insertions(+)