On 24/07/2024 22:29:45+0200, Alexander Kanavin wrote: > On Wed, 24 Jul 2024 at 21:33, Tom Hochstein <[email protected]> wrote: > > > 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. > > Thanks for the background. I guess the only real objection I have is > about repeating the flags multiple times. They should be defined once, > so we probably need an extra intermediate variable that would be set > with target overrides.
Then why not simply have this intermediate variable contain the initial GLIBC_64BIT_TIME_FLAGS value with the leading space so recipe can simply use it to restore the value? -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#202487): https://lists.openembedded.org/g/openembedded-core/message/202487 Mute This Topic: https://lists.openembedded.org/mt/107527348/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
