[PATCH] tests: ignore $__CF_USER_TEXT_ENCODING in env during commandtest
This environment variable is supposedly set according to the contents of ~/.CFUserTextEncoding, and certainly on MacOS 14 (Sonoma) it shows up in the environment, causing commandtest to fail. However, the value that is shown in $__CF_USER_TEXT_ENCODING during the test 1) is not in the environment of the shell the test is run from, and 2) doesn't match the contents of ~/.CFUserTextEncoding. It is true, though, that filtering out this environment setting from the test results permits commandtest to pass on MacOS 14. Signed-off-by: Laine Stump <laine@redhat.com> --- [*] There may be a better way to suppress this environment setting (maybe something done to prevent it from ever being added to the environment in the first place?), and that would be fine too. This patch does work though. [*] Andrea's patches to force rpcgen to generate ANSI C code are also required for the test suite to pass on MacOS 14. tests/commandhelper.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/tests/commandhelper.c b/tests/commandhelper.c index 9b56feb120..08ee48a3a8 100644 --- a/tests/commandhelper.c +++ b/tests/commandhelper.c @@ -169,9 +169,12 @@ static int printEnvironment(FILE *log) for (i = 0; i < length; i++) { /* Ignore the variables used to instruct the loader into - * behaving differently, as they could throw the tests off. */ - if (!STRPREFIX(newenv[i], "LD_")) + * behaving differently, as they could throw the tests off. + * Also ignore __CF_USER_TEXT_ENCODING, which is set by MacOS. */ + if (!STRPREFIX(newenv[i], "LD_") && + !STRPREFIX(newenv[i], "__CF_USER_TEXT_ENCODING=")) { fprintf(log, "ENV:%s\n", newenv[i]); + } } return 0; -- 2.41.0
On Fri, Nov 03, 2023 at 12:00:30AM -0400, Laine Stump wrote:
This environment variable is supposedly set according to the contents of ~/.CFUserTextEncoding, and certainly on MacOS 14 (Sonoma) it shows up in the environment, causing commandtest to fail. However, the value that is shown in $__CF_USER_TEXT_ENCODING during the test 1) is not in the environment of the shell the test is run from, and 2) doesn't match the contents of ~/.CFUserTextEncoding.
It is true, though, that filtering out this environment setting from the test results permits commandtest to pass on MacOS 14.
Signed-off-by: Laine Stump <laine@redhat.com>
I guess this is being set by macOS libc runtime somewhere.
---
[*] There may be a better way to suppress this environment setting (maybe something done to prevent it from ever being added to the environment in the first place?), and that would be fine too. This patch does work though.
[*] Andrea's patches to force rpcgen to generate ANSI C code are also required for the test suite to pass on MacOS 14.
tests/commandhelper.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/tests/commandhelper.c b/tests/commandhelper.c index 9b56feb120..08ee48a3a8 100644 --- a/tests/commandhelper.c +++ b/tests/commandhelper.c @@ -169,9 +169,12 @@ static int printEnvironment(FILE *log)
for (i = 0; i < length; i++) { /* Ignore the variables used to instruct the loader into - * behaving differently, as they could throw the tests off. */ - if (!STRPREFIX(newenv[i], "LD_")) + * behaving differently, as they could throw the tests off. + * Also ignore __CF_USER_TEXT_ENCODING, which is set by MacOS. */ + if (!STRPREFIX(newenv[i], "LD_") && + !STRPREFIX(newenv[i], "__CF_USER_TEXT_ENCODING=")) { fprintf(log, "ENV:%s\n", newenv[i]); + }
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Fri, Nov 03, 2023 at 12:00:30AM -0400, Laine Stump wrote:
[*] There may be a better way to suppress this environment setting (maybe something done to prevent it from ever being added to the environment in the first place?), and that would be fine too. This patch does work though.
Yeah, I think this is pretty safe but it's kinda weird that this specific environment variable would make it through despite our filtering mechanisms in virCommand. So if some good soul with access to a macOS 14 installation (*cough cough* ;) could try to figure out why this started showing up all of a sudden, when it was not there for any previous version of macOS, that would be absolutely awesome.
+++ b/tests/commandhelper.c @@ -169,9 +169,12 @@ static int printEnvironment(FILE *log)
for (i = 0; i < length; i++) { /* Ignore the variables used to instruct the loader into - * behaving differently, as they could throw the tests off. */ - if (!STRPREFIX(newenv[i], "LD_")) + * behaving differently, as they could throw the tests off. + * Also ignore __CF_USER_TEXT_ENCODING, which is set by MacOS. */
s/MacOS/macOS/ (in the commit message too) Reviewed-by: Andrea Bolognani <abologna@redhat.com> -- Andrea Bolognani / Red Hat / Virtualization
On Fri, Nov 03, 2023 at 03:11:07AM -0700, Andrea Bolognani wrote:
On Fri, Nov 03, 2023 at 12:00:30AM -0400, Laine Stump wrote:
[*] There may be a better way to suppress this environment setting (maybe something done to prevent it from ever being added to the environment in the first place?), and that would be fine too. This patch does work though.
Yeah, I think this is pretty safe but it's kinda weird that this specific environment variable would make it through despite our filtering mechanisms in virCommand. So if some good soul with access to a macOS 14 installation (*cough cough* ;) could try to figure out why this started showing up all of a sudden, when it was not there for any previous version of macOS, that would be absolutely awesome.
Oh, and of course the same person could also look at all the various ld: warning: -undefined error is deprecated ld: warning: ignoring duplicate libraries: '-lxml2' that are printed during build O:-) -- Andrea Bolognani / Red Hat / Virtualization
On Fri, Nov 03, 2023 at 03:19:17AM -0700, Andrea Bolognani wrote:
On Fri, Nov 03, 2023 at 03:11:07AM -0700, Andrea Bolognani wrote:
On Fri, Nov 03, 2023 at 12:00:30AM -0400, Laine Stump wrote:
[*] There may be a better way to suppress this environment setting (maybe something done to prevent it from ever being added to the environment in the first place?), and that would be fine too. This patch does work though.
Yeah, I think this is pretty safe but it's kinda weird that this specific environment variable would make it through despite our filtering mechanisms in virCommand. So if some good soul with access to a macOS 14 installation (*cough cough* ;) could try to figure out why this started showing up all of a sudden, when it was not there for any previous version of macOS, that would be absolutely awesome.
Oh, and of course the same person could also look at all the various
ld: warning: -undefined error is deprecated
Meson add "-undefined,error" and macOS no longer likes that: https://github.com/mesonbuild/meson/issues/12450
ld: warning: ignoring duplicate libraries: '-lxml2'
There's a similarish warning reported against homebew https://github.com/orgs/Homebrew/discussions/4794 With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Fri, Nov 03, 2023 at 10:41:51AM +0000, Daniel P. Berrangé wrote:
On Fri, Nov 03, 2023 at 03:19:17AM -0700, Andrea Bolognani wrote:
On Fri, Nov 03, 2023 at 03:11:07AM -0700, Andrea Bolognani wrote:
On Fri, Nov 03, 2023 at 12:00:30AM -0400, Laine Stump wrote:
[*] There may be a better way to suppress this environment setting (maybe something done to prevent it from ever being added to the environment in the first place?), and that would be fine too. This patch does work though.
Yeah, I think this is pretty safe but it's kinda weird that this specific environment variable would make it through despite our filtering mechanisms in virCommand. So if some good soul with access to a macOS 14 installation (*cough cough* ;) could try to figure out why this started showing up all of a sudden, when it was not there for any previous version of macOS, that would be absolutely awesome.
Oh, and of course the same person could also look at all the various
ld: warning: -undefined error is deprecated
Meson add "-undefined,error" and macOS no longer likes that:
https://github.com/mesonbuild/meson/issues/12450
ld: warning: ignoring duplicate libraries: '-lxml2'
There's a similarish warning reported against homebew
Actually I think it is more mundane and a stupid warning: % gcc c.c -lxml2 % gcc c.c -lxml2 -lxml2 ld: warning: ignoring duplicate libraries: '-lxml2' oooooh soo many projects have the same -lXXX repeated mamy times when building, as build systems don't make it easy to merge duplicates. Warning about this is madness :-( With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Fri, Nov 03, 2023 at 10:47:11AM +0000, Daniel P. Berrangé wrote:
On Fri, Nov 03, 2023 at 10:41:51AM +0000, Daniel P. Berrangé wrote:
On Fri, Nov 03, 2023 at 03:19:17AM -0700, Andrea Bolognani wrote:
ld: warning: ignoring duplicate libraries: '-lxml2'
There's a similarish warning reported against homebew
Actually I think it is more mundane and a stupid warning:
% gcc c.c -lxml2
% gcc c.c -lxml2 -lxml2 ld: warning: ignoring duplicate libraries: '-lxml2'
oooooh soo many projects have the same -lXXX repeated mamy times when building, as build systems don't make it easy to merge duplicates. Warning about this is madness :-(
Yeah I really don't see the point, seems like it's there just to be annoying :( -- Andrea Bolognani / Red Hat / Virtualization
On Fri, Nov 03, 2023 at 04:13:12AM -0700, Andrea Bolognani wrote:
On Fri, Nov 03, 2023 at 10:47:11AM +0000, Daniel P. Berrangé wrote:
On Fri, Nov 03, 2023 at 10:41:51AM +0000, Daniel P. Berrangé wrote:
On Fri, Nov 03, 2023 at 03:19:17AM -0700, Andrea Bolognani wrote:
ld: warning: ignoring duplicate libraries: '-lxml2'
There's a similarish warning reported against homebew
Actually I think it is more mundane and a stupid warning:
% gcc c.c -lxml2
% gcc c.c -lxml2 -lxml2 ld: warning: ignoring duplicate libraries: '-lxml2'
oooooh soo many projects have the same -lXXX repeated mamy times when building, as build systems don't make it easy to merge duplicates. Warning about this is madness :-(
Yeah I really don't see the point, seems like it's there just to be annoying :(
We can turn it off with: -Wl,-no_warn_duplicate_libraries but need to probe for whether that option exists or not. https://indiestack.com/2023/10/xcode-15-duplicate-library-linker-warnings/ With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Fri, Nov 03, 2023 at 11:17:03AM +0000, Daniel P. Berrangé wrote:
On Fri, Nov 03, 2023 at 04:13:12AM -0700, Andrea Bolognani wrote:
On Fri, Nov 03, 2023 at 10:47:11AM +0000, Daniel P. Berrangé wrote:
On Fri, Nov 03, 2023 at 10:41:51AM +0000, Daniel P. Berrangé wrote:
On Fri, Nov 03, 2023 at 03:19:17AM -0700, Andrea Bolognani wrote:
ld: warning: ignoring duplicate libraries: '-lxml2'
There's a similarish warning reported against homebew
Actually I think it is more mundane and a stupid warning:
% gcc c.c -lxml2
% gcc c.c -lxml2 -lxml2 ld: warning: ignoring duplicate libraries: '-lxml2'
oooooh soo many projects have the same -lXXX repeated mamy times when building, as build systems don't make it easy to merge duplicates. Warning about this is madness :-(
Yeah I really don't see the point, seems like it's there just to be annoying :(
We can turn it off with:
-Wl,-no_warn_duplicate_libraries
but need to probe for whether that option exists or not.
https://indiestack.com/2023/10/xcode-15-duplicate-library-linker-warnings/
Laine, can you please cook up a patch for this? -- Andrea Bolognani / Red Hat / Virtualization
On 11/3/23 8:41 AM, Andrea Bolognani wrote:
On Fri, Nov 03, 2023 at 11:17:03AM +0000, Daniel P. Berrangé wrote:
On Fri, Nov 03, 2023 at 04:13:12AM -0700, Andrea Bolognani wrote:
On Fri, Nov 03, 2023 at 10:47:11AM +0000, Daniel P. Berrangé wrote:
On Fri, Nov 03, 2023 at 10:41:51AM +0000, Daniel P. Berrangé wrote:
On Fri, Nov 03, 2023 at 03:19:17AM -0700, Andrea Bolognani wrote:
ld: warning: ignoring duplicate libraries: '-lxml2'
There's a similarish warning reported against homebew
Actually I think it is more mundane and a stupid warning:
% gcc c.c -lxml2
% gcc c.c -lxml2 -lxml2 ld: warning: ignoring duplicate libraries: '-lxml2'
oooooh soo many projects have the same -lXXX repeated mamy times when building, as build systems don't make it easy to merge duplicates. Warning about this is madness :-(
Yeah I really don't see the point, seems like it's there just to be annoying :(
We can turn it off with:
-Wl,-no_warn_duplicate_libraries
but need to probe for whether that option exists or not.
https://indiestack.com/2023/10/xcode-15-duplicate-library-linker-warnings/
Laine, can you please cook up a patch for this?
Yeah, I think I see how that's done. I need to take the dog for a walk first though :-)
On 11/3/23 6:11 AM, Andrea Bolognani wrote:
On Fri, Nov 03, 2023 at 12:00:30AM -0400, Laine Stump wrote:
[*] There may be a better way to suppress this environment setting (maybe something done to prevent it from ever being added to the environment in the first place?), and that would be fine too. This patch does work though.
Yeah, I think this is pretty safe but it's kinda weird that this specific environment variable would make it through despite our filtering mechanisms in virCommand. So if some good soul with access to a macOS 14 installation (*cough cough* ;) could try to figure out why this started showing up all of a sudden, when it was not there for any previous version of macOS, that would be absolutely awesome.
Well, I have access to macos 14, but not to anything earlier. It seems pretty cut/dried that our virCommand gives the child process a very limited environment, so it Dan's supposition must be correct. Possibly it can be eliminated by setting the C locale or something?
participants (3)
-
Andrea Bolognani -
Daniel P. Berrangé -
Laine Stump