LFS_CFLAGS on 32bits architectures
andreas at canonical.com
Mon May 30 14:16:59 UTC 2022
on a pi3 (armhf):
$ getconf LFS_CFLAGS
This only returns a value where it's needed, aka, 32bits (AFAIK).
Shouldn't this be part of our default set of CFLAGS on 32bits architectures?
The reason I ask is this old samba bug ("64bits prototype not
precised")], which iterated over a few fixes:
- force-refine _LARGEFILE64_SOURCE and _FILE_OFFSET_BIGS in
libsmbclient.h (it's been like this since 2011 in the package)
- it was replaced with , which uses a `static_assert(sizeof(off_t)
>= 8` check and fails the build on 32bit without LFS
- then it was replaced again with , which uses this one liner:
`typedef int smbc_off_t_should_be_at_least_64bits_use_LFS_CFLAGS[sizeof(off_t)-7];`,
which also fails the build because it becomes a very large array on
32bits if off_t is not 64bits.
In Ubuntu builds, only the first original patch was ever used. The
other iterations happened in debian unstable and I encountered them
while starting a new merge from debian for the kinetic cycle.
So far, only adsys is failing to build:
In file included from
/usr/include/samba-4.0/libsmbclient.h:84:13: error: size of array
'smbc_off_t_should_be_at_least_64bits_use_LFS_CFLAGS' is too large
84 | typedef int
I experimented a few things, and this got it building again:
@@ -10,6 +10,10 @@ export DH_GOLANG_INSTALL_ALL := 1
# Skip integration tests when building package: they need docker images.
+# be sure to set LFS_CFLAGS if needed, required for libsmbclient on 32bits
+CGO_CFLAGS := $(shell getconf LFS_CFLAGS)
dh $@ --buildsystem=golang --with=golang,apport
I'm trying a rebuild of all reverse dependencies of libsmbclient to
see if there are any other failures, but I am wondering if this is the
current approach we want to take, or revert to our old-and-tried patch
that just defines it for all apps including libsmbclient.h?
More information about the ubuntu-devel