LFS_CFLAGS on 32bits architectures

[Steve Langasek]

Hi Andreas,

On Mon, May 30, 2022 at 02:16:59PM +0000, Andreas Hasenack wrote:
> on a pi3 (armhf):

> $ getconf LFS_CFLAGS
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64

> 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?

In principle, yes.  The problem is, it is ABI-breaking to add this to the
default set of CFLAGS on an architecture after it has been bootstrapped.

There are libraries which expose either C/Linux types or their own types in
function prototypes, where those types are of different sizes depending on
the LFS defines in use.  IIRC a classic example of this is zlib.

So because i386 and armhf (and likewise all other 32-bit Debian
architectures to date) have been bootstrapped without LFS_CFLAGS exported to
dpkg-buildflags by default, we can't add it now without introducing forced
ABI changes on an indeterminate number of libraries.  Those libraries SHOULD
all be made to transition to LFS_CFLAGS, but we have to know which libraries
have their ABIs changing and plan transitions for them rather than just
flipping the switch.

If someone were able to do the necessary static analysis over the archive to
identify all of the affected libraries, then I think there's a strong case
to be made that we should do them all at once and then change the default
flags, because that would then fix the problem for any new libraries that
are introduced in the future.

FYI this issue is mentioned in the dpkg-buildflags manpage:

FEATURE AREAS
[...]
   future
       Several compile-time options (detailed below) can be used to enable
       features that should be enabled by default, but cannot due to backwards
       compatibility reasons.

       lfs This setting (disabled by default) enables Large File Support on
           32-bit architectures where their ABI does not include LFS by
           default, by adding -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 to
           CPPFLAGS.

> I experimented a few things, and this got it building again:
> --- a/debian/rules
> +++ b/debian/rules
> @@ -10,6 +10,10 @@ export DH_GOLANG_INSTALL_ALL := 1
>  # Skip integration tests when building package: they need docker images.
>  export ADSYS_SKIP_INTEGRATION_TESTS=1
> 
> +# be sure to set LFS_CFLAGS if needed, required for libsmbclient on 32bits
> +CGO_CFLAGS  := $(shell getconf LFS_CFLAGS)
> +export CGO_CFLAGS
> +
>  %:
>         dh $@ --buildsystem=golang --with=golang,apport

Would be interesting to know if 'export DEB_BUILD_MAINT_OPTIONS=future=+lfs'
also fixed the build, as conceptually that's the same level of abstraction
as fixing dpkg-buildflags per the above.

> 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?

I think that if there's a solution that doesn't require patching upstream
samba, while guarding against miscompilation of either libraries or their
consumers and avoiding accidentally introducing any ABI changes, we should
prefer that.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                   https://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20220530/06a336c0/attachment.sig>