11 p.m.
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(a)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
3:56 a.m.
New subject: [PATCH] tests: ignore $__CF_USER_TEXT_ENCODING in env during
commandtest
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(a)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(a)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 :|
5:11 a.m.
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(a)redhat.com>
--
Andrea Bolognani / Red Hat / Virtualization
5:19 a.m.
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
5:41 a.m.
New subject: [PATCH] tests: ignore $__CF_USER_TEXT_ENCODING in env during
commandtest
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 :|
5:47 a.m.
New subject: [PATCH] tests: ignore $__CF_USER_TEXT_ENCODING in env during
commandtest
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
https://github.com/orgs/Homebrew/discussions/4794
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 :|
6:13 a.m.
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
>
> https://github.com/orgs/Homebrew/discussions/4794
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
6:17 a.m.
New subject: [PATCH] tests: ignore $__CF_USER_TEXT_ENCODING in env during
commandtest
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
> >
> > https://github.com/orgs/Homebrew/discussions/4794
>
> 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 :|
7:41 a.m.
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
> > >
> > > https://github.com/orgs/Homebrew/discussions/4794
> >
> > 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
9:55 a.m.
New subject: [PATCH] tests: ignore $__CF_USER_TEXT_ENCODING in env during
commandtest
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
>>>>
>>>> https://github.com/orgs/Homebrew/discussions/4794
>>>
>>> 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 :-)
9:39 a.m.
New subject: [PATCH] tests: ignore $__CF_USER_TEXT_ENCODING in env during
commandtest
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?
385
days inactive
385
days old
10 comments
3 participants
participants (3)
-
Andrea Bolognani -
Daniel P. Berrangé -
Laine Stump