Re: Patch to fix autoconf/strip for cross-compiling

[Daniel Miller <bonsaiviking () gmail com>]

On Sun, Feb 8, 2015 at 4:44 PM, Vlatko Kosturjak <kost () linux hr> wrote:

> Hello!
>
> Nmap is configured to use AC_PATH_TOOL instead of AC_CHECK_TOOL for finding
> strip binary. Since strip is architecture dependant, it is more convient
> to use AC_CHECK_TOOL instead.
>
> In short, if someone specify --host=my-cc-host, currently nmaps uses
> system wide strip in PATH rather than trying my-cc-host-strip first.
> This patch fixes that and it makes cross compilers happy.
>
> You can read more about these options:
> http://www.delorie.com/gnu/docs/autoconf/autoconf_41.html

kost,

I understand the benefit to checking for arch-specific tools, but that link
(and my own test below) seem to indicate that both AC_CHECK_TOOL and
AC_PATH_TOOL first check for host-specific tools, the difference being that
CHECK does not use the full path to the tool.

 $ ./configure --host=x86_64-linux-gnu | grep strip
checking for x86_64-linux-gnu-strip... /usr/bin/x86_64-linux-gnu-strip
config.status: WARNING:  'Makefile.in' seems to ignore the --datarootdir
setting
checking for x86_64-linux-gnu-strip... /usr/bin/x86_64-linux-gnu-strip
config.status: WARNING:  'Makefile.in' seems to ignore the --datarootdir
setting
=== configuring in libdnet-stripped
(/home/miller/nmap/nmap/libdnet-stripped)
configure: WARNING: If you wanted to set the --build type, don't use --host.
    If a cross compiler is detected then cross compile mode will be used.
checking for x86_64-linux-gnu-strip... x86_64-linux-gnu-strip
checking for x86_64-linux-gnu-strip... (cached) x86_64-linux-gnu-strip
checking whether stripping libraries is possible... yes
config.status: WARNING:  'Makefile.in' seems to ignore the --datarootdir
setting
checking for x86_64-linux-gnu-strip... /usr/bin/x86_64-linux-gnu-strip
config.status: WARNING:  'Makefile.in' seems to ignore the --datarootdir
setting

Can you show some examples of the current configure script treating these
differently? I did check for instances of AC_*_PROG, since those are the
more-problematic calls, but I don't know if these need to be replaced:

$ grep -r --include '*.ac' --include '*.in' 'AC_[A-Z]*_PROG\>'
nbase/configure.ac:dnl AC_PATH_PROG(MAKEDEPEND, makedepend)
nsock/src/configure.ac:dnl AC_PATH_PROG(MAKEDEPEND, makedepend)
libpcap/configure.in:   AC_CHECK_PROG([PKGCONFIG], [pkg-config],
[pkg-config], [no])

Dan

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/