On 7/24/2024 12:20 PM, Alexander Kanavin wrote:
On Wed, 24 Jul 2024 at 19:10, Tom Hochstein via lists.openembedded.org
<tom.hochstein=oss.nxp....@lists.openembedded.org> wrote:
-GLIBC_64BIT_TIME_FLAGS = " -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64"
+TARGET_CC_ARCH += "${GLIBC_64BIT_TIME_FLAGS}"
# Only needed for some 32-bit architectures, some relatively newer
# architectures do not need it ( e.g. riscv32 )
-TARGET_CC_ARCH:append:arm = "${GLIBC_64BIT_TIME_FLAGS}"
-TARGET_CC_ARCH:append:armeb = "${GLIBC_64BIT_TIME_FLAGS}"
-TARGET_CC_ARCH:append:mipsarcho32 = "${GLIBC_64BIT_TIME_FLAGS}"
-TARGET_CC_ARCH:append:powerpc ="${@bb.utils.contains('TUNE_FEATURES', 'm32',
'${GLIBC_64BIT_TIME_FLAGS}', '', d)}"
-TARGET_CC_ARCH:append:x86 ="${@bb.utils.contains('TUNE_FEATURES', 'm32',
'${GLIBC_64BIT_TIME_FLAGS}', '', d)}"
+GLIBC_64BIT_TIME_FLAGS = ""
+GLIBC_64BIT_TIME_FLAGS:arm = "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64"
+GLIBC_64BIT_TIME_FLAGS:armeb = "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64"
+GLIBC_64BIT_TIME_FLAGS:mipsarcho32 = "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64"
+GLIBC_64BIT_TIME_FLAGS:powerpc = \
+"${@bb.utils.contains('TUNE_FEATURES', 'm32', '-D_TIME_BITS=64
-D_FILE_OFFSET_BITS=64', '', d)}"
+GLIBC_64BIT_TIME_FLAGS:x86 = \
+"${@bb.utils.contains('TUNE_FEATURES', 'm32', '-D_TIME_BITS=64
-D_FILE_OFFSET_BITS=64', '', d)}"
Apologies, but this is not simpler or better or more readable.
Repeating "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" multiple times
should really be avoided.
What prompted this patch specifically?
Thanks, Alex.
We are working to configure the builds of certain recipes so the
non-Y2038-compliant code is avoided, e.g, by disabling oss-output in
pulseaudio. That leads to needing to restore GLIBC_64BIT_TIME_FLAGS,
which for pulseaudio is cleared in this file (on scarthgap, not on master):
GLIBC_64BIT_TIME_FLAGS:pn-pulseaudio = ""
When you do that override as one would normally expect, i.e., without
the leading space, you get the error:
cc1: error: '-Werror=format-security-D_TIME_BITS=64': no option
'-Wformat-security-D_TIME_BITS=64'
The problem is the design in time64.inc does impose an extra requirement
for an external assignment to include a leading space. The redesign is
meant to remove that requirement on the leading space, i.e., to simplify
the usage of the variable by external users.
Tom
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#202482):
https://lists.openembedded.org/g/openembedded-core/message/202482
Mute This Topic: https://lists.openembedded.org/mt/107527348/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
