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

David Hauck davidh at
Wed Mar 9 19:55:51 UTC 2016

On Wednesday, March 09, 2016 11:39 AM, Uri Simchoni wrote:
> On 03/09/2016 09:26 PM, David Hauck wrote:
>> On Wednesday, March 09, 2016 10:42 AM, Uri Simchoni wrote:
>>> On 03/09/2016 05:10 PM, David Hauck wrote:
>>>> Hi Uri,
>>>> On Mon, 7 Mar 2016 at 11:53:00, samba-technical wrote:
>>>>> Hi Uri,
>>>>> On Monday, March 07, 2016 11:52 AM, Uri Simchoni wrote:
>>>>>> On 03/07/2016 08:59 PM, David Hauck wrote:
>>>>>>> NCURSES_CONFIG='<cross-dir>/bin/ncurses6-config' waf configure
>>>>>> Yeah that's what you need to do. You can look at the source code
>>>>>> for find_program and see that if it's set in the env then that's
>>>>>> what it'll take (for find_program, not necessarily in a general way).
>>>>>> But your ncurses6-config must also not be broken, a challenge in
>>>>>> itself. Run /cross/ncurses6-config --clfags --libs and see if it
>>>>>> gets you anything reasonable.
>>>>> Yes, it does, it gets me exactly what I want/need: i.e.,
>>>>> -lncurses
>>>>> (only) and not -lncurses -ltinfo (which the host variant returns).
>>>> You previous answer probably implied this, but I just wanted to
>>>> make
>>>> sure: would calling 'waf configure' like I proposed above work?
>>> Looks like it. Best thing is to try.
>> Yes, for sure, and I will do this, just wanted to get an opinion on
>> this from
> someone who's a waf expert.
> :) Wouldn't call myself an expert, just someone with some waf (and
> scons) hands-on experience and some Python know how. FWIW, In upstream
> waf this is the documented way.
>>> To be sure what configure came up
>>> with have a look at bin/c4che/
>> I'm not seeing anything related to either NCURSES_CONFIG or PATH in
>> the
> above file. Perhaps you mean check LIB_ncurses after these runs to see
> if this is properly set to 'ncurses' and not 'ncurses tinfo'?
> Strange..
> [uri at uri-dell s2]$ grep NCURSES_CONFIG bin/c4che/
> NCURSES_CONFIG = '/bin/ncurses5-config'

OK, I think I probably know what's going on here: the current version of this file is a result of the 'waf configure' occurring with "--without-regedit", which likely prevents this wscript_configure_system_ncurses from being invokded (?).

I'll try again with the below considerations included.
> I wouldn't expect PATH to be there, it's not part of the build env.
>>>> And also, given the several other places where 'pkg-config'-like
>>>> scripts are
>>> called I'm wondering whether a similar approach is recommended? Yes,
>>> but only for cross-built packages (for example not to xslt package
>>> which generates documentation). Last time I checked the candidates
>>> were: - Python (but you NEED a good python2.7-config, the CPython one
>>> is no good for cross builds) - ncurses - if you are NOT using the
>>> bundled Heimdal, you need something for Kerberos.
>>>> Alternatively, is there some way to get "find_program" to use the
>>>> current
>>> PATH (which in my case should have identified the cross variants of
>>> these scripts)? If this latter consideration worked then it would
>>> suffice to require that the cross variants of all 'pkg-config'-like
>>> scripts simply be in the PATH (ahead of the host variants).
>>> That's exactly what it does - scan all directoried in PATH
>>> according to the order in PATH. I verified it by putting a
>>> breakpoint at
> find_program().
>> Hmmm, very interesting. Then this should have "just worked" for me
>> (since
> my cross directory is the first thing in the PATH). I'll try to figure
> out why this doesn't seem to be working in my build environment. Any
> hints are where I can go to find out how to get waf to output more
> detail regarding these steps (e.g., is 'waf -v' enough here?)?
> Crash-course in Python debugging:
> Edit third_party/waf/wafadmin/, in function
> find_program_impl(), just above the line that reads "if not path_list:
> ....", enter this:
> import pdb; pdb.set_trace()
> (and make sure it has exactly the same indentation as the line below it)
> Then run configure and it would stop in the Python debugger and you'll
> be able to see what path you get. That's what I did to verify my
> answer above.

Nice tip, I'll try this ;). 

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

More information about the samba-technical mailing list