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

[David Hauck]

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/default.cache.py.
>> 
>> 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/default.cache.py
> NCURSES_CONFIG = '/bin/ncurses5-config'
> 
> 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/Configure.py, 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.

OK, this was perfect and explains what's been going on with all of this. The other relevant 'pkg-config' like scripts are properly being found as a result of the cross toolchain variant's being first in the PATH (and 'find_program' legitimately finds these). For 'ncurses', however, the wscript_configure_system_ncurses first looks for 'ncurses5-config', which does not exists in the cross toolchain since 'ncurses6-config' is there instead, and so it ends up finding this in the system (after searching the system paths near the end of the PATH environment's list). 

So I believe the general question of proper 'pkg-config' behaviour in the cross build is answered (and this is being done correctly). The specific question of the 'ncurses' handling (i.e., a side effect of the ncurses5 vs ncurses6 detection) is that this may sometimes fail in the cross environment. I don't see a clear way to solve this in the scripts so I suppose a workaround solution is to use the 'NCURSES_CONFIG='<cross-dir>/bin/ncurses6-config' waf configure' pattern for now.

Thanks for helping me run this down - I learned a bit in the process, which is always nice ;).
 
>> Thanks,
>> -David
>> 
>>>> Thanks again,
>>>> -David
>>>> 
>>>>> Thanks,
>>>>> -David
>>>>> 
>>> 
>>> Hope that helps,
>>> Uri.