On Sun, 2021-03-28 at 00:35 -0400, Denys Dmytriyenko wrote: > On Sun, Mar 28, 2021 at 04:25:02AM +0200, Lars Poeschel wrote: > > On Sat, Mar 27, 2021 at 01:54:11PM +0000, Richard Purdie wrote: > > > On Sat, 2021-03-27 at 02:41 +0100, Lars Poeschel wrote: > > > > From: Lars Poeschel <[email protected]> > > > > > > > > The functions for checking the C compiler version call the compiler with > > > > the --version argument and capture stdout and stderr to extract the > > > > version information from that. This does not work if something goes > > > > wrong for the compiler and it then prints some warning to stderr. The > > > > following regex will certainly fail in that case. > > > > It is better to just concentrate on stdout where the real version is > > > > printed to and ignore stderr. So we have a chance to get a version info > > > > even if a waring or error happened. > > > > > > > > Signed-off-by: Lars Poeschel <[email protected]> > > > > --- > > > > meta/lib/oe/utils.py | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > What kind of warning/error would a compiler generate that we should > > > ignore here? This seems a little odd... > > > > Well, to be more specific: It seems to come from the shell, that then > > invokes the compiler. Nevertheless it is stored in the output variable. > > In my case it contains: > > /nix/store/9ywr69qi622lrmx5nn88gk8jpmihy0dz-bash-4.4-p23/bin/sh: warning: > > setlocale: LC_ALL: cannot change locale (en_US.UTF-8) > > /nix/store/9ywr69qi622lrmx5nn88gk8jpmihy0dz-bash-4.4-p23/bin/bash: warning: > > setlocale: LC_ALL: cannot change locale (en_US.UTF-8) > > It is common to prefix command invocations with LC_ALL=C to avoid such issues. > For example: > > https://git.openembedded.org/openembedded-core/tree/scripts/lib/recipetool/append.py#n151 > > helptext = subprocess.check_output('LC_ALL=C %s --help' % command, > > shell=True).decode('utf-8')
We have: meta/conf/bitbake.conf:export LC_ALL = "en_US.UTF-8" so if this is showing warnings, the rest of the build isn't going to be great either. Why en_US.UTF-8? We need a utf-8 locale for python and a C utf-8 locale isn't standard. en_US is as close to standard across distros as we can get. Adding LC_ALL=C everywhere isn't the right solution, we're certainly not prefxixing every shell command execution with that. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#150022): https://lists.openembedded.org/g/openembedded-core/message/150022 Mute This Topic: https://lists.openembedded.org/mt/81644274/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
