Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> While it does not /prevent/ cracks, there is something
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> I'm currently looking at adding support for this to
>
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> While it does not /prevent/ cracks, there is something we can ensure
> that
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> To avoid false positives if this test is used, we might want to add a
> rule
Bruno Haible wrote:
Richard Stallman commented on Jacob Bachmeyer's idea:
> > Another related check that /would/ have caught this attempt would be
> > comparing the aclocal m4 files in a release against their (meta)upstream
> > sources before building a package. This is something
Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
[...]
When considering any such change, we still should
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > Can anyone think of a feasible way to prevent this sort of attack?
> A
Bruno Haible writes:
> Richard Stallman commented on Jacob Bachmeyer's idea:
>> > > Another related check that /would/ have caught this attempt would be
>> > > comparing the aclocal m4 files in a release against their
>> (meta)upstream
>> > > sources before building a package. This is
Richard Stallman commented on Jacob Bachmeyer's idea:
> > > Another related check that /would/ have caught this attempt would be
> > > comparing the aclocal m4 files in a release against their
> (meta)upstream
> > > sources before building a package. This is something distribution
> >
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > Now for a bit of speculation. I speculate that a cracker was careless
> >
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> I would like to clarify that my purpose in starting this thread wasn't
> so
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > Another related check that /would/ have caught this attempt would be
> >
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> However, the question remains unanswered why it needs 3 different
>
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> My first thought was that Autoconf is a relatively trivial attack
Eric Blake wrote:
[adding in coreutils, for some history]
[...]
At any rate, it is now obvious (in hindsight) that zstd has a much
larger development team than xz, which may alter the ability of zstd
being backdoored in the same way that xz was, merely by social
engineering of a lone
Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> My first thought was that Autoconf is a relatively
Bruno Haible wrote:
Jacob Bachmeyer wrote:
Another related check that /would/ have caught this attempt would be
comparing the aclocal m4 files in a release against their (meta)upstream
sources before building a package. This is something distribution
maintainers could do without
Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> The issue seems to be releases containing binary data
Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> What would be helpful is if `make dist' would
On Tue, Apr 2, 2024 at 6:05 PM Karl Berry wrote:
>
> I'm also wondering whether the GNU system should recommend using zstd
> instead of or in addition to xz for compression purposes.
>
> I'm not sure GNU explicitly recommends anything. Although the tarball
> examples in standards.texi and
On 4/2/24 16:42, Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> My first thought was that Autoconf
I'm also wondering whether the GNU system should recommend using zstd
instead of or in addition to xz for compression purposes.
I'm not sure GNU explicitly recommends anything. Although the tarball
examples in standards.texi and maintain.texi all use gz, I don't think
even gz is
I'm also wondering whether the GNU system should recommend using zstd
instead of or in addition to xz for compression purposes. Automake
gained support for dist-zstd back in 2019 [1], but I'm not sure how
many projects are using it yet.
[1]
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> The issue seems to be releases containing binary data for unit tests,
>
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> My first thought was that Autoconf is a relatively trivial attack vector
>
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> There is not much one can do when a maintainer with signing/release
> power
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> There is not much one can do when a maintainer with signing/release
> power
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> What would be helpful is if `make dist' would guarantee to produce the same
>
[adding in coreutils, for some history]
On Sat, Mar 30, 2024 at 12:55:35PM -0400, Eric Gallager wrote:
> I was recently reading about the backdoor announced in xz-utils the
> other day, and one of the things that caught my attention was how
> (ab)use of the GNU build system played a role in
Jacob Bachmeyer wrote:
> Another related check that /would/ have caught this attempt would be
> comparing the aclocal m4 files in a release against their (meta)upstream
> sources before building a package. This is something distribution
> maintainers could do without cooperation from upstream.
> Jose E. Marchesi wrote:
>>> Jose E. Marchesi wrote:
>>>
> [...]
>
>> I agree that distcheck is good but not a cure all. Any static
>> system can be attacked when there is motive, and unit tests are
>> easily gamed.
>>
> The issue
Eric Gallager wrote:
On Tue, Apr 2, 2024 at 12:04 AM Jacob Bachmeyer wrote:
Russ Allbery wrote:
[...] I think one useful principle that's
emerged that doesn't disrupt the world *too* much is that the release
tarball should differ from the Git tag only in the form of added files.
Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> `distcheck` target's prominence to recommend it in
Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> I was recently reading about the backdoor announced in
On Tue, Apr 2, 2024 at 12:04 AM Jacob Bachmeyer wrote:
>
> Russ Allbery wrote:
> > [...]
> >
> > There is extensive ongoing discussion of this on debian-devel. There's no
> > real consensus in that discussion, but I think one useful principle that's
> > emerged that doesn't disrupt the world
Jacob Bachmeyer writes:
> The m4 files were not checked into the repository, instead being added
> (presumably by running autogen.sh with a rigged local m4 file
> collection) while preparing the release.
Ah, yes, I think you are correct. For some reason I thought the
legitimate
Zack Weinberg wrote:
On Mon, Apr 1, 2024, at 2:04 PM, Russ Allbery wrote:
"Zack Weinberg" writes:
It might indeed be worth thinking about ways to minimize the
difference between the tarball "make dist" produces and the tarball
"git archive" produces, starting from the same clean git
Russ Allbery wrote:
[...]
There is extensive ongoing discussion of this on debian-devel. There's no
real consensus in that discussion, but I think one useful principle that's
emerged that doesn't disrupt the world *too* much is that the release
tarball should differ from the Git tag only in
Zack Weinberg wrote:
[...] but I do think there's a valid point here: the malicious xz
maintainer *might* have been caught earlier if they had committed the
build-to-host.m4 modification to xz's VCS.
That would require someone to notice that xz.git has a build-to-host.m4
that does not exist
Bruno Haible wrote:
Jacob Bachmeyer wrote:
Essentially, this would be an automated release building service: upon
request, make a Git checkout, run autogen.sh or equivalent, make dist,
and publish or hash the result. The problem is that an attacker who
manages to gain commit access to a
Bruno Haible wrote:
Jacob Bachmeyer wrote:
some of the blame for this needs to fall on the
systemd maintainers and their "katamari" architecture. There is no good
reason for notifications of daemon startup to pull in liblzma, but using
libsystemd for that purpose does exactly that, and
Jose E. Marchesi wrote:
Jose E. Marchesi wrote:
[...]
I agree that distcheck is good but not a cure all. Any static
system can be attacked when there is motive, and unit tests are
easily gamed.
The issue seems to be releases containing binary data for
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> I was recently reading about the backdoor announced in xz-utils the
> other
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> `distcheck` target's prominence to recommend it in the "Standard
>
Eric Gallager wrote:
> What about a 3rd one of these prefixes: "novcs", to teach automake
> about which files belong in VCS or not? i.e. then you might have a
> variable name like:
> dist_novcs_DATA = foo bar baz
> ...which would indicate that foo, bar, and baz are data files that
> ought to be
On Mon, Apr 1, 2024 at 2:26 PM Zack Weinberg wrote:
>
> On Mon, Apr 1, 2024, at 2:04 PM, Russ Allbery wrote:
> > "Zack Weinberg" writes:
> >> It might indeed be worth thinking about ways to minimize the
> >> difference between the tarball "make dist" produces and the tarball
> >> "git archive"
On Sun, Mar 31, 2024 at 6:19 PM Peter Johansson wrote:
>
>
> On 1/4/24 06:00, Eric Gallager wrote:
>
> So, `aclocal` has a flag to control this behavior: specifically, its
> `--install` flag. Right now I don't see `aclocal` mentioned in the GNU
> Coding Standards at all. Should they be updated to
On Mon, Apr 1, 2024, at 2:04 PM, Russ Allbery wrote:
> "Zack Weinberg" writes:
>> It might indeed be worth thinking about ways to minimize the
>> difference between the tarball "make dist" produces and the tarball
>> "git archive" produces, starting from the same clean git checkout,
>> and also
"Zack Weinberg" writes:
> I have been thinking about this incident and this thread all weekend and
> have seen a lot of people saying things like "this is more proof that
> tarballs are a thing of the past and everyone should just build straight
> from git". There are a bunch of reasons why one
On Sun, Mar 31, 2024, at 3:17 AM, Jacob Bachmeyer wrote:
> Eric Gallager wrote:
>> Specifically, what caught my attention was how the release tarball
>> containing the backdoor didn't match the history of the project in its
>> git repository. That made me think about automake's `distcheck`
>>
* Such an automated release building service is a piece of SaaSS.
CI is not SaaSS, how is it different?
I can
hardly imagine how we at GNU tell people "SaaSS is as bad as, or worse
than, proprietary software" and at the same time advocate the use of
such a service.
I am not arguing for the building service, but:
On 2024-04-01 14:40:20 +0200, Bruno Haible wrote:
> * Such an automated release building service is a piece of SaaSS. I can
> hardly imagine how we at GNU tell people "SaaSS is as bad as, or worse
> than, proprietary software" and at the same
Jacob Bachmeyer wrote:
> >> Essentially, this would be an automated release building service: upon
> >> request, make a Git checkout, run autogen.sh or equivalent, make dist,
> >> and publish or hash the result. The problem is that an attacker who
> >> manages to gain commit access to a
Jacob Bachmeyer wrote:
> some of the blame for this needs to fall on the
> systemd maintainers and their "katamari" architecture. There is no good
> reason for notifications of daemon startup to pull in liblzma, but using
> libsystemd for that purpose does exactly that, and ended up getting
>
> Jose E. Marchesi wrote:
>>> [...]
>>>
I agree that distcheck is good but not a cure all. Any static
system can be attacked when there is motive, and unit tests are
easily gamed.
>>> The issue seems to be releases containing binary data for unit tests,
>>>
Tomas Volf wrote:
On 2024-03-31 14:50:47 -0400, Eric Gallager wrote:
With a reproducible build system, multiple maintainers can "make dist"
and compare the output to cross-check for erroneous / malicious dist
environments. Multiple signatures should be harder to compromise,
assuming each is
Eric Gallager wrote:
On Sun, Mar 31, 2024 at 3:20 AM Jacob Bachmeyer wrote:
dherr...@tentpost.com wrote:
[...]
The issue seems to be releases containing binary data for unit tests,
instead of source or scripts to generate that data. In this case, that
binary data was used to smuggle
Jose E. Marchesi wrote:
[...]
I agree that distcheck is good but not a cure all. Any static
system can be attacked when there is motive, and unit tests are
easily gamed.
The issue seems to be releases containing binary data for unit tests,
instead of source or scripts to generate
On 1/4/24 06:00, Eric Gallager wrote:
So, `aclocal` has a flag to control this behavior: specifically, its
`--install` flag. Right now I don't see `aclocal` mentioned in the GNU
Coding Standards at all. Should they be updated to include a
recommendation as to whether it's better to put
On 2024-03-31 14:50:47 -0400, Eric Gallager wrote:
> > > With a reproducible build system, multiple maintainers can "make dist"
> > > and compare the output to cross-check for erroneous / malicious dist
> > > environments. Multiple signatures should be harder to compromise,
> > > assuming each
On Sun, Mar 31, 2024 at 3:54 PM Russ Allbery wrote:
>
> Eric Gallager writes:
>
> > Well, other people besides the maintainers can also run `make dist` and
> > `make distcheck`. My idea was to get end-users in the habit of running
> > `make distcheck` themselves before installing stuff. And if
Eric Gallager writes:
> Well, other people besides the maintainers can also run `make dist` and
> `make distcheck`. My idea was to get end-users in the habit of running
> `make distcheck` themselves before installing stuff. And if that's too
> much to ask of end users, I'd also point out that
On Sun, Mar 31, 2024 at 3:20 AM Jacob Bachmeyer wrote:
>
> dherr...@tentpost.com wrote:
> > On 2024-03-30 18:25, Bruno Haible wrote:
> >> Eric Gallager wrote:
> >>>
> >>> Hm, so should automake's `distcheck` target be updated to perform
> >>> these checks as well, then?
> >>
> >> The first
> [...]
>> I agree that distcheck is good but not a cure all. Any static
>> system can be attacked when there is motive, and unit tests are
>> easily gamed.
>
> The issue seems to be releases containing binary data for unit tests,
> instead of source or scripts to generate that data. In this
Bluntly, I don't think it would help with security. The attacker would
just have to disable or adjust the distcheck target to seemingly pass.
Yeah, it should be noted that the way the backdoor got into the code
was by the _co-maintainer_ -- distcheck or not, would not have
mattered,
> It is not yet clear if the
> maintainer intentionally did this, or if the changes were introduced via
> a compromise of his computer.
I think it is pretty clear by now. [1][2][3]
There is a bit more to it all than just this -- the maintainer wasn't
responsible (Lasse Collin), the
I think it is pretty clear by now. [1][2][3]
[1] https://boehs.org/node/everything-i-know-about-the-xz-backdoor
[2] https://news.ycombinator.com/item?id=39865810
[3] https://www.youtube.com/watch?v=Kw8MCN5uJPg
There is not much one can do when a maintainer with signing/release
power does
Bob Friesenhahn wrote:
> It is not yet clear if the
> maintainer intentionally did this, or if the changes were introduced via
> a compromise of his computer.
I think it is pretty clear by now. [1][2][3]
[1] https://boehs.org/node/everything-i-know-about-the-xz-backdoor
[2]
On 3/30/24 19:00, Alexandre Oliva wrote:
Bluntly, I don't think it would help with security. The attacker would
just have to disable or adjust the distcheck target to seemingly pass.
Relying on something in a code repository to tell whether the repository
is secure is akin to tying a dog with
dherr...@tentpost.com wrote:
On 2024-03-30 18:25, Bruno Haible wrote:
Eric Gallager wrote:
Hm, so should automake's `distcheck` target be updated to perform
these checks as well, then?
The first mentioned check can not be automated. ...
The second mentioned check could be done by the
Eric Gallager wrote:
Specifically, what caught my attention was how the release tarball
containing the backdoor didn't match the history of the project in its
git repository. That made me think about automake's `distcheck`
target, whose entire purpose is to make it easier to verify that a
On Mar 30, 2024, Eric Gallager wrote:
> automake's `distcheck` target, whose entire purpose is to make it
> easier to verify that a distribution tarball can be rebuilt from
> itself and contains all the things it ought to contain.
> Recommending the `distcheck` target to a wider variety of
On 2024-03-30 18:25, Bruno Haible wrote:
Eric Gallager wrote:
Hm, so should automake's `distcheck` target be updated to perform
these checks as well, then?
The first mentioned check can not be automated. ...
The second mentioned check could be done by the maintainer, ...
I agree that
Eric Gallager wrote:
> > * In order to detect that a tarball contains too many files, that is,
> > some files that the release manager did not intend to include,
> > the best way is to compare the file list of the current tarball
> > with the previous version:
> > $ diff -r -q
On Sat, Mar 30, 2024 at 5:41 PM Bruno Haible wrote:
>
> Eric Gallager wrote:
> > Recommending the `distcheck` target to a wider variety of users would
> > help more projects catch mismatches between things a distribution
> > tarball is supposed to contain, and things that it isn't.
>
> While
Eric Gallager wrote:
> Recommending the `distcheck` target to a wider variety of users would
> help more projects catch mismatches between things a distribution
> tarball is supposed to contain, and things that it isn't.
While 'make distcheck' detects some of these mismatches, it does not
detect
`distcheck` target's prominence to recommend it in the "Standard
Targets for All Users" section of the GCS?
Replying as an Automake developer, I have nothing against it in
principle, but it's clearly up to the GNU coding standards
maintainers. As far as I know, that's still rms (for
I was recently reading about the backdoor announced in xz-utils the
other day, and one of the things that caught my attention was how
(ab)use of the GNU build system played a role in allowing the backdoor
to go unnoticed: https://openwall.com/lists/oss-security/2024/03/29/4
Specifically, what
already solved → documentation is your friend, this issue with "-module" is
already known.
Hi,
I'm having a problem to use a makefile *variable* to minimize the configuration
replication.
The problem is *noversion_LDFLAGS* which has all flags for *_LDFLAGS *but*
seems *not* be accepted
as valid input in the *Makefile.am* file.
my project :
> pkglib_LTLIBRARIES = pymqmsgque.la
>
The output I got from this and dist-no-built-sources.log is rather
interesting. As it looks, the test is indeed broken from the beginning.
Thank you very much, Jens. We'll deal with this asap. Your original
analysis that we simply don't recognize the right option name is looking
correct
Hi,
I just realized the last part might be confusing.
What I meant by "looks identical" is only the output of the *second*
grep (see linked script), not the whole file:
BUILT_SOURCES = x.c
all: $(BUILT_SOURCES)
distdir: $(BUILT_SOURCES)
check: $(BUILT_SOURCES)
install:
Hi Karl,
> Can you please send an example tree that shows the failure?
I modified the existing testscript slightly so I can get a view into
both configure.ac and Makefile files.
https://gist.github.com/Jens-G/dc9e3fc89d10d1dcf27f289c7e8d5fc8
The output I got from this and
Hi Jens - thanks for the report.
Nevertheless I think there is something wrong here.
Quite likely. Can you please send an example tree that shows the failure?
'DIST_BUILT_SOURCES' => !! option 'dist-built-sources',
Hmm. I had a vague impression that the "no-" was automatically
Hi,
I have seen https://debbugs.gnu.org/49317 and the two commits 13659a7
and especially 314c55f. I also recognized there is a test case to test
for the correct behaviour.
Nevertheless I think there is something wrong here. I tried to make it
work yesterday via AUTOMAKE_OPTIONS (tried both
Hello,
I am trying to write rules in order to build a program with ghc
I end up with this, I think that I could improve all this a lot.
So I would like your advices in order to improve this
thanks for considering
Frederic
GHCLINK = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
Hi Bob,
It is my opinion that if a library or program
is linked with C++ libraries (and especially if it is a static build!)
that it should be linked using the C++ linker. Likewise, if a library
or program does not depend on, or contain any C++ code, it should be
Hi Bob,
It is my opinion that if a library or program
is linked with C++ libraries (and especially if it is a static build!)
that it should be linked using the C++ linker. Likewise, if a library
or program does not depend on, or contain any C++ code, it should be
linked
GraphicsMagick (which is primarily C code) supports optional linkage
with some C++ libraries. It is my opinion that if a library or program
is linked with C++ libraries (and especially if it is a static build!)
that it should be linked using the C++ linker. Likewise, if a library
or program
GraphicsMagick (which is primarily C code) supports optional linkage
with some C++ libraries. It is my opinion that if a library or program
is linked with C++ libraries (and especially if it is a static build!)
that it should be linked using the C++ linker. Likewise, if a library
or program
Bruno Haible , 2024-02-20 12:44:
Bogdan wrote:
Right. And, as I suspected, nothing in any LIBS, LD*, no libobjc found.
Does it work if you put
AC_LANG([Objective C])
somewhere between the lines
cat >> configure.ac << 'END'
and the first
END
following it (i.e., in
Bogdan wrote:
> # Ensure install-strip works when STRIP consists of more than one word.
> # This test needs GNU binutils strip. See sister test 'strip3.sh'.
>
>
> And, frankly, I don't know what to do about this. It's the whole
> point of the test to use 'strip --verbose' (well, 'strip' + any
Bogdan wrote:
> Right. And, as I suspected, nothing in any LIBS, LD*, no libobjc found.
> Does it work if you put
>
> AC_LANG([Objective C])
>
> somewhere between the lines
>
> cat >> configure.ac << 'END'
>
> and the first
>
> END
>
> following it (i.e., in the
Bruno Haible , 2024-02-19 01:44:
Hello Bogdan,
Can you tell us what actually "c++" is on your system? Like e.g. run
"c++ --version" or "c++ --help"?
$ c++ --version
OpenBSD clang version 13.0.0
Target: amd64-unknown-openbsd7.4
Thread model: posix
InstalledDir: /usr/bin
On my system,
Bruno Haible , 2024-02-19 01:33:
Hello Bogdan,
Thank you for dealing with the Automake support.
Thank you for testing :)
2) t/strip2 - could you check if you have the STRIPPROG environment
variable set and, if yes, unset it (or, at least, remove the
"--verbose" parameter from it) prior
Hello Bogdan,
> Can you tell us what actually "c++" is on your system? Like e.g. run
> "c++ --version" or "c++ --help"?
$ c++ --version
OpenBSD clang version 13.0.0
Target: amd64-unknown-openbsd7.4
Thread model: posix
InstalledDir: /usr/bin
> On my system, Autoconf finds "g++", tests it for
Hello Bogdan,
Thank you for dealing with the Automake support.
> 2) t/strip2 - could you check if you have the STRIPPROG environment
> variable set and, if yes, unset it (or, at least, remove the
> "--verbose" parameter from it) prior to running the test?
I did not have the STRIPPROG
Hello, Bruno.
Thank you for your testing.
About your defect:
1) t/objcxx-* - may need our attention,
2) t/strip2 - could you check if you have the STRIPPROG environment
variable set and, if yes, unset it (or, at least, remove the
"--verbose" parameter from it) prior to running the test?
3)
Hello, Bruno.
Thank you for your testing.
About your defect:
1) t/objcxx-* - may need our attention,
2) t/strip2 - could you check if you have the STRIPPROG environment
variable set and, if yes, unset it (or, at least, remove the
"--verbose" parameter from it) prior to running the test?
3)
Hi,
I tested automake-1.16 with the automake-openindiana-fix-mail.diff (minor
tweaks were needed because the patch refused to apply) and all four tests
failed as before. That's not surprising because the patch is effectively no-op
on illumos because __sun is defined and __EXTERN_C__ is not
201 - 300 of 28113 matches
Mail list logo