Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cross-compilation 'configure' broken - hard-coded paths #17

Open
roliver opened this issue Dec 18, 2017 · 4 comments
Open

Cross-compilation 'configure' broken - hard-coded paths #17

roliver opened this issue Dec 18, 2017 · 4 comments

Comments

@roliver
Copy link

roliver commented Dec 18, 2017

Hi,

I'm currently trying to cross-compile Xastir for an i386 embedded system using Buildroot.

The m4 macros XASTIR_DETECT_BINARIES sets BINPATH to hard-coded system paths such as /usr/local/bin. This causes problems as configure flags false-positives such as finding festival/lpr on my host system. configure also flags false-negatives as it can't find X libraries in the target sysroot.

Kind regards,
Richard

@tvrusso
Copy link
Member

tvrusso commented Dec 18, 2017

You're quite right, Xastir's configure is very broken for cross-compilation. Some of its probes actually run programs (such as the one that tries to work out the version of gv), which is a huge no-no for cross-compilation-friendliness. I think you may find that there are other things downstream of the XASTIR_DETECT_BINARIES call that are just as unfriendly to cross-compilation.

Unfortunately, I don't think anyone is going to be able to work through configure and fix it for you. You seem to be the first person to have tried to cross-compile Xastir. You will probably have to hack on it yourself to get it working. A quick fix might be to make XASTIR_DETECT_BINARIES not set up the BINPATH variable from standard locations if that variable is already defined, perhaps something like this:

 if [ "x$BINPATH" = "x" ]
 then
   BINPATH=$PATH

   for d in / /usr /usr/local /usr/X11 /usr/X11R6 /usr/sfw /opt/sfw /opt/local /sw; do
   test -d $d/bin && echo $BINPATH | grep -- $d/bin > /dev/null || BINPATH="$BINPATH:$d/bin"
   done
 fi

Then, you could simply set it on the configure line (e.g. "/path/to/configure BINPATH='/my/target/sysroot/bin:/my/target/sysroot/sbin'") and XASTIR_DETECT_BINARIES would only look where you tell it, and not in any of your host system's directories. Not sure that would be enough to get you past this problem, but it's where I would start.

As for not being able to detect the X11 libraries for the target system, that's not our macros that are screwing up, it's AC_PATH_XTRA, which is part of the autoconf suite. It allows you to force it to look in a particular place if you add some command line flags at configure time. If you do "configure --help" you'll see those options:

 X features:
  --x-includes=DIR    X include files are in DIR
  --x-libraries=DIR   X library files are in DIR

So you probably need to use one of these to force configure to look for X libraries in your target sysroot instead of locally.

If you find a solution to this that doesn't break native builds, please feed it back to the project via a pull request.

@roliver
Copy link
Author

roliver commented Dec 18, 2017

Hi @tvrusso , thanks for your response. I don't have much experience with autotools but I'll certainly send a patch if I get it working. My main motivation for this is to get a xastir-only minimal linux system with a < 5s boot time.

Cheers,
Richard

@tvrusso
Copy link
Member

tvrusso commented Dec 18, 2017

Sorry I can't be of more direct assistance here. I've not done cross-compiling of anything in years, but know that one has to be really careful in configure not to do unsafe things like running test programs or utilities --- only compiling and linking should be done in cross-compile-safe configures. Since Xastir makes use of utility programs (gv, gm, convert, lpr, etc.) all over the place, this can make it difficult. Most of the energy put into configure has been to make as much as possible automatically detected, but without providing ways to override that automatic detection from the command line.

I'm happy to offer autoconf assistance as you work through this, but since I have no cross-compilation environment set up, most of my assistance would be to suggest things to try (such as in my earlier comment about making BINPATH something you can override manually when the default behavior isn't acceptable).

I'm interested in what sort of embedded system you're trying to create.

@roliver
Copy link
Author

roliver commented Dec 18, 2017

Thanks for the advice. Yes, I believe the utilities will be the tricky bit. I believe that autotools has seperate concepts for host-utilities and target-utilities though so hopefully that will help solve the problem.

In terms of my embedded system, I've pre-ordered one of the XTRX SDRs which I'm hoping to integrate into a rugged laptop (something like a Panasonic Toughbook CF-19). The XTRX is built completely onto a miniPCIe card so I should be able to integrate it inside the laptop itself. The idea is to have a completely disconnected/portable APRS terminal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants