[Bug 1105368] [NEW] db: crossbuild and arm64 fixes

[Wookey]

Public bug reported:

db does not crossbuild for a new architecture. Nor would it crossbuild
for an existing architecture doing a stage1 profile build either (I
don't think). I couldn't even get it to natively build without nobbling
the db_signature thing. I don't understand how that is supposed to work,
so that part of the patch should be reviewed. It's disabled for the
crossbuild anyway so doesn't cause issue there. Although I don't see why
it shouldn't work the same in both cases...

So this patch works, but various things were confusing and this is very
much a 'version 0.1' cross/staging/arm64 patch. Smoone who knows the
package better could improve it.

The main config files are already uptodate and thus work for
arm64/aarch64, but the sub-files in the lang/sql dirs (actually 3 in
different dirs (sqlite, jdbc, odbc) are old. I tried to get dh-
autoreconf to update these with a debian/autoreconf file listing these
dirs (or just the lang/sql/sqlite dir, as the only one that actually
gets built) but it never put the old files back so a second build would
always halt on 'missing/changed files'. So this is a good old-fashioned
config.guess/sub patch, because that works. Again, only doing the one
dir that gets built out of these 3. I also tried explicit dh_autoreconf
and autoreconf_clean commands in the rules file, but still failed to get
it to work. I expect this could be done.

I tried a range of things to get past sqlite build errors. config.h from an external libsqlite-dev is needed because -D_HAVE_SQLITE_CONFIG_H is set so the build-dep for that is added to build deps. I don't know why the native build doesn't fall over this problem. Maybe I'm confused, but this worked for me. 
An alternative is the part of the patch that disables sql build and package, switched with ENABLE_SQL=no. 
It was also necessary to run configure on the lang/sql/sqlite dir otherwise it tries to do a native build there and ignores the configure setting to turn it off. I tried a number of things here and I'm not absolutely sure which combinations are needed. As it stands the SQL part of the build can be disabled, but is not disabled in stage1 as it does not seem to be necessary for a bootstrap (sqlite3 can be cross-built first). This WFM.

DEB_BUILD_OPTIONS=nocheck is not honoured by the rules file, and is
overwridden by cross/not cross state. This prevents a native stage1
build as --enable test also requires --enable-tcl. Interesting question
as to whether cross should set test state automatically, or if ot should
be left to build tools. Better fixes may well be possible here.

The clean target didn't clean the build dir or the generated
db_signature file. So a second build never worked. Tidied that too.

The rules files has inconsistent use of $(CURDIR) but I left that alone.

** Affects: db (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: arm64 cross patch

** Patch added: "db_5.1.29-5ubuntu4-cross-fix-2.patch"
   https://bugs.launchpad.net/bugs/1105368/+attachment/3500462/+files/db_5.1.29-5ubuntu4-cross-fix-2.patch

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to db in Ubuntu.
https://bugs.launchpad.net/bugs/1105368

Title:
  db: crossbuild and arm64 fixes

Status in “db” package in Ubuntu:
  New

Bug description:
  db does not crossbuild for a new architecture. Nor would it crossbuild
  for an existing architecture doing a stage1 profile build either (I
  don't think). I couldn't even get it to natively build without
  nobbling the db_signature thing. I don't understand how that is
  supposed to work, so that part of the patch should be reviewed. It's
  disabled for the crossbuild anyway so doesn't cause issue there.
  Although I don't see why it shouldn't work the same in both cases...

  So this patch works, but various things were confusing and this is
  very much a 'version 0.1' cross/staging/arm64 patch. Smoone who knows
  the package better could improve it.

  The main config files are already uptodate and thus work for
  arm64/aarch64, but the sub-files in the lang/sql dirs (actually 3 in
  different dirs (sqlite, jdbc, odbc) are old. I tried to get dh-
  autoreconf to update these with a debian/autoreconf file listing these
  dirs (or just the lang/sql/sqlite dir, as the only one that actually
  gets built) but it never put the old files back so a second build
  would always halt on 'missing/changed files'. So this is a good old-
  fashioned config.guess/sub patch, because that works. Again, only
  doing the one dir that gets built out of these 3. I also tried
  explicit dh_autoreconf and autoreconf_clean commands in the rules
  file, but still failed to get it to work. I expect this could be done.

  I tried a range of things to get past sqlite build errors. config.h from an external libsqlite-dev is needed because -D_HAVE_SQLITE_CONFIG_H is set so the build-dep for that is added to build deps. I don't know why the native build doesn't fall over this problem. Maybe I'm confused, but this worked for me. 
  An alternative is the part of the patch that disables sql build and package, switched with ENABLE_SQL=no. 
  It was also necessary to run configure on the lang/sql/sqlite dir otherwise it tries to do a native build there and ignores the configure setting to turn it off. I tried a number of things here and I'm not absolutely sure which combinations are needed. As it stands the SQL part of the build can be disabled, but is not disabled in stage1 as it does not seem to be necessary for a bootstrap (sqlite3 can be cross-built first). This WFM.

  DEB_BUILD_OPTIONS=nocheck is not honoured by the rules file, and is
  overwridden by cross/not cross state. This prevents a native stage1
  build as --enable test also requires --enable-tcl. Interesting
  question as to whether cross should set test state automatically, or
  if ot should be left to build tools. Better fixes may well be possible
  here.

  The clean target didn't clean the build dir or the generated
  db_signature file. So a second build never worked. Tidied that too.

  The rules files has inconsistent use of $(CURDIR) but I left that
  alone.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/db/+bug/1105368/+subscriptions