Hi!
Do you have any idea why the test "Bug598" fails? You seem to have
looked into it already.
- Olaf
On 08/31/2017 18:28, "Simon Schröder" wrote:
> Hi Olaf,
>
> Thanks! I did not really think about ag++ because the tests do not use it.
> However, ag++ -std=XXX should be sufficient for users (User-friendliness was
> the main reason why I found the ac++ "std" argument useful).
>
> Furthermore, thank you for fixing the ExecAdviceNewDelete test.
>
> This makes Bug598 the last failing test on Debian 9 and I am not sure whether
> the test will be fixed quickly. As a workaround puma.config can be generated
> using "ag++ -std=gnu++98 --gen_config".
>
> Reinhard, all in all, it should be sufficient for you to use the current trunk
> version and to add "-std=gnu++98" as ag++ command line argument when
> generating puma.config ("ag++ -std=gnu++98 --gen_config").
>
> Best regards,
>
> Simon
>
>
>> Hi Simon,
>>
>> I already suspected that I should think longer about this. ;-)
>>
>> I agree that the interface of ac++ for configuring the language standard
>> is not very convenient. However, it avoids redundancy. The __cplusplus
>> macro would have to be defined in puma.config anyway. Defining the
>> remaining parts of puma.config manually is either not convenient.
>>
>> If you use ag++, everything should work smoothly at the moment:
>> Depending on the gcc version and its default language standard, the
>> __cplusplus macro is defined in puma.config. If the project's source
>> code is written for some other standard, ag++ would be called with
>> -std=c++<year> and the __cplusplus macro would be generated accordingly.
>>
>> If we had a -std option in ac++, ag++ would have to be changed as well.
>>
>> In summary: I might be missing something, but still don't see the point
>> in that new option.
>>
>> - Olaf
>>
>>
>> On 08/31/2017 15:32, "Simon Schröder" wrote:
>>> Hi Olaf,
>>>
>>> Thank you for your opinion! I think my previous email was not clear enough.
>>> My
>>> suggestion was/is to have a *default* language standard that is independent
>>> of
>>> the operating system's default compiler. The language standard can still be
>>> changed to C++11, C++14, or C++17. Currently this change is possible by
>>> providing -D "__cplusplus=XXXXXXL" as a command line argument or through
>>> puma.config. What I do not like about this is that it is not documented (as
>>> far as I know) and that it is not as intuitive as a "std=..." command line
>>> argument. That is why I suggested adding that command line argument.
>>>
>>> Test Bug574 is fixed in current trunk version.
>>>
>>> Best regards,
>>>
>>> Simon
>>>
>>>
>>>
>>>> Hi!
>>>>
>>>> No. Please don't commit the fixes. I have implemented C++14 support in
>>>> ag++ and ac++ for good reasons. If ac++ is configured to internally use
>>>> the C++98 standard (always), it will not be able to handle programs that
>>>> make use of C++11/14/17 extensions. For instance, we wouldn't be able to
>>>> compile Qt 5.x applications anymore!
>>>>
>>>> If a test only works with a specific language standard, we can configure
>>>> that in its Makefile, e.g.:
>>>>
>>>> ACFLAGS ?= -D "__cplusplus=201103L"
>>>> CXXFLAGS ?= -std=c++11
>>>> include ../Makefile.generic
>>>>
>>>> However, normally the tests should work with C++98 *and* C++14, i.e.
>>>> older gccs und gcc >= 6. For the ExecAdviceNewDelete we should implement
>>>> different handling for the two cases in the weaver. However, first we
>>>> have to verify that the signature really changed. That would be quite
>>>> strange.
>>>>
>>>> tests/Bug574 should of course be fixed.
>>>>
>>>> Cheers,
>>>>
>>>> Olaf
>>>>
>>>> On 08/31/2017 14:23, "Simon Schröder" wrote:
>>>>> Hi Reinhard,
>>>>>
>>>>> I am able to reproduce the failing tests. The source of the problems is
>>>>> that
>>>>> starting with gcc-6.0 the default language standard is gnu++14 (instead of
>>>>> gnu++98) (see [1]). When using an operating system that has gcc >= 6.0 as
>>>>> system compiler (e.g. debian 9), this leads to two problems:
>>>>>
>>>>> 1) Because Ag++ uses the system compiler without specifying a language
>>>>> standard to generate puma.config, puma.config contains the line
>>>>> -D "__cplusplus=201402L" (C++14) instead of -D "__cplusplus=199711L"
>>>>> (C++98).
>>>>> This line causes AspectC++ to set the standard language of the internal
>>>>> Clang
>>>>> compiler instance to C++14 (-std=c++14). In c++14 mode Clang behaves
>>>>> different
>>>>> which leads to a different AspectC++ repo and to different woven code. In
>>>>> case
>>>>> of Bug598 "different" means wrong (see [2]). In case of
>>>>> ExecAdviceNewDelete
>>>>> "different" means that C++11 code is generated (which cannot be compiled
>>>>> using
>>>>> g++ in non-C++11 mode).
>>>>>
>>>>> 2) When executing the tests, the woven code is compiled using the system
>>>>> compiler without specifying a language standard. Due to this, g++ with
>>>>> implicit -std=gnu++14 is used to compile the woven code. This makes
>>>>> ExecAdviceNewDelete fail, because g++ does not like "void *operator new
>>>>> (size_t ) throw(std::bad_alloc);" in gnu++14 mode (probably because
>>>>> "throw(std::bad_alloc)" is deprecated in C++11). On the other hand,
>>>>> clang++ in
>>>>> gnu++14 mode does not complain, so this might be a g++ issue.
>>>>>
>>>>> To fix 1), AspectC++ should use gnu++98 as default (as on operating
>>>>> systems
>>>>> with gcc < 6.0). To accomplish this, either ag++ has to explicitly set
>>>>> gnu++98
>>>>> while generating puma.config or AspectC++ has to ignore -D
>>>>> "__cplusplus=XXXX"
>>>>> and provide an own mechanism to set the language standard that should be
>>>>> used
>>>>> for parsing and code generation. I would recommend the latter and would
>>>>> add a
>>>>> new command line argument "--std" to AspectC++ whose default value is
>>>>> "gnu++98" and which could look like the following:
>>>>> ...
>>>>> -c|--compile <arg> Name of the input file
>>>>> -o|--output <arg> Name of the output file
>>>>> --std <arg> Language standard used for parsing and
>>>>> code generation
>>>>> -i|--include_files Generate manipulated header files
>>>>> ...
>>>>>
>>>>> To fix 2), the woven test code should be compiled using gnu++98
>>>>> regardless of
>>>>> the system compiler's default language standard, because the tests were
>>>>> written on the supposition that gnu++98 is used. Of course tests can
>>>>> explicitly change the language standard if they rely on C++11 or C++14
>>>>> (e.g. using "--std c++11").
>>>>>
>>>>> Test Bug574 is "just" indeterminate behavior because the value of an
>>>>> uninitialized member is used in an if-clause.
>>>>>
>>>>> I already created commits for my recommended fixed and if no one has
>>>>> objections, I would push them. What do you think? Olaf, what is your
>>>>> opinion?
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Simon
>>>>>
>>>>>
>>>>> [1] https://gcc.gnu.org/gcc-6/changes.html
>>>>> [2]
>>>>> template <typename TResult, typename TEntity>
>>>>> __attribute__((always_inline)) inline TResult __Get__Z4mainv_1_0
>>>>> (TEntity &ent,
>>>>> AC::RT<TResult>){
>>>>> typedef TJP__Z4mainv_1_0< const TResult, void, void, const char [2],
>>>>> AC::DILE, AC::TLE >
>>>>> __TJP;
>>>>> const TResult __result_buffer;
>>>>> AC::invoke_Bar_Bar__a0_before<__TJP> ();
>>>>> __result_buffer = ::arr;
>>>>> return (const TResult &)__result_buffer;
>>>>> }
>>>>> int main() {
>>>>> char x = __Get__Z4mainv_1_0< > (arr[1], __AC_TYPEOF((arr[1])) );
>>>>> return 0;
>>>>> }
>>>>>
>>>>> instead of
>>>>>
>>>>> template <typename TResult, typename TEntity, unsigned int TDim0,
>>>>> typename TIdx0>
>>>>> __attribute__((always_inline)) inline TResult __Get__Z4mainv_1_0
>>>>> (TEntity (&base)[TDim0],
>>>>> TIdx0
>>>>> idx0, AC::RT<TResult>){
>>>>> typedef TJP__Z4mainv_1_0< TResult, void, void, char, AC::DIL< 2, int,
>>>>> AC::DILE >, AC::TLE
>>>>>>
>>>>> __TJP;
>>>>> TResult __result_buffer;
>>>>> AC::invoke_Bar_Bar__a0_before<__TJP> ();
>>>>> __result_buffer = ::arr[idx0];
>>>>> return (TResult &)__result_buffer;
>>>>> }
>>>>> int main() {
>>>>> char x = __Get__Z4mainv_1_0< > (arr, (1), __AC_TYPEOF((arr[1])) );
>>>>> return 0;
>>>>> }
>>>>>
>>>>>
>>>>>> I've uploaded a new package that simply ignores failures from tests. Not
>>>>>> exactly an ideal
>>>>>> situation because it renders the test ineffective.
>>>>>>
>>>>>> From what I understand I could instead dialer disable these the tests
>>>>>> instead. But before
>>>>>> doing
>>>>>> that, I wanted to check with you if these failures also occurred on your
>>>>>> akut Test
>>>>>> infrastructure.
>>>>>> If yes, how do you deal with them, maybe you could disable the test in
>>>>>> svn. If they do not
>>>>>> appear
>>>>>> in akut, I wonder why.
>>>>>>
>>>>>> I agree that it's not super critical or urgent to me, but I think you
>>>>>> are in a much per
>>>>>> position
>>>>>> to assess the criticality and urgency.
>>>>>>
>>>>>> Thanks
>>>>>> Reinhard
>>>>>>
>>>>>> On August 29, 2017 12:19:21 PM EDT, Olaf Spinczyk
>>>>>> <olaf.spinc...@tu-dortmund.de> wrote:
>>>>>>> Hi Reinhard!
>>>>>>>
>>>>>>> We should definitely look into these three problems within the next few
>>>>>>> weeks, but I don't regard them as very critical, because they affect
>>>>>>> only special use cases: Advice for user-defined "operator new"
>>>>>>> implementations and the code generation for get/set advice, which is a
>>>>>>> feature that is only enabled with --data_joinpoints and still a bit
>>>>>>> experimental.
>>>>>>>
>>>>>>> How to proceed? Can we/you live with these problems for now and update
>>>>>>> later or is there no update option and we have to fix it sooner?
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Olaf
>>>>>>>
>>>>>>> On 08/24/2017 00:16, Reinhard Tartler wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 08/23/2017 12:07 PM, Olaf Spinczyk wrote:
>>>>>>>>> Hi!
>>>>>>>>>
>>>>>>>>> You can generate the config file easily with ag++ --gen_config.
>>>>>>> Sorry
>>>>>>>>> for the inconvenience. The background is that when I wrote the first
>>>>>>>>> ac++ tests, I did not want the makefile to depend on ag++.
>>>>>>>>>
>>>>>>>>> We should change that sooner or later, because it is obviously
>>>>>>> confusing.
>>>>>>>>
>>>>>>>> Not a problem.
>>>>>>>>
>>>>>>>> Progress! With a "correct" PUMA CONFIG, I now get further, but there
>>>>>>> seem to be
>>>>>>>> genuine test failures. Are they concerning or shall I ignore them for
>>>>>>> the debian
>>>>>>>> package?
>>>>>>>>
>>>>>>>> They look like this:
>>>>>>>>
>>>>>>>> /usr/bin/make -C tests -s all
>>>>>>>> make[2]: Entering directory
>>>>>>>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++/tests'
>>>>>>>>
>>>>>>> ...........................................[C:ExecAdviceNewDelete].................................................................................[D:Bug574].......[C:Bug598]........
>>>>>>>>
>>>>>>>>
>>>>>>>> +---------+
>>>>>>>> |ERRORS: |
>>>>>>>> +---------+
>>>>>>>>
>>>>>>>>
>>>>>>> -----------------------------------------------------------------------------
>>>>>>>> TEST: ExecAdviceNewDelete
>>>>>>>>
>>>>>>> -----------------------------------------------------------------------------
>>>>>>>> STDOUT:
>>>>>>>> --------
>>>>>>>> make[3]: Entering directory
>>>>>>>>
>>>>>>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++/tests/ExecAdviceNewDelete'
>>>>>>>> Weaving main.cc
>>>>>>>> * Running ac++ 2.2
>>>>>>>> * Handling Translation Unit `main.cc'.
>>>>>>>> - Path "main.cc"
>>>>>>>> - Parsing ...
>>>>>>>> - Weaving Aspects Forward Declarations ...
>>>>>>>> - Inserting namespace AC
>>>>>>>> - Committing
>>>>>>>> - Preparing introductions ...
>>>>>>>> - Parsing again ...
>>>>>>>> - Weaving access control bypass classes ...
>>>>>>>> - Weaving Join Points ...
>>>>>>>> Advicecode manipulation
>>>>>>>> Collecting Advice
>>>>>>>> Setting up thisJoinPoint for aspectof
>>>>>>>> Create pointcut expression tree
>>>>>>>> Matching joinpoints
>>>>>>>> Aspect ordering ...
>>>>>>>> Creating project repository 'repo.acp'
>>>>>>>> Type Check Functions
>>>>>>>> Access Join Points
>>>>>>>> Execution Join Points
>>>>>>>> void *operator new(unsigned long int)
>>>>>>>> void *operator new[](unsigned long int)
>>>>>>>> void operator delete(void *)
>>>>>>>> void operator delete[](void *)
>>>>>>>> void A::operator delete(void *)
>>>>>>>> void *C::operator new(unsigned long int)
>>>>>>>> void C::operator delete(void *)
>>>>>>>> Construction Join Points
>>>>>>>> Destruction Join Points
>>>>>>>> - Aspect Includes ...
>>>>>>>> - Final cleanup
>>>>>>>> - Committing
>>>>>>>> * Inserting unit pro- and epilogues
>>>>>>>> - Manipulating translation unit file main.cc
>>>>>>>> * Updating #line directives of generated code fragments
>>>>>>>> * Saving
>>>>>>>> - Expanding project includes
>>>>>>>> - Fixing #line directives
>>>>>>>> - Path "main.acc"
>>>>>>>> * Done
>>>>>>>> Compiling main.acc
>>>>>>>> ../Makefile.generic:80: recipe for target 'Junk/main.o' failed
>>>>>>>> make[3]: Leaving directory
>>>>>>>>
>>>>>>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++/tests/ExecAdviceNewDelete'
>>>>>>>>
>>>>>>>> STDERR:
>>>>>>>> --------
>>>>>>>> main.cc:5:30: warning: dynamic exception specifications are
>>>>>>> deprecated in C++11
>>>>>>>> [-Wdeprecated]
>>>>>>>> void *operator new (size_t ) throw(std::bad_alloc);
>>>>>>>> ^~~~~
>>>>>>>> main.cc:7:31: warning: dynamic exception specifications are
>>>>>>> deprecated in C++11
>>>>>>>> [-Wdeprecated]
>>>>>>>> void *operator new (size_t s) throw(std::bad_alloc) {
>>>>>>>> ^~~~~
>>>>>>>> main.cc: In function 'void* operator new(size_t)':
>>>>>>>> main.cc:7:7: error: declaration of 'void* operator new(size_t) throw
>>>>>>>> (std::bad_alloc)' has a different exception specifier
>>>>>>>> void *operator new (size_t s) throw(std::bad_alloc) {
>>>>>>>> ^~~~~~~~
>>>>>>>> main.cc:5:7: note: from previous declaration 'void* operator
>>>>>>> new(std::size_t)'
>>>>>>>> void *operator new (size_t ) throw(std::bad_alloc);
>>>>>>>> ^~~~~~~~
>>>>>>>> main.acc: In function 'void* operator new(std::size_t)':
>>>>>>>> main.acc:147:61: warning: dynamic exception specifications are
>>>>>>> deprecated in
>>>>>>>> C++11 [-Wdeprecated]
>>>>>>>> typedef TJP__Znwm_0< void *, void, void, void *(::size_t)
>>>>>>>> throw(std::bad_alloc), AC::TL< ::size_t, AC::TLE > > __TJP;
>>>>>>>> ^~~~~
>>>>>>>> main.cc: At global scope:
>>>>>>>> main.cc:11:33: warning: dynamic exception specifications are
>>>>>>> deprecated in C++11
>>>>>>>> [-Wdeprecated]
>>>>>>>> void *operator new[] (size_t s) throw(std::bad_alloc) {
>>>>>>>> ^~~~~
>>>>>>>> main.acc: In function 'void* operator new [](std::size_t)':
>>>>>>>> main.acc:198:61: warning: dynamic exception specifications are
>>>>>>> deprecated in
>>>>>>>> C++11 [-Wdeprecated]
>>>>>>>> typedef TJP__Znam_0< void *, void, void, void *(::size_t)
>>>>>>>> throw(std::bad_alloc), AC::TL< ::size_t, AC::TLE > > __TJP;
>>>>>>>> ^~~~~
>>>>>>>> make[3]: *** [Junk/main.o] Error 1
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> -----------------------------------------------------------------------------
>>>>>>>> TEST: Bug574
>>>>>>>>
>>>>>>> -----------------------------------------------------------------------------
>>>>>>>> STDOUT:
>>>>>>>> --------
>>>>>>>> make[3]: Entering directory
>>>>>>>>
>>>>>>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++/tests/Bug574'
>>>>>>>> Weaving main.cc
>>>>>>>> * Running ac++ 2.2
>>>>>>>> * Handling Translation Unit `main.cc'.
>>>>>>>> - Path "main.cc"
>>>>>>>> - Parsing ...
>>>>>>>> - Weaving Aspects Forward Declarations ...
>>>>>>>> - Inserting namespace AC
>>>>>>>> - Committing
>>>>>>>> - Preparing introductions ...
>>>>>>>> - Parsing again ...
>>>>>>>> - Weaving access control bypass classes ...
>>>>>>>> - Weaving Join Points ...
>>>>>>>> Advicecode manipulation
>>>>>>>> Collecting Advice
>>>>>>>> Setting up thisJoinPoint for aspectof
>>>>>>>> Create pointcut expression tree
>>>>>>>> Matching joinpoints
>>>>>>>> Aspect ordering ...
>>>>>>>> Creating project repository 'repo.acp'
>>>>>>>> Type Check Functions
>>>>>>>> Access Join Points
>>>>>>>> Get: bool Cyg_SchedThread::priority_inherited
>>>>>>>> Get: int Cyg_SchedThread::original_priority
>>>>>>>> Execution Join Points
>>>>>>>> Construction Join Points
>>>>>>>> Destruction Join Points
>>>>>>>> - Aspect Includes ...
>>>>>>>> - Final cleanup
>>>>>>>> - Committing
>>>>>>>> * Inserting unit pro- and epilogues
>>>>>>>> - Manipulating translation unit file main.cc
>>>>>>>> * Updating #line directives of generated code fragments
>>>>>>>> * Saving
>>>>>>>> - Expanding project includes
>>>>>>>> - Fixing #line directives
>>>>>>>> - Path "main.acc"
>>>>>>>> * Done
>>>>>>>> Compiling main.acc
>>>>>>>> Linking
>>>>>>>> make[3]: Leaving directory
>>>>>>>>
>>>>>>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++/tests/Bug574'
>>>>>>>> make[3]: Entering directory
>>>>>>>>
>>>>>>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++/tests/Bug574'
>>>>>>>> 1a2
>>>>>>>>> int Cyg_SchedThread::original_priority
>>>>>>>> ../Makefile.generic:48: recipe for target 'diff' failed
>>>>>>>> make[3]: Leaving directory
>>>>>>>>
>>>>>>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++/tests/Bug574'
>>>>>>>>
>>>>>>>> STDERR:
>>>>>>>> --------
>>>>>>>> make[3]: *** [diff] Error 1
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> -----------------------------------------------------------------------------
>>>>>>>> TEST: Bug598
>>>>>>>>
>>>>>>> -----------------------------------------------------------------------------
>>>>>>>> STDOUT:
>>>>>>>> --------
>>>>>>>> make[3]: Entering directory
>>>>>>>>
>>>>>>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++/tests/Bug598'
>>>>>>>> Weaving main.cc
>>>>>>>> * Running ac++ 2.2
>>>>>>>> * Handling Translation Unit `main.cc'.
>>>>>>>> - Path "main.cc"
>>>>>>>> - Parsing ...
>>>>>>>> - Weaving Aspects Forward Declarations ...
>>>>>>>> - Inserting namespace AC
>>>>>>>> - Committing
>>>>>>>> - Preparing introductions ...
>>>>>>>> - Parsing again ...
>>>>>>>> - Weaving access control bypass classes ...
>>>>>>>> - Weaving Join Points ...
>>>>>>>> Advicecode manipulation
>>>>>>>> Collecting Advice
>>>>>>>> Setting up thisJoinPoint for aspectof
>>>>>>>> Create pointcut expression tree
>>>>>>>> Matching joinpoints
>>>>>>>> Aspect ordering ...
>>>>>>>> Creating project repository 'repo.acp'
>>>>>>>> Type Check Functions
>>>>>>>> Access Join Points
>>>>>>>> Get: char const arr[2]
>>>>>>>> Execution Join Points
>>>>>>>> Construction Join Points
>>>>>>>> Destruction Join Points
>>>>>>>> - Aspect Includes ...
>>>>>>>> - Final cleanup
>>>>>>>> - Committing
>>>>>>>> * Inserting unit pro- and epilogues
>>>>>>>> - Manipulating translation unit file main.cc
>>>>>>>> * Updating #line directives of generated code fragments
>>>>>>>> * Saving
>>>>>>>> - Expanding project includes
>>>>>>>> - Fixing #line directives
>>>>>>>> - Path "main.acc"
>>>>>>>> * Done
>>>>>>>> Compiling main.acc
>>>>>>>> ../Makefile.generic:80: recipe for target 'Junk/main.o' failed
>>>>>>>> make[3]: Leaving directory
>>>>>>>>
>>>>>>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++/tests/Bug598'
>>>>>>>>
>>>>>>>> STDERR:
>>>>>>>> --------
>>>>>>>> main.acc: In instantiation of 'TResult __Get__Z4mainv_1_0(TEntity&,
>>>>>>> AC::RT<T>)
>>>>>>>> [with TResult = char; TEntity = const char]':
>>>>>>>> main.cc:16:66: required from here
>>>>>>>> main.acc:283:17: error: uninitialized const '__result_buffer'
>>>>>>> [-fpermissive]
>>>>>>>> const TResult __result_buffer;
>>>>>>>> ^~~~~~~~~~~~~~~
>>>>>>>> main.acc:285:19: error: assignment of read-only variable
>>>>>>> '__result_buffer'
>>>>>>>> __result_buffer = ::arr;
>>>>>>>> ~~~~~~~~~~~~~~~~^~~~
>>>>>>>> main.acc:285:19: error: invalid conversion from 'const char*' to
>>>>>>> 'char'
>>>>>>>> [-fpermissive]
>>>>>>>> make[3]: *** [Junk/main.o] Error 1
>>>>>>>>
>>>>>>>> Makefile:161: recipe for target 'all' failed
>>>>>>>> make[2]: *** [all] Error 1
>>>>>>>> make[2]: Leaving directory
>>>>>>>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++/tests'
>>>>>>>> Makefile:259: recipe for target 'testall' failed
>>>>>>>> make[1]: *** [testall] Error 2
>>>>>>>> make[1]: Leaving directory
>>>>>>>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++'
>>>>>>>> debian/rules:52: recipe for target 'test-builds' failed
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sent from my cell phone. Please excuse my brevity and typos.
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
