ncurses-5.9-r101 fails

[mateuszmandera]

Ncurses 6.1 compiles fine, but 5.9 does not.
build.log

emerge --info

With *FLAGS-=-flto* it works.
Curious fact is that after I build it without LTO, I can get rid of the *FLAGS-=-flto* and rebuild and it compiles fine, with LTO enabled.

[InBetweenNames]

I just rebuilt it here without issues -- did you do a full system rebuild before trying it the first time?

[mateuszmandera]

I did. I can keep reproducing the issue, by emerge -C =ncurses-5.9-r101, and then trying to install it again with LTO fails. I can build it without LTO, and then rebuild it with LTO and it works.

[mateuszmandera]

Seems related to this? #66 and the setting of LDFLAGS+=-ldl # checking whether able to link to dl*() functions... in ltoworkaround.conf?

[InBetweenNames]

That workaround is necessary for both ncurses 5 and 6. However, in your case, it seems to only be applying sometimes. Can you attach this file from your failed build?

/var/tmp/portage/sys-libs/ncurses-5.9-r101/work/cross/config.log

[mateuszmandera]

config.log

[InBetweenNames]

If you modify the line in your ltoworkarounds.conf to:

  sys-libs/ncurses *FLAGS-=-Wl,--as-needed *FLAGS+=-ldl

does this help?

[InBetweenNames]

OK -- I actually managed to reproduce this on my system. Investigating.

[InBetweenNames]

Alright, I have it narrowed down. It looks like on the first build, it's working directory is cross, and it wants to build static libraries. On the second build, it uses CHOST as the working directory, and it builds it as a shared object.

Removing the -static flag from the test causes it to work. My real question right now, though, is why it's doing this behaviour.

[InBetweenNames]

It's something to do with crossdev for sure.

[InBetweenNames]

Interesting: after forcing the test to pass, it goes ahead with doing the correct configure using ncurses-5.9-abi_x86_64.amd64 anyway.

[InBetweenNames]

Ahh, found relevant lines from the ebuild:

 # When installing ncurses, we have to use a compatible version of tic.
    # This comes up when cross-compiling, doing multilib builds, upgrading,
    # or installing for the first time.  Build a local copy of tic whenever
    # the host version isn't available. #249363 #557598
    if ! ROOT=/ has_version "~sys-libs/${P}" ; then
        # We can't re-use the multilib BUILD_DIR because we run outside of it.
        BUILD_DIR="${WORKDIR}" \
        CHOST=${CBUILD} \
        CFLAGS=${BUILD_CFLAGS} \
        CXXFLAGS=${BUILD_CXXFLAGS} \
        CPPFLAGS=${BUILD_CPPFLAGS} \
        LDFLAGS="${BUILD_LDFLAGS} -static" \
        do_configure cross --without-shared --with-normal
    fi
    multilib-minimal_src_configure

[InBetweenNames]

Alright, so this actually affects both versions of ncurses. Removing -static from LDFLAGS here seems to prevent it from happening. As to the rationale for doing this, I'm unsure if it's still relevant or not.

[Althorion]

The workaround doesn’t seem to work:

$ fgrep ncurses /etc/portage/package.cflags/ltoworkarounds.conf 
sys-libs/ncurses *FLAGS-=-Wl,--as-needed *FLAGS+=-ldl # checking whether able to link to dl*() functions... configure: error: Cannot link test program for libdl (#111)

emerge --info '=sys-libs/ncurses-5.9-r101::gentoo' → https://gist.github.com/48ee83dad78afad3355425d8a29c33cf

Build log → https://gist.github.com/2380707a5060a38cb02d69baa383719d

[pchome]

We definitely have to figure out how to split the configure options and the build options.

Who knows how many errors are silently reported as checking ... no, with "extended" C*FLAGS/LDFLAGS, where a test is supposed to compile code sample.

[sjnewbury]

@pchome fwiw most packages will fail to configure if a test for an option specified on the configure command line doesn't pass. So any fails for other optional tests are probably for dependencies not specified in the ebuild and so should be disabled in that case anyway! ;-)

[InBetweenNames]

@sjnewbury @pchome is right though, because sometimes configure scripts will enable certain optimization settings or customization settings based on these tests. We actually have an open issue #171 where a situation like this is happening. I'm unsure how exactly to "trick" the configure scripts into ignoring the extended CFLAGS for tests like these. Manually patching them is an option if it's not a frequent problem.

[pchome]

@InBetweenNames

I'm unsure how exactly to "trick" the configure scripts into ignoring the extended CFLAGS for tests like these.

Maybe it should be something similar to https://github.com/vaeth/portage-bashrc-mv/blob/master/bashrc.d/50-ccache.sh