0

I try to build sqlite-jdbc on aarch64 machine, using specific version of sqlite that is on my computer.

I tried to follow this guide and use autoreconf to build this package, using configure --with-sqlite to this path, but it fails on guessing the arch.

I downloaded the last config.guess & config.sub files, which solved me this problem recently, but not in this case.

Specifying build to configure in --build/host/target, did not solve the issue, because configure was lookging for install.sh and did not find it. I know there is an option to build using docker by make linux-arm64 command, but i did not find how to specify the sqlite version i want.

RD7
  • 628
  • 4
  • 9
  • 20
  • To confirm, you are building on the same machine on which you want to use the software? – John Bollinger Apr 01 '19 at 14:16
  • And if so, have you tried building (from a freshly unpacked source tree) *without* first running `autoreconf`, and without using any of `--build`, `--host`, or `--target`? – John Bollinger Apr 01 '19 at 14:22
  • Yes, I'm building on the same machine on which I want to use the software. building without configuring the sqlite version won't help me, and without autoconf this file is not exist. anyway, 'make' command is searcing for docker images to build, i would like to build it locally. – RD7 Apr 02 '19 at 05:23
  • or even on docker - i want to specify locally compiled version of sqlite, i don't find easy way to do it. – RD7 Apr 02 '19 at 05:31
  • 1
    An Autotools-based project *should* be distributed with pre-built `configure` script, `Makefile.in` file(s), and other needed Autotools and Autools-built components. One is not supposed to require their own copy of the Autotools to configure and build the project -- the first thing to try is always to go straight to running `configure`. In practice the success rate with doing that varies, but when it does work, it's a huge time- and effort saver. – John Bollinger Apr 02 '19 at 11:47
  • But if you do run `autoreconf`, then you should pass it the `--install` and `--force` flags. This will cause it to install all the appropriate helper scripts and files, overwriting any that are already present to ensure that you have the versions that go with your version of the Autotools. You do not need to search for `config.guess`, `install.sh`, or other such files, and you should not install random versions of them that you happen to find on the Net. – John Bollinger Apr 02 '19 at 11:51
  • Having done that, you should not need to specify any of `--host` *etc*. to perform a native build -- *i.e.* to build a version intended to run on the same OS and machine architecture as the one where it was built. It should not matter whether the build environment is emulated, virtual, or real, so long as it has the appropriate build tools for building software for itself. – John Bollinger Apr 02 '19 at 11:54
  • I did run autoreconf with -ivf. i solved this issue by hacking Makefile, but this is not portable solution and i don't lije to think i have to do it any time i want to compile it. just for example, now the .so file is exist, but jar file was not built, not sure why – RD7 Apr 03 '19 at 06:09
  • Not all configure scripts depend on determining the build machine's architecture, but yours does. That requires that the build system have been built with a version of the Autotools (specifically Autoconf) that supports the architecture in question. Support for aarch64 was added to Autoconf in version 2.69, which is the latest release and (only) a couple of years old. If you are not already using that version then you'll probably need to upgrade to it. After upgrading, run `autoreconf -if` (or `-ivf`) again. – John Bollinger Apr 03 '19 at 12:05

0 Answers0