On 2023-08-05 21:00, adigitoleo (Leon) wrote: > Hello,
>
> I'm new to txr and was attempting a cross-compile to armv6l,
> however configure is failing with the following error:
Hi Leon,
You are in new(ish) territory there. I proactively added the
_TIME_BITS detection to the configure script several years
ago. (In December 2021).
This was a new glibc feature at the time that I found out
about, and not available in any major distro, so I wasn't
able to test it. :(
I was not aware that it's hinged together with _FILE_OFFSET_BITS.
The configure script treats them as independent knobs.
Somehow it failed to detect _FILE_OFFSET_BITS working,
but _TIME_BITS kicked in. That's for me to debug (and
to fix the script with the knowledge that they are tied
together).
> Is this test expected to pass on armv6l? Or is ARM not a supported
> architecture?
32 bit ARM is supported.
> I couldn't find a comment about supported architectures on
> the website. I'm asking because I am interested in taking on maintenance
> off the txr package for Void Linux, which supports armv5l, armv6l and
> aarch64. However, I don't personally have any experience with ARM
> architectures yet.
For now, we need a workaround.
I think you have about two choices: you have to figure out whether
you want the 32 bit ARM package to have 64 bit file offsets and time_t,
or 32. With 32 bit file offsets, the ability to use large files in
some ways is limited, which might not matter on some embedded systems
that don't have mass storage. 32 bit time_t implies that the application
has a Y2038 problem. That might matter if there is a possibility that
that package will be deployed today and not updated for a decade and half.
If you want 64 bits, it seems the problem is that _FILE_OFFSET_BITS=64
is somehow missing. A good way to add it would be via EXTRA_FLAGS:
make EXTRA_FLAGS="-D_FILE_OFFSET_BITS=64"
If you don't want 64 bit time_t or large file support, you could
try
./configure --big-time=no
that should get rid of the -D_TIME_BITS=64.
Let me know how it goes; I will be in touch about the status of the
fix for this issue. A smooth experience for downstream package
maintainers is a priority.
Unfortunately, downstream package maintainers very rarely contact
upstream; they like to slug it alone. (And it's more or less obvious
why: only that type of persistent personality could make it as
a distro maintainer; the job selects for that.)
I find out about their issues by searching through their
repositories and project pages. "Oh, they are applying a weird
patch to get it to build ... and they didn't tell me".
(text/plain)