Samba v4.2.0 vs. v4.3.5 and -ltinfo

[David Hauck]

Hi Uri,
 
On Saturday, March 05, 2016 12:57 PM, Uri Simchoni wrote:
> On 03/04/2016 11:32 PM, David Hauck wrote:
>> Hi Uri,
>> 
>> Thanks for your note, please see below.
>> 
>> On Friday, March 04, 2016 11:26 AM, Uri Simchoni wrote:
>>> On 03/04/2016 07:48 PM, David Hauck wrote:
>>>> Hello,
>>>> 
>>>> I've been working on migrating my cross-build from v4.2.0 to
>>>> v4.3.5 (latest
>>> stable). I finally got this building but wanted to ask about the
>>> one build failure I initially encountered. Specifically this
>>> related to a missing libtinfo.so. My build environment includes
>>> 'ncurses' built without the --with-termlib autoconf parameter set
>>> (hence no libtinfo) and so packages that rely on 'ncurses', and
>>> that expect to use -ltinfo, will
> fail during link.
>>>> 
> <snip>
> 
>>> Haven't looked into that, but I know that adding ncurses to build
>>> env broke our (cross) samba build, and that --without-regedit in
>>> samba configure was the workaround. So if you don't need regedit
>>> that could be
> a quick fix.
>> 
>> My failure is occurring here:
>> 
>> /home/dhauck/production/factory/build_i686-netacquire-linux-gnu/tool ch
>> ain/lib/gcc/i686-netacquire-linux-gnu/4.9.3/../../../../i686-netacqu ir
>> e-linux-gnu/bin/ld: cannot find -ltinfo collect2: error: ld returned 1
>> exit status Waf: Leaving directory
>> `/home/dhauck/production/factory/build_i686-
>> netacquire-linux-gnu/samba-4.3.5/samba-4.3.5/bin' Build failed:  ->
>> task failed (err #1): 	{task: cc_link
>> client_1.o,popt_common_5.o,smbreadline_1.o,popt_credentials_6.o,clil sa
>> _2.o -> smbclient4} target/software/Networking/samba/samba.mk:54:
>> recipe for target
>> '/home/dhauck/production/factory/build_i686-netacquire-linux- gnu/samba
>> -4.3.5/.stamp_built' failed
>> 
>> The waf build hides (by default I guess - presumably there is a way
>> to get it
> to be more verbose about what it's doing?) where this is actually
> happening, but this first occurrence seems to be in the attempted link for 'smbclient4'.
> Does --without-regedit have an impact on this target as well (and
> potentially all other targets that appear to be attempting to link with -ltinfo)?
> 
> I can confirm that removing --without-regedit gives me the same error
> message. Probably it adds the -ltinfo for binaries other than regedit.

OK, thx. I can probably live with this workaround.

>>> After a quick look, I would guess that the samba configuration
>>> script for ncurses does not support cross-compiling because it runs
>>> ncurses5-config or ncurses6-config, but the wrong ones - the system
>>> ones. See source3/wscript_configure_system_ncurses.
>> 
>> This script references 'ncurses' but not 'tinfo'  specifically (or
>> is there
> something subtle/indirect in the way this script results in the
> eventual usage of -ltinfo?).
> The indirect thing is the invocation of ncurses5-config or
> ncursers6-config - that's a pkgconfig-style program, which outputs the
> linker and compiler flags needed for ncurses integration. Running the
> native, or system, ncurses6- config for a cross-build is fundamentally
> wrong, and that's a bug of the build system.
> 
> The ncurses(5|6)-config invocation is attempted if --without-regedit is
> NOT specified AND if the ncurses.h headers are found. Since you seem to
> have ncurses headers in your cross-build env, the way for you to avoid
> this link flag (other than fixing the Samba configure script, and of
> course I'd love to see a fix) is to specify --without-regedit (assuming
> you can manage without regedit).

I'm really not sure how the Samba waf configure framework can be massaged in this regard to mimic other autoconf packages, but I've seen these other packages use 'pkg-config' to determine whether 'tinfo' is present. For example, here's a package (util-linux) I found that does this (from configure.ac):

AC_ARG_WITH([tinfo], AS_HELP_STRING([--without-tinfo], [compile without libtinfo
]),
  [], [with_tinfo=auto]
)
have_tinfo=no
AS_IF([test "x$with_tinfo" != xno], [
  dnl Try pkg-config for libtinfo
  PKG_CHECK_MODULES(TINFO, [tinfo], [
    dnl pkg-config success
    have_tinfo=yes
    UL_PKG_STATIC([TINFO_LIBS_STATIC], [tinfo])], [

    dnl If pkg-config failed, fall back to classic searching.
    AC_CHECK_LIB([tinfo], [tgetent], [
       have_tinfo=yes
       TINFO_LIBS="-ltinfo"
       TINFO_LIBS_STATIC="-ltinfo"
       TINFO_CFLAGS=""])
  ])
])
AC_SUBST([TINFO_LIBS])
AC_SUBST([TINFO_LIBS_STATIC])
AC_SUBST([TINFO_CFLAGS])
AM_CONDITIONAL([HAVE_TINFO], [test "x$have_tinfo" = xyes])
AS_IF([test "x$have_tinfo" = xyes], [
  AC_DEFINE(HAVE_LIBTINFO, 1, [Define if libtinfo available.])
])

In my build environment the PKG_CONFIG_PATH and PKG_CONFIG_LIBDIR environment variables are used to point to the cross-toolchain's location for the pkg-config files (and further, this environment uses PKG_CONFIG, which points to the cross-toolchain's version of 'pkg-config', to invoke the target's 'pkg-config'). In this way the proper package configuration can be located/queried. Is the idea of using the cross variant of 'pkg-config' present in the Samba 'cross-build' infrastructure? 

It's true also though that my host's ncurses[5]-config includes '-lncurses -ltinfo' while my cross-toolchain version of ncurses[6]-config returns '-lncurses'. Is there some way to prefix (or otherwise parameterize) the 'ncurses[56]-config' invocation in wscript_configure_system_ncurses with the proper path for the location of this script? If so, then the script, as-is, would work fine since it would just use my cross variant of 'ncurses6-config'.

I actually see that there are multiple, similar references in the waf "wscript*" files. These 'conf.find_program()' calls all do the same thing; they reference the located pkg-config like script to determine various cflag and lib configurations. I haven't looked at all of these in detail but at least some of them will need to use the cross-toolchain's version of these scripts. So again, some way to preface these with a parameterized location path would be ideal.

The WAF book's documentation on 'find_program' wasn't enough for me to determine whether just passing this information into the 'waf configure' command would be sufficient. For e.g., is the following sufficient for this?

NCURSES_CONFIG='<cross-dir>/bin/ncurses6-config' waf configure

Furthermore, what directories does 'find_program' search by default? My PATH is set up such that the cross-toolchain versions of all the *-config scripts will resolve before the host variants. So, if 'ncurses[56]-config' was called outright the correct version would have been found. 

OK, I'm starting to ramble now ;), but I think you probably get the gist of what I'm asking here...

Thanks,
-David

>> Thanks,
>> -David
>> 
>>> Hope that helps,
>>> Uri.