All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Smith <psmith@netezza.com>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: autofs@linux.kernel.org
Subject: Re: autofs won't cross-compile
Date: Tue, 14 Nov 2006 17:46:18 -0500	[thread overview]
Message-ID: <1163544378.32038.6.camel@localhost> (raw)
In-Reply-To: <x491wodki3x.fsf@segfault.boston.devel.redhat.com>

On Wed, 2006-11-08 at 11:39 -0500, Jeff Moyer wrote:
> Paul Smith <psmith@netezza.com> writes:
> 
> > Hi all; autofs's configure.in is not properly set up to allow for
> > cross-compiling.  It fails trying to detect -fPIE, because configure.in
> > runs AC_RUN_IFELSE to run a program (which of course can't work during
> > cross-compilation) and does not provide a cross-compilation result.
> >
> > I'm not sure why this test for PIE exists or if it's really needed, but
> > if you want to keep it please add an argument for cross-compilation.
> > Patch is attached, against 4.1.4 (but I checked 5.00beta1 and it had the
> > same issue).  As recommended by the autoconf manual, this patch is
> > pessimistic and assumes no PIE support for all cross-compilation
> > environments.
> >
> > I've split the patch into two: one for configure.in and one for
> > configure itself (I'm not sure if you source code control the configure
> > script: some projects do and some don't).
> 
> This is the wrong way to go about it.  We should probably provide a
> --enable-PIE or some such option.  That way, anyone who cross-compiles
> has the option of enabling it.

That's fine, but why not leave the default as "off", as in my patch?  If
you don't want to do that then please at least add a 5th argument to
AC_RUN_IFELSE to print some kind of message telling the user what to do
(use --enable-pie or --disable-pie).  If you leave it as-is, then
configure just bombs out with a scary error message when it hits that
AC_RUN_IFELSE.

I did find a few other items which broke during cross-compilation; there
are a number of checks in configure looking for programs that live on
the disk, like mount etc.  It's a bit unpleasant since these could
potentially live somewhere different on the target system than they do
on the build system.  One idea would be to have configure options for
these as well.

However, with FHS etc. it's probably not TOO much of a stretch to
imagine these locations are fairly standard.  There is one item, though,
which did bite me: the test for the -s option to mount.  My build system
has it, but my target system uses BusyBox mount which doesn't support
-s.  There is no easy way to turn this off: I had to go in and patch
things to disable it.  It would be nice to have this as a configure
option, or something.

After these changes it does work... yay!

Cheers!

-- 
-----------------------------------------------------------------------------
 Paul D. Smith <psmith@netezza.com>                       http://netezza.com
 "Please remain calm--I may be mad, but I am a professional."--Mad Scientist
-----------------------------------------------------------------------------
      These are my opinions--Netezza takes no responsibility for them.

  reply	other threads:[~2006-11-14 22:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-07 19:36 autofs won't cross-compile Paul Smith
2006-11-08 16:39 ` Jeff Moyer
2006-11-14 22:46   ` Paul Smith [this message]
2006-12-11  5:43     ` Ian Kent

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1163544378.32038.6.camel@localhost \
    --to=psmith@netezza.com \
    --cc=autofs@linux.kernel.org \
    --cc=jmoyer@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.