[aspectc-user] Compiler Error - Related Error being fixed in(Version 1.0pre1: 10/2005)?

Dimple dkaul at isis.vanderbilt.edu
Fri Oct 28 16:57:53 CEST 2005


Hi Olaf,
I was trying to build example makefile of 1.0pre1 version by running make
command in my installation path. It is giving me following error
"<my_installation_path> /ag++ --gen_config -o
<my_installation_path>/ac-1.0pre1/puma.config
<my_installation_path>/ac-1.0pre1/ag++:
<my_installation_path>/ac-1.0pre1/ag++: cannot execute binary file
make: *** [<my_installation_path>/ac-1.0pre1/puma.config] Error 126"

It seem there is no puma.config file in the directory. In your last release
you had puma.config file in main directory of installation.
Thanks,
Dimple

-----Original Message-----
From: aspectc-user-bounces at aspectc.org
[mailto:aspectc-user-bounces at aspectc.org] On Behalf Of Olaf Spinczyk
Sent: Friday, October 28, 2005 2:00 AM
To: John C. Weicher
Cc: aspectc-user at aspectc.org
Subject: Re: [aspectc-user] Compiler Error - Related Error being fixed
in(Version 1.0pre1: 10/2005)?

Hi John,

version 1.0pre1 contains a fix for your problem. I tested it with a 
SystemC application that has had a similar problem.

Of course, I'm interested in your top secret project ;-). Please keep us 
posted!

-Olaf


John C. Weicher wrote:
> Olaf-
>   Ha ha ha, please don't think me ungrateful, but I'd rather not say.
> There's some competition on the task, and I'd like to keep our doings to
> ourselves until we're ready to release.  It's always nice to be the first,
> you know?  As for AspectC++, it's been absolutely great.  Up until
recently
> our approach was direct modification of existing functions, hacking up the
> original application's source files, etc.  Okay for experimentation, but
> totally unacceptable in the end as a means of producing an external,
> optional patch-like modification, you know?  Then we discovered aspects,
and
> it's been great.  So definitely thank you for all your work.  I'll keep
you
> posted if you're interested!
> 
> -John
>  
> 
>>-----Original Message-----
>>From: Olaf Spinczyk [mailto:Olaf.Spinczyk at informatik.uni-erlangen.de]
>>Sent: Thursday, October 20, 2005 11:27 AM
>>To: John C. Weicher
>>Subject: Re: [aspectc-user] Compiler Error - Related Error being fixed in
>>(Version 1.0pre1: 10/2005)?
>>
>>John,
>>
>>on which open source project are you working? How much trouble did you
>>have with AspectC++ so far? ;-)
>>
>>Olaf
>>
>>
>>Olaf Spinczyk wrote:
>>>Hi,
>>>
>>>for SystemC there is no solution, yet. We hope simply that no user needs
>>>execution advice for the sc_main function ;-), which is similar to
>>>main() in normaly C++ code.
>>>
>>>The best solution would be a last minute fix that is integrated into
>>>version 1.0pre1. I'll do what I can.
>>>
>>>Olaf
>>>
>>>John C. Weicher wrote:
>>>>Olaf-
>>>>   Dead on!  That is exactly the situation.  And I discovered that
>>>>late last
>>>>night.  If I manually go in and add the declaration before the
>>>>definition,
>>>>it compiles perfectly (the extern header file issue never occurred to
>>me
>>>>though).  Do you have any suggestions on a way to get around this
>>without
>>>>the manual intervention? Because everything being open source, it
>>>>would be
>>>>nice to not make potential users who wanted to rebuild the app I'm
>>>>modifying
>>>>on their own, have to go in and do the same.  Right now the beauty is
>>>>that
>>>>everything is done by a single additional script that I would
>>distribute
>>>>with my modification/patch.  They'd just have to drop in the
>>>>distribution,
>>>>the scripts calls the aspect compiler to make the changes, calls the
>>apps
>>>>original make routines they would have had to call anyway, and bingo,
>>>>they've modified their app.  I'd love to be able to keep it that way.
>>>>
>>>>If this is not doable, I'll just have to come up with another
>>>>strategy.  I'm
>>>>sorry I've taken so much of your time on this issue already, as I know
>>>>now
>>>>it's kind of in my court.  But you mentioned another similar encounter,
>>>>SystemC?  What was the solution in that case?
>>>>
>>>>I really appreciate the help already given.
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Olaf Spinczyk [mailto:Olaf.Spinczyk at informatik.uni-erlangen.de]
>>>>>Sent: Thursday, October 20, 2005 11:00 AM
>>>>>To: John C. Weicher
>>>>>Cc: aspectc-user at aspectc.org
>>>>>Subject: Re: [aspectc-user] Compiler Error - Related Error being
>>>>>fixed in
>>>>>(Version 1.0pre1: 10/2005)?
>>>>>
>>>>>Hi,
>>>>>
>>>>>I'm slowly beginning to understand (at least I hope so) ...
>>>>>
>>>>>* you are using ac++ in the WPT mode and not via ag++
>>>>>* your command line options are "-p module/dev -d module"
>>>>>* the "include" directory tree does not belong to the project
>>>>>  (from ac++'s point of view)
>>>>>* the function for which you define execution advice is
>>>>>  *declared* somewhere in "include", but defined in your
>>>>>  part, i.e. module
>>>>>
>>>>>Is that right? It explains the behavior completely:
>>>>>
>>>>>* call advice works properly, as the location of the call is part
>>>>>  of the ac++ project
>>>>>
>>>>>* execution advice does not work completely, because there is a
>>function
>>>>>  declaration that does not belong to the ac++ project
>>>>>
>>>>>We have a similar problem with the SystemC library. In this case the
>>>>>function sc_main is declared in a library header file, but the
>>>>>implementation has to be provided in the application code.
>>>>>
>>>>>o check if we are right, you can insert a declaration of the function
>>in
>>>>>front of the definition. Then the execution advice should work as
>>>>>expected.
>>>>>
>>>>>Does that help?
>>>>>
>>>>>Olaf
>>>>>
>>>>>
>>>>>John C. Weicher wrote:
>>>>>>Olaf-
>>>>>>  As a matter of fact, yes, the prototype for the function that I am
>>>>>>attempting to call around is included in a header file that is
>>outside
>>>>>of my
>>>>>>project directory.  I am using aspects to increase the functionality
>>of
>>>>>one
>>>>>>module in a much larger open source application.  So like many such
>>>>>>applications, the source code that I am extending is in a separate
>>part
>>>>>of
>>>>>>the directory tree than the application's main include directory,
>>>>>containing
>>>>>>the headers for those sources:
>>>>>>
>>>>>>AppRoot
>>>>>>|
>>>>>>-- include  <- prototype for function I'm wrapping in header file
>>here
>>>>>>|              (It's an existing application function that I'm
>>>>>>wrapping,
>>>>>>|               not one of my own that I can easily relocate)
>>>>>>|
>>>>>>-- module   <- where I am placing weaved code to be placed so it can
>>>>>still
>>>>>>   |          be found by application's existing make routines, etc.
>>>>>>   |
>>>>>>   -- dev  <- new directory I've created where I've copied and keep
>>>>>>              original versions of source and aspects
>>>>>>
>>>>>>The problem is that this is a large application, to which I am
>>>>>>trying to
>>>>>>develop a useful extension to that I could offer to people.  I'm only
>>>>>>mentioning all this because the point is I want to keep my
>>>>>>modifications
>>>>>>through aspects as modularized from the rest of code as possible (so
>>it
>>>>>can
>>>>>>be easily applied by interested parties).  I want to avoid having to
>>>>>make
>>>>>>changes to files outside of that one 'module' directory (and more
>>>>>>specifically the 'dev') directory.  If possible, I want to avoid
>>having
>>>>>to
>>>>>>make changes to outside files, for example those in the apps main
>>>>>include
>>>>>>directory.  For this same reason, I don't want to rename any function
>>>>>names
>>>>>>as the function I am wrapping is actually called from a whole
>>different
>>>>>>module, which means I'd have to edit IT'S code as well, etc.
>>>>>>
>>>>>>I assume this is causing my problem, because there is then an
>>existing
>>>>>>prototype for the function that I am wrapping, which is a point you
>>>>>asked
>>>>>>about at the end of your last post.
>>>>>>
>>>>>>Is it possible to force ac++ to add any necessary new prototypes
>>right
>>>>>into
>>>>>>the file that contains the source for functions it is
>>>>>>weaving/modifying?
>>>>>>
>>>>>>Thanks again for your help.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: Olaf Spinczyk [mailto:Olaf.Spinczyk at informatik.uni-
>>erlangen.de]
>>>>>>>Sent: Thursday, October 20, 2005 3:16 AM
>>>>>>>To: John C. Weicher
>>>>>>>Cc: aspectc-user at aspectc.org
>>>>>>>Subject: Re: [aspectc-user] Compiler Error - Related Error being
>>fixed
>>>>>in
>>>>>>>(Version 1.0pre1: 10/2005)?
>>>>>>>
>>>>>>>Hi,
>>>>>>>
>>>>>>>there should be no problem, even if the called function (F1 in your
>>>>>>>example) is part of a separate library. The call advice only
>>>>>>>affects the
>>>>>>>function that calls (F2). You can test it with this example:
>>>>>>>
>>>>>>>void f2 () {
>>>>>>> puts ("hello");
>>>>>>>}
>>>>>>>
>>>>>>>int main () {
>>>>>>> f2 ();
>>>>>>>}
>>>>>>>
>>>>>>>aspect Foo {
>>>>>>> advice execution("% f2(...)") : before() {
>>>>>>>   printf ("before\n");
>>>>>>> }
>>>>>>> advice call("% puts(...)") && within("% f2(...)") : around() {
>>>>>>>   tjp->proceed ();
>>>>>>>   printf ("after\n");
>>>>>>> }
>>>>>>>};
>>>>>>>
>>>>>>>The libc function puts is definitely part of a separate library.
>>>>>>>
>>>>>>>AspectC++ does not generate the function prototype that is missing
>>in
>>>>>>>your case, if
>>>>>>>
>>>>>>>(A) somewhere is a prototype declaration of the wrapped function
>>(f2).
>>>>>>>   (in this case the wrapper function prototype will be generated in
>>>>>>>   front of this declaration and doesn't have to be generated in
>>front
>>>>>>>   of the definition)
>>>>>>>
>>>>>>>(B) the wrapped function is a member function of a class
>>>>>>>   (in this case the function is either defined in a class body and,
>>>>>>>   thus, declarations are not necessary, or the function is defined
>>>>>>>   outside the class body. In this case there will be a declaration
>>>>>>>   within the class body and the declaration of the wrapper function
>>>>>>>   will be generated there)
>>>>>>>
>>>>>>>Is it possible that there is a declaration of the function f2 (the
>>one
>>>>>>>for which you defined execution advice) in some header file that is
>>>>>>>*not* part of your project (-p option!)? Maybe it is the prototype
>>>>>>>of a
>>>>>>>different function that unintentionally has the same name. You
>>>>>>>could try
>>>>>>>to rename your function to rule out this possibility.
>>>>>>>
>>>>>>>- Olaf
>>>>>>>
>>>>>>>
>>>>>>>John C. Weicher wrote:
>>>>>>>>I apologize for not CC-ing my first response to the listserv as
>>well,
>>>>>so
>>>>>>>>thank you for doing so with your last reply, so that message can at
>>>>>>>least
>>>>>>>>now be included.
>>>>>>>>
>>>>>>>>With that said, unfortunately, I am not sure how to give you a
>>>>>>>>minimal
>>>>>>>step
>>>>>>>>by step, as when I do testing similar to yours, it works for me
>>too!
>>>>>>>But in
>>>>>>>>doing so, I have found what I think is the source of the problem.
>>>>>There
>>>>>>>is
>>>>>>>>in fact a prototype that is being omitted from the weaved code.
>>>>>>>>
>>>>>>>>Using the following example, all but identical to yours:
>>>>>>>>
>>>>>>>>void F1(){
>>>>>>>>}
>>>>>>>>
>>>>>>>>void F2(){
>>>>>>>>F1();
>>>>>>>>}
>>>>>>>>
>>>>>>>>int main(int argc, char **argv){
>>>>>>>> F2();
>>>>>>>> return 0;
>>>>>>>>}
>>>>>>>>
>>>>>>>>
>>>>>>>>aspect intercept{
>>>>>>>>
>>>>>>>>advice call("% F1(...)") && within("% F2(...)") : around() {
>>>>>>>>  printf("About to enter F1()\n");
>>>>>>>>  tjp->proceed();
>>>>>>>>}
>>>>>>>>
>>>>>>>>advice execution("% F2(...)") : before() {
>>>>>>>>  printf("About to enter F2\n");
>>>>>>>>}
>>>>>>>>};
>>>>>>>>--
>>>>>>>>
>>>>>>>>Everything here works just fine.  But when I go back and look at my
>>>>>>>actual
>>>>>>>>code, I notice a difference between it and the code generated for
>>the
>>>>>>>above
>>>>>>>>test.  In the above test, the modifications for the
>>execution/before
>>>>>>>advice
>>>>>>>>are as follows:
>>>>>>>>
>>>>>>>><snip>
>>>>>>>>#line 7 "./main.c"
>>>>>>>>
>>>>>>>>#line 1 ""
>>>>>>>>
>>>>>>>>inline void __exec_old_F2();
>>>>>>>>
>>>>>>>>#line 7 "./main.c"
>>>>>>>>void F2()
>>>>>>>>#line 1 ""
>>>>>>>>{
>>>>>>>>AC::invoke_intercept_intercept_a1_before ();
>>>>>>>>__exec_old_F2();
>>>>>>>>
>>>>>>>>}
>>>>>>>>inline void __exec_old_F2()
>>>>>>>>#line 7 "./main.c"
>>>>>>>>{
>>>>>>>>__call__ZN2F2Ev_0_0 ();
>>>>>>>>}
>>>>>>>><snip>
>>>>>>>>
>>>>>>>>This makes perfect sense.  We have the prototype for the inline
>>>>>>>>altered
>>>>>>>>original function, the replacement of the original function which
>>>>>>>>calls
>>>>>>>the
>>>>>>>>inline alternate, and then the definition of the inline alternate
>>>>>(which
>>>>>>>>itself has internal modifications due to the other call/around
>>advice
>>>>>>>for
>>>>>>>>the F1).
>>>>>>>>
>>>>>>>>The kicker is that in my real code, the general layout is the
>>>>>>>>same, but
>>>>>>>NO
>>>>>>>>prototype is ever inserted above the replacement of the original
>>>>>>>function.
>>>>>>>>There is just the replacement of the original function which calls
>>>>>>>>the
>>>>>>>>inline alternate, and then the definition of the inline alternate.
>>>>>>>Without
>>>>>>>>the prototype above all this, the undeclared error is going to
>>occur.
>>>>>>>>As I said, other than the above program you gave me, I don't know
>>how
>>>>>to
>>>>>>>>give you another minimal step by step.  The layout of my real
>>project
>>>>>is
>>>>>>>>identical.  Can you think of any other reason why a prototype
>>>>>>>>would be
>>>>>>>>omitted?
>>>>>>>>
>>>>>>>>Actually I just realized that I have made a mistake.  There is one
>>>>>>>>difference.  The function with the call/around advice (the nested
>>>>>>>function)
>>>>>>>>is NOT in the same file as the function causing problems with the
>>>>>>>missing
>>>>>>>>prototype.  It's part of another library.  I apologize I missed
>>this.
>>>>>>>>However, being call/around, the compiler never needs access to it's
>>>>>>>actual
>>>>>>>>code, correct?, and in fact I wasn't having any problems with it's
>>>>>>>>call/around advice anyway, until I added the execute/before advice
>>to
>>>>>>>the
>>>>>>>>function that calls IT.
>>>>>>>>
>>>>>>>>Phew!  Sorry for the long post.  Maybe this will change the
>>>>>>>>situation?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>-----Original Message-----
>>>>>>>>>From: John C. Weicher [mailto:jweicher at piocon.com]
>>>>>>>>>Sent: Wednesday, October 19, 2005 9:13 AM
>>>>>>>>>To: 'Olaf Spinczyk'
>>>>>>>>>Subject: RE: [aspectc-user] Compiler Error - Related Error being
>>>>>>>>>fixed
>>>>>>>in
>>>>>>>>>(Version 1.0pre1: 10/2005)?
>>>>>>>>>
>>>>>>>>>Thanks for your help so far.  There is really only one difference
>>>>>>>between
>>>>>>>>>my code and your test program.  It's not really a situation of
>>>>>>>around/call
>>>>>>>>>and before/execution of the same function.  Using your example,
>>the
>>>>>>>>>function having advice inserted before its execution is F2(), not
>>>>>F1().
>>>>>>>I
>>>>>>>>>of course have no idea if this should make any difference?
>>>>>>>>>
>>>>>>>>>In other words, in your program you have a function F1 that is
>>both
>>>>>>>being
>>>>>>>>>called around, as well as having code inserted before its
>>execution
>>>>>>>>>contents.
>>>>>>>>>
>>>>>>>>>In my code I have a function F1 that is being called around, and a
>>>>>>>>>_different_ function (from which the first is called), that is
>>>>>>>>>having
>>>>>>>the
>>>>>>>>>code inserted before it.
>>>>>>>>>
>>>>>>>>>I admit even to me this seems like a trivial difference, but you'd
>>>>>know
>>>>>>>>>far better.  Could there be a problem with applying before advice
>>>>>>>>>to a
>>>>>>>>>function and then applying around advice to another function call
>>>>>within
>>>>>>>>>it? Perhaps simply in how it decides in which order to append
>>weaved
>>>>>>>code
>>>>>>>>>to the source file?  I am totally grasping at straws here.
>>>>>>>>>Obviously
>>>>>>>the
>>>>>>>>>operations of the weaver are way over my head.  It's just that
>>>>>>>>>the odd
>>>>>>>>>thing is, if I go look at the source file, all the code for all
>>>>>advices
>>>>>>>is
>>>>>>>>>properly generated.  It's just that the code for the alternate
>>>>>>>>>call to
>>>>>>>the
>>>>>>>>>function to handle the before insertion is placed after it's
>>>>>invocation,
>>>>>>>>>giving the not defined error when parsed for compling.
>>>>>>>>>Otherwise, all
>>>>>>>the
>>>>>>>>>code is generated perfectly!
>>>>>>>>>
>>>>>>>>>Other that this though, nothing else mentioned comes to mind.
>>>>>Regarding
>>>>>>>>>your other questions, no, all applicable functions are in the same
>>>>>>>source
>>>>>>>>>file, and no recursion is involved.
>>>>>>>>>
>>>>>>>>>Thanks for your help.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>-----Original Message-----
>>>>>>>>>>From: Olaf Spinczyk
>>>>>>>>>>[mailto:Olaf.Spinczyk at informatik.uni-erlangen.de]
>>>>>>>>>>Sent: Wednesday, October 19, 2005 2:25 AM
>>>>>>>>>>To: John C. Weicher
>>>>>>>>>>Cc: aspectc-user at aspectc.org
>>>>>>>>>>Subject: Re: [aspectc-user] Compiler Error - Related Error being
>>>>>fixed
>>>>>>>>>in
>>>>>>>>>>(Version 1.0pre1: 10/2005)?
>>>>>>>>>>
>>>>>>>>>>Hi John,
>>>>>>>>>>
>>>>>>>>>>there is no general problem with around/call and before/execution
>>>>>>>advice
>>>>>>>>>>for the same function. I tried the following example without any
>>>>>>>>>>problems (version 0.9.3):
>>>>>>>>>>
>>>>>>>>>>--
>>>>>>>>>>void f1 () {
>>>>>>>>>>}
>>>>>>>>>>
>>>>>>>>>>void f2 () {
>>>>>>>>>>f1 ();
>>>>>>>>>>}
>>>>>>>>>>
>>>>>>>>>>int main () {
>>>>>>>>>>f2 ();
>>>>>>>>>>}
>>>>>>>>>>
>>>>>>>>>>aspect Foo {
>>>>>>>>>>advice call("% f1(...)") && within("% f2(...)") : around() {
>>>>>>>>>>  tjp->proceed ();
>>>>>>>>>>  printf ("after\n");
>>>>>>>>>>}
>>>>>>>>>>advice execution("% f1(...)") : before() {
>>>>>>>>>>  printf ("before\n");
>>>>>>>>>>}
>>>>>>>>>>};
>>>>>>>>>>--
>>>>>>>>>>
>>>>>>>>>>What is the difference between your code and this test program?
>>Are
>>>>>any
>>>>>>>>>>recursive functions involved? Is f2() declared in a separate
>>header
>>>>>>>file
>>>>>>>>>>that does not belong to your project?
>>>>>>>>>>
>>>>>>>>>>The (HUGE) problem with version 0.9.3 is a different one. It is
>>>>>related
>>>>>>>>>>to introductions.
>>>>>>>>>>
>>>>>>>>>>Best regards,
>>>>>>>>>>
>>>>>>>>>>Olaf
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>John C. Weicher wrote:
>>>>>>>>>>>I am running into an odd error during compilation that only
>>>>>>>>>>>crops up
>>>>>>>>>>>when I provide two separate advice calls which affect the same
>>>>>>>>>function.
>>>>>>>>>>>Simplified scenario exists where there is
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>someFunctionA(){
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>//blah blah
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>someFunctionB();
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>//blah blah
>>>>>>>>>>>
>>>>>>>>>>>}
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>I have already defined an aspect with advice as follows:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>advice call("% %someFunctionB(...)") && within("%
>>>>>>>>>%someFunctionA(...)")
>>>>>>>>>>>: around() {  //blah blah }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>Obviously I am trying to call around function B when called from
>>>>>>>>>within
>>>>>>>>>>>A (I do some other stuff, and then let it proceed).  This
>>weaves,
>>>>>>>>>>>parses, compiles and runs beautifully.  I've been using this in
>>a
>>>>>>>>>>>working application for some time now.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>A new situation has arisen for me now where in addition to the
>>>>>>>>>>>above
>>>>>>>>>>>(situation is the same, and the previous advice block is also
>>>>>>>>>>>still
>>>>>>>>>>>needed and in place), I ALSO want to define an additional advice
>>>>>block
>>>>>>>>>>>to perform some operations before the execution of function A,
>>>>>>>>>>>done
>>>>>as
>>>>>>>>>>>follows:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>advice execution("% %someFunctionA(...)") : before() {  // blah
>>>>>>>>>>>blah
>>>>>}
>>>>>>>>>>>
>>>>>>>>>>>This is causing problems.  Weaving still occurs without error,
>>but
>>>>>>>>>when
>>>>>>>>>>>I then try to compile weaved code, I receive the following error
>>>>>>>>>>>(changed the function names to match my fake example above, so
>>it
>>>>>>>>>makes
>>>>>>>>>>>sense):
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>: In function `int someFunctionA(args args args.)':
>>>>>>>>>>>
>>>>>>>>>>>:4: `__exec_old_someFunctionA' undeclared (first use this
>>>>>>>>>>>function)
>>>>>>>>>>>
>>>>>>>>>>>:4: (Each undeclared identifier is reported only once for each
>>>>>>>>>function
>>>>>>>>>>it
>>>>>>>>>>>appears in.)
>>>>>>>>>>>
>>>>>>>>>>>./thefile.c: In function `int __exec_old_someFunctionA(args arg
>>>>>>>>>args)':
>>>>>>>>>>>./thefile.c:280: `int __exec_old_someFunctionA(args args args)
>>>>>>>>>>>
>>>>>>>>>>>' used prior to declaration
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>And sure enough, when I go into the file the inline definition
>>for
>>>>>>>>>>>__exec_old_someFunctionA is coming after the modified call to
>>it.
>>>>>But
>>>>>>>>>I
>>>>>>>>>>>didn't think this mattered with inline functions.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>I apologize for the lengthy post, but I am definitely
>>>>>>>>>>>confused.  If
>>>>>I
>>>>>>>>>>>take the new additional advice block back out, everything
>>compiles
>>>>>>>>>fine
>>>>>>>>>>>again.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>I also noticed that although that it specifically mentions only
>>>>>>>>>classes,
>>>>>>>>>>>this sounds very similar to the issue that is supposed to be
>>fixed
>>>>>in
>>>>>>>>>>>the new release mentioned on the Roadmap page: "fix for the HUGE
>>>>>>>>>problem
>>>>>>>>>>>of ac++ 0.9.3 that causes parse errors, when an aspect defines
>>>>>>>>>>>code
>>>>>>>>>>>advice for a class into which it also introduces new
>>>>>>>>>functions/members".
>>>>>>>>>>>Is this the case, and if so is there a workaround in the
>>meantime?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>----------------------------------------------------------------
>>----
>>>>>--
>>>>>>>>>--
>>>>>>>>>>>_______________________________________________
>>>>>>>>>>>aspectc-user mailing list
>>>>>>>>>>>aspectc-user at aspectc.org
>>>>>>>>>>>http://www.aspectc.org/mailman/listinfo/aspectc-user
>>>>>>>>_______________________________________________
>>>>>>>>aspectc-user mailing list
>>>>>>>>aspectc-user at aspectc.org
>>>>>>>>http://www.aspectc.org/mailman/listinfo/aspectc-user
>>>>>>_______________________________________________
>>>>>>aspectc-user mailing list
>>>>>>aspectc-user at aspectc.org
>>>>>>http://www.aspectc.org/mailman/listinfo/aspectc-user
>>>>_______________________________________________
>>>>aspectc-user mailing list
>>>>aspectc-user at aspectc.org
>>>>http://www.aspectc.org/mailman/listinfo/aspectc-user
>>>_______________________________________________
>>>aspectc-user mailing list
>>>aspectc-user at aspectc.org
>>>http://www.aspectc.org/mailman/listinfo/aspectc-user
> 
> _______________________________________________
> aspectc-user mailing list
> aspectc-user at aspectc.org
> http://www.aspectc.org/mailman/listinfo/aspectc-user

_______________________________________________
aspectc-user mailing list
aspectc-user at aspectc.org
http://www.aspectc.org/mailman/listinfo/aspectc-user





More information about the aspectc-user mailing list