waf build of libbsd produces no exe's (for me)

[Chris Johns]

On 25/06/2015 10:46 am, Gene Smith wrote:
> On 06/22/2015 02:00 AM, Gene Smith wrote:
>> I have tried to build libbsd using the documented methods from
>> README.waf with no success, although the Makefile method seems to work
>> fine. Maybe I am doing something obviously wrong in the waf command
>> lines that is preventing the testsuite exe's files (.e.g.,
>> ping01/ping01.exe) from being produced.
> 
> Thanks for pointing out that the waf style build puts the outputs under
> build/ with no .exe. I should have seen that.

Building with waf is a new user experience and everyone is learning.
Your feedback to the list is valuable for everyone.

> 
> Anyhow, just want to report that the waf build of realview-pbx-a9-qemu
> is working close to ok and identically to the Makefile build. This
> includes the manual addition of tests that run tcpdump (modified
> netshell01).
> 

Excellent.

> There are three minor problems.
> 
> 1) when tcpdump is run from rtems shell, if "promiscuous" mode is set
> (no -p option provided) then the guest crashes or seems to. This is
> indicated by lack of ping responses at a remote or local host as soon as
> tcpdump is started in rtems shell. I.e., this crashes the guest (since
> pings from other host stop):
> 
> [/] # tcpdump -i smc0
> %s: promiscuous mode %s
> 
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on smc0, link-type EN10MB (Ethernet), capture size 65535 bytes
> 
> But this allows pings to continue and tcpdump shows packet info (rtems
> guest is 192.168.2.2):
> 
> [/] # tcpdump -p -i smc0
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on smc0, link-type EN10MB (Ethernet), capture size 65535 bytes
> 00:01:28.117849 IP 192.168.1.132 > 192.168.2.2: ICMP echo request, id
> 22951, seq 1, length 64
> 00:01:28.120912 IP 192.168.2.2 > 192.168.1.132: ICMP echo reply, id
> 22951, seq 1, length 64
> 

This is interesting. I will try it with the zynq and compare and report
back.

> 2) ctrl-c does not exit tcpdump back to the rtems shell but kills rtems
> shell. This was pointed out by Chris.

I am still not sure how to solve this one. We do not have signals nor
support in our shell and I need to think about a solution in tcpdump
that lets us update the source cleanly. It is needed.

> 
> 3) When starting the guest from the command line like this:
> 
> qemu-system-arm -M realview-pbx-a9 -m 256M -no-reboot -monitor none
> -serial stdio -nographic -net nic -net tap,ifname=tap0,script=no -kernel
> build/arm-rtems4.11-realview_pbx_a9_qemu/netshell01
> 
> There is a 30-45 second delay after this prints:
> 
> smc0: <SMSC LAN91C110FD or LAN91C111FD> on nexus0
> 
> Observing the tap0 interface at start up on the local linux host with
> tcpdump shows ipv6 activities with no apparent response. Something seems
> to be timing out:
> 
> sudo tcpdump -i tap0 -vv
> tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size
> 262144 bytes
> 19:45:38.277969 IP6 (hlim 1, next-header Options (0) payload length: 36)
> :: > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6,
> multicast listener report v2, 1 group record(s) [gaddr ff02::1:ff98:f98a
> to_ex { }]
> 19:45:38.450003 IP6 (hlim 1, next-header Options (0) payload length: 36)
> :: > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6,
> multicast listener report v2, 1 group record(s) [gaddr ff02::1:ff98:f98a
> to_ex { }]
> 19:45:38.824033 IP6 (hlim 255, next-header ICMPv6 (58) payload length:
> 24) :: > ff02::1:ff98:f98a: [icmp6 sum ok] ICMP6, neighbor solicitation,
> length 24, who has hplt.dbnet.lan
> 19:45:39.826110 IP6 (hlim 1, next-header Options (0) payload length: 36)
> hplt.dbnet.lan > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok]
> ICMP6, multicast listener report v2, 1 group record(s) [gaddr
> ff02::1:ff98:f98a to_ex { }]
> :
> :

I have no idea about this. I am not seeing it with the Zynq. I am using
VDE so it is also another difference. A different NIC on say a PC would
be a nice data point to get to help isolate this one.

Thanks for reporting the updated status.

Chris