Closed thom-nic closed 6 years ago
So, I installed libtool on my host machine and made the error go away. I'm not familiar with libtool but my goal is to cross-compile to a busybox (not statically-linked) armhf target. I was able to cross-build by doing the following...
# ./configure --host=arm-linux-gnueabihf --prefix=/ CC=arm-linux-gnueabihf-gcc LD=arm-linux-gnueabi-ld
... snip configure output ...
# make
... snip make output ...
# file mdnsd
mdnsd: Bourne-Again shell script, ASCII text executable, with very long lines
# file .libs/mdnsd
.libs/mdnsd: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=bc2dc7f122510249af7acf963c04fd3b65eb508f, not stripped
# make install DESTDIR=/root/busybox-initramfs/build/rootfs
Making install in libmdnsd
make[1]: Entering directory '/root/mdnsd/libmdnsd'
make[2]: Entering directory '/root/mdnsd/libmdnsd'
/bin/mkdir -p '/root/busybox-initramfs/build/rootfs//lib'
/bin/bash ../libtool --mode=install /usr/bin/install -c libmdnsd.la '/root/busybox-initramfs/build/rootfs//lib'
libtool: install: /usr/bin/install -c .libs/libmdnsd.so.0.0.0 /root/busybox-initramfs/build/rootfs//lib/libmdnsd.so.0.0.0
libtool: install: (cd /root/busybox-initramfs/build/rootfs//lib && { ln -s -f libmdnsd.so.0.0.0 libmdnsd.so.0 || { rm -f libmdnsd.so.0 && ln -s libmdnsd.so.0.0.0 libmdnsd.so.0; }; })
libtool: install: (cd /root/busybox-initramfs/build/rootfs//lib && { ln -s -f libmdnsd.so.0.0.0 libmdnsd.so || { rm -f libmdnsd.so && ln -s libmdnsd.so.0.0.0 libmdnsd.so; }; })
libtool: install: /usr/bin/install -c .libs/libmdnsd.lai /root/busybox-initramfs/build/rootfs//lib/libmdnsd.la
libtool: install: /usr/bin/install -c .libs/libmdnsd.a /root/busybox-initramfs/build/rootfs//lib/libmdnsd.a
libtool: install: chmod 644 /root/busybox-initramfs/build/rootfs//lib/libmdnsd.a
libtool: install: arm-linux-gnueabihf-ranlib /root/busybox-initramfs/build/rootfs//lib/libmdnsd.a
libtool: warning: remember to run 'libtool --finish //lib'
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/root/mdnsd/libmdnsd'
make[1]: Leaving directory '/root/mdnsd/libmdnsd'
make[1]: Entering directory '/root/mdnsd'
make[2]: Entering directory '/root/mdnsd'
/bin/mkdir -p '/root/busybox-initramfs/build/rootfs//bin'
/bin/bash ./libtool --mode=install /usr/bin/install -c mquery '/root/busybox-initramfs/build/rootfs//bin'
libtool: warning: 'libmdnsd/libmdnsd.la' has not been installed in '//lib'
libtool: install: /usr/bin/install -c .libs/mquery /root/busybox-initramfs/build/rootfs//bin/mquery
/bin/mkdir -p '/root/busybox-initramfs/build/rootfs//sbin'
/bin/bash ./libtool --mode=install /usr/bin/install -c mdnsd '/root/busybox-initramfs/build/rootfs//sbin'
libtool: warning: 'libmdnsd/libmdnsd.la' has not been installed in '//lib'
libtool: install: /usr/bin/install -c .libs/mdnsd /root/busybox-initramfs/build/rootfs//sbin/mdnsd
/bin/mkdir -p '/root/busybox-initramfs/build/rootfs//share/doc/libmdnsd'
/usr/bin/install -c -m 644 README.md LICENSE '/root/busybox-initramfs/build/rootfs//share/doc/libmdnsd'
/bin/mkdir -p '/root/busybox-initramfs/build/rootfs//include'
/bin/mkdir -p '/root/busybox-initramfs/build/rootfs//include/libmdnsd'
/usr/bin/install -c -m 644 libmdnsd/mdnsd.h libmdnsd/1035.h libmdnsd/sdtxt.h libmdnsd/xht.h '/root/busybox-initramfs/build/rootfs//include/libmdnsd'
make[2]: Leaving directory '/root/mdnsd'
make[1]: Leaving directory '/root/mdnsd'
# ./libtool --finish /root/busybox-initramfs/build/rootfs/lib
...
Going to test this now and see if it works as expected.
There is still some way to go with this project before it's usable to other ppl. Right now you need all the GNU auto-tools to build from GIT, but when it's done (and released) the tarball will contain the a pre-generated stand-alone configure script and Makefile.in file(s).
I haven't tested cross-compiling this project myself yet, but in theory it should work by adding --host=$(CROSS_TARGET)
to the configure script.
Actually, the above appears to work: From my device:
# mdnsd $(hostname) 192.168.1.100 80 '/login'
Announcing .local site named 'foodevice' to 192.168.1.100:80 and extra path '/login'
When I query using dns-sd
on mac...
$ dns-sd -B _http._tcp
Browsing for _http._tcp
DATE: ---Mon 09 Jul 2018---
15:48:51.414 ...STARTING...
Timestamp A/R Flags if Domain Service Type Instance Name
15:48:51.416 Add 3 5 local. _http._tcp. Brother MFC-asdfasdf
15:48:51.416 Add 3 5 local. _http._tcp. switchabcdf
15:48:51.416 Add 3 5 local. _http._tcp. switchd12345
15:48:51.416 Add 3 5 local. _http._tcp. switchb0012f3
15:48:51.416 Add 3 5 local. _http._tcp. Canon MB5000 series
15:48:51.416 Add 3 5 local. _http._tcp. switch123123
15:48:51.416 Add 3 5 local. _http._tcp. foodevice <---- it showed up!!
^C
However lookup (PTR record?) changes the hostname:
$ dns-sd -L foodevice _http._tcp
Lookup foodevice._http._tcp.local
DATE: ---Mon 09 Jul 2018---
15:55:46.812 ...STARTING...
15:55:46.813 foodevice._http._tcp.local. can be reached at http-foodevice.local.:80 (interface 5)
path=/login
^C
Note http-foodevice.local
instead of foodevice.local
.
Most importantly, A
record query looks like it is working correctly:
$ ping http-foodevice.local
PING http-foodevice.local (192.168.8.179): 56 data bytes
64 bytes from 192.168.1.100: icmp_seq=0 ttl=64 time=1.952 ms
My primary need is actually, I know the hostname and I want to find its IP in a zeroconf environment. (even though the above is shown on a DHCP network.)
Cool! :-)
Haven't really read up on the RFC in detail yet, but I'm willing to bet the http-
prefix is something from the pre-official RFC days. If you find it in the code (and not mentioned in the RFC) you're very welcome to submit a pull-request to drop it.
Yeah it was easy to spot: https://github.com/troglobit/mdnsd/blob/master/mdnsd.c#L114
It looks like the original intent of the tool was a bit http-service-centric (e.g. I can't specify a _ssh._tcp
) but that's less important to me. Also it should not be difficult to specify a service type argument. @troglobit how much do you care about CLI backward compatibility?
Ah, hiding in plain sight! :)
Haven't gotten around to cleaning up the CLI yet, but was aiming at something similar to what I've done for my other projects, e.g. the uftpd usage paints a quite clear picture.
You're free to clean up and fix whatever you like. Would be neat to fix _ssh._tcp
as well ... :-)
Apologies if I'm doing something obviously wrong, I'm not well versed in native linux development.