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

[Uri Simchoni]

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.

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