cross-compilation issues in 5.2

[greg . roelofs]

Hi, Thomas et al.,

I've grep'd through a few of the post-5.2 patches, and while it looks like
a few things have changed (hopefully improved) w.r.t. cross-compilation,
but I'm on a tight schedule and haven't had a chance to try the latest
beta.  Since I'm about to move on, I wanted to note a couple of small
problems, just in case one or the other isn't fixed yet:

 - In general, I think of "host" and "build" as synonymous (which seems
   also to be the view of 5.2's ncurses/Makefile.in, in which HOSTCC is
   equated with @BUILD_CC@).  But the configure script tests whether host
   != build in deciding whether to do anything with BUILD_CC, and since
   the two are generally equal even in a cross-compilation environment,
   the build fails.  I believe the test should be whether target != build.
   For now I've worked around this by explicitly giving a --build option
   to configure (see below).

 - ncurses/Makefile.in includes -L$(libdir) in SHLIB_DIRS.  But libdir is
   derived from prefix, which is a target directory, whereas SHLIB_DIRS
   is a host/build variable.  On Linux/x86/glibc 2.2.x, this results in
   300KB of error messages when the cross-compiler attempts to link with
   one or more of the host's libraries in /usr/lib.  Insofar as SHLIB_DIRS
   is hardcoded, there doesn't seem to be any way to work around this via
   configure; I had to edit the makefile directly to remove -L$(libdir).

For reference, here's the configure command I ended up with:

        BUILD_CC=gcc CC=mipsel-linux-gcc \
        CFLAGS="-O2 -Wall -Wmissing-prototypes" LDFLAGS=-static \
        ./configure --prefix=/usr --with-shared --with-normal --without-debug \
        
--with-fallbacks=ansi,ansi-m,color_xterm,linux,pcansi-m,rxvt,vt100,vt102,vt220,xterm
 \
        --disable-database --build=x86-unknown-linux-gnu \
        --target=mipsel-unknown-linux-gnu

Note that configure sets host=i686-pc-linux-gnu, so the host/build test
finds inequality and proceeds to honor the BUILD_CC variable.

It might also be nice if there were a way to override the HOSTCCFLAGS and
HOSTLDFLAGS (insofar as one might wish to use a MIPS-specific compiler
option that the host compiler doesn't recognize or interprets differently),
but I didn't run into this problem (aside from -static, which was basically
harmless).

Regards,
--
Greg Roelofs            `Name an animal that's small and fuzzy.' `Mold.'
Philips Semiconductors   address@hidden