Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

I used GNU ARM to compile my sources which compiled fine, but when calling arm-elf-ld on the .o files, it complains about mulitple definitions of the included routines.

utils.o(.text+0x1dc): D:/BREWSD~1/inc/AEENet.h:421: multiple definition of `ISOCKET_Realize'
paint.o(.text+0x2b24): D:/BREWSD~1/inc/AEENet.h:421: first defined here
utils.o(.text+0x20c): D:/BREWSD~1/inc/AEENet.h:431: multiple definition of `ISOCKET_Listen'
paint.o(.text+0x2b54): D:/BREWSD~1/inc/AEENet.h:431: first defined here
utils.o(.text+0x240): D:/BREWSD~1/inc/AEENet.h:435: multiple definition of `ISOCKET_Accept'
paint.o(.text+0x2b88): D:/BREWSD~1/inc/AEENet.h:435: first defined here
.....
NMAKE : fatal error U1077: 'D:\gnude\bin\arm-elf-ld' : return code '0x1'
Stop.

This error comes for all the pseudo-methods defined in AEENet.h.
the problem is same as the one mentioned in the thread "conflicting .h declarations",
http://brewforums.qualcomm.com/show...596&mode=linear

Unfortunately I did not find any answers to this in that thread.

Any help would be very much appreciated.

Thanks in advance.
R.Pradeep

can we see your .mak file.

can we see your .mak file.

Hi skumar_rao,
here is the make file, this file was auto-generated by the VSAddin.
all the environment variable paths specified are correct and i use the of BREW SDK version 2.1.3 and nmake for compilation.

Hi skumar_rao,
here is the make file, this file was auto-generated by the VSAddin.
all the environment variable paths specified are correct and i use the of BREW SDK version 2.1.3 and nmake for compilation.

can you run it my using nmake /f / i from command line.

can you run it my using nmake /f / i from command line.

Your compiler isn't considering __inline to also mean static. Try changing the header to use static __inline. It's redundant, but shouldn't hurt. My guess would be that it's probably not inlining them either, but that's only an optimization issue.
This is the sort of thing that happens when you rely on language extensions like __inline. There's no reason these things couldn't have been macros.

Your compiler isn't considering __inline to also mean static. Try changing the header to use static __inline. It's redundant, but shouldn't hurt. My guess would be that it's probably not inlining them either, but that's only an optimization issue.
This is the sort of thing that happens when you rely on language extensions like __inline. There's no reason these things couldn't have been macros.

Hi RPDP,
Did the above solutions work for you. ??

Hi RPDP,
Did the above solutions work for you. ??

Thanks skumar_rao and rabidcow. :)
nmake /f / i
did not work for me, it threw the same error as mentioned previously.
But
Try changing the header to use "static __inline". [in AEENet.h]
worked out for me.
The compilation now generates the .mod file without any problems.
Once again thanks for helping me out.
Also this solution arises 2 questions in my mind:
1. Is changing the header files provided by SDK a good choice ? Will it cause any problems in the device?
2. I am using gnude 3.3.1 and installed and configured it as given in this article .
Did anyone else had the same problem?
if yes, is this the only solution for this problem?
if not, is the configuration of gnude specified in the article missing something?
Thanks
R.Pradeep

Thanks skumar_rao and rabidcow. :)
nmake /f / i
did not work for me, it threw the same error as mentioned previously.
But
Try changing the header to use "static __inline". [in AEENet.h]
worked out for me.
The compilation now generates the .mod file without any problems.
Once again thanks for helping me out.
Also this solution arises 2 questions in my mind:
1. Is changing the header files provided by SDK a good choice ? Will it cause any problems in the device?
2. I am using gnude 3.3.1 and installed and configured it as given in this article .
Did anyone else had the same problem?
if yes, is this the only solution for this problem?
if not, is the configuration of gnude specified in the article missing something?
Thanks
R.Pradeep

Quote:Did anyone else had the same problem?
I did not find this problem i use same Gnude also.

Quote:Did anyone else had the same problem?
I did not find this problem i use same Gnude also.

So it seems i am missing something in the configuration. It would be helpful if you can provide the details about how you configured the gnude and what steps you followed.

So it seems i am missing something in the configuration. It would be helpful if you can provide the details about how you configured the gnude and what steps you followed.

It is long back when i setup the Gnude. I followed one of the post here in this forum .http://brewforums.qualcomm.com/showthread.php?s=&threadid=1601

It is long back when i setup the Gnude. I followed one of the post here in this forum .http://brewforums.qualcomm.com/showthread.php?s=&threadid=1601

I went thru the thread and it was very useful, but it provides support for only one .c file [and I have about four]. I will try it and configure as specified.
Any details for compiling mulitple files would be helpful.
Also was anyone able to find out any reasons for having this problem.
Why should the same gnude gcc compiler show the error in one case and not for others?
The same code seems to compile without any error in ADS. So the sources i have are clear.
Any insight into this behaviour will be help us very much in understanding the configurations better.

I went thru the thread and it was very useful, but it provides support for only one .c file [and I have about four]. I will try it and configure as specified.
Any details for compiling mulitple files would be helpful.
Also was anyone able to find out any reasons for having this problem.
Why should the same gnude gcc compiler show the error in one case and not for others?
The same code seems to compile without any error in ADS. So the sources i have are clear.
Any insight into this behaviour will be help us very much in understanding the configurations better.

Did you tryed WinARM. It has a new GCC version

Did you tryed WinARM. It has a new GCC version

I tried WinARM also, but the same error occurs. so it seems that the GCC version is not the problem.
So i think one of the following may be causing the problem:
1. Configuration of gnude is missing something
Quote:I am using gnude 3.3.1 and installed and configured it as given in this article .
2. Certain headers when included to the sources, compiles fine in ADS, but conflicts when compiled with GNU ARM. I will check out by compiling other projects with the same configuration and see what happens.
[Has anyone used AEENet.h within their project and was able to compile without this problem, with GNU ARM ?]
3. maybe the problem is with auto-generated make-file and needs some changes.
Thanks
R.Pradeep

I tried WinARM also, but the same error occurs. so it seems that the GCC version is not the problem.
So i think one of the following may be causing the problem:
1. Configuration of gnude is missing something
Quote:I am using gnude 3.3.1 and installed and configured it as given in this article .
2. Certain headers when included to the sources, compiles fine in ADS, but conflicts when compiled with GNU ARM. I will check out by compiling other projects with the same configuration and see what happens.
[Has anyone used AEENet.h within their project and was able to compile without this problem, with GNU ARM ?]
3. maybe the problem is with auto-generated make-file and needs some changes.
Thanks
R.Pradeep

I'm actually using AEENet.h and didn't think to look at what I've done... Apparently I ran across the exact same problem in January and converted all of the "pseudo-methods" except for ISOCKET_GetSockName (which I just removed) to macros:
#define ISOCKET_Realize(me) ISOCKET_IOCtl(me, ISOCKET_IOCTL_REALIZE, 0)
#define ISOCKET_Listen(me, nBacklog) ISOCKET_IOCtl(me, ISOCKET_IOCTL_LISTEN, (uint32)(nBacklog))
#define ISOCKET_Accept(me, pps) ISOCKET_IOCtl(me, ISOCKET_IOCTL_ACCEPT, (uint32)(pps))
#define ISOCKET_Shutdown(me, nHow) ISOCKET_IOCtl(me, ISOCKET_IOCTL_SHUTDOWN, (uint32)(nHow))
#define ISOCKET_Close(me) ISOCKET_IOCtl(me, ISOCKET_IOCTL_CLOSE, 0)
I am not using the autogenerated make files, so if it's missing a flag, so am I. (and I looked through all of GCC's flags when I made the makefile.) It sounds like a compiler bug to me... GCC obviously recognizes __inline, but doesn't tell the linker to merge or ignore the duplicate code generated.

I'm actually using AEENet.h and didn't think to look at what I've done... Apparently I ran across the exact same problem in January and converted all of the "pseudo-methods" except for ISOCKET_GetSockName (which I just removed) to macros:
#define ISOCKET_Realize(me) ISOCKET_IOCtl(me, ISOCKET_IOCTL_REALIZE, 0)
#define ISOCKET_Listen(me, nBacklog) ISOCKET_IOCtl(me, ISOCKET_IOCTL_LISTEN, (uint32)(nBacklog))
#define ISOCKET_Accept(me, pps) ISOCKET_IOCtl(me, ISOCKET_IOCTL_ACCEPT, (uint32)(pps))
#define ISOCKET_Shutdown(me, nHow) ISOCKET_IOCtl(me, ISOCKET_IOCTL_SHUTDOWN, (uint32)(nHow))
#define ISOCKET_Close(me) ISOCKET_IOCtl(me, ISOCKET_IOCTL_CLOSE, 0)
I am not using the autogenerated make files, so if it's missing a flag, so am I. (and I looked through all of GCC's flags when I made the makefile.) It sounds like a compiler bug to me... GCC obviously recognizes __inline, but doesn't tell the linker to merge or ignore the duplicate code generated.

---------------------------------------------------------------
EDIT: The problem still exists. It was my mistake, I didnt revert back to the original AEENet.h when copying "inc" and "src" to ..\gnude\2.1.3\ as specified by Tyndal.
And after that I reverted back the original file only in the BREW SDK install. So naturally when compiling by Tyndal's method, it used the "inc" from ..\gnude\2.1.3
which had the change specified by rabidcow.
Sorry for the inconvenience. :o
The search for the solution starts again...... :confused:
---------------------------------------------------------------
Hi rabidcow,
Thanks for the reply, I had the problem solved by configuring the enviroment as said in this thread
The problem i had after configuring, was compiling multiple files that i had, as the above configuration worked for only single source file - projects. So I changed the make file a little to compile multiple files and it worked without a glitch.[using the original AEENet.h ]
I will post the changes that were made, after consolidating all the changes I made.
Also we need to look to see which settings caused the problem, so that we can use the auto-generated make file and also have a better understanding of the GNU ARM configuration.
Once again, thanks to you and skumar_rao for the support extended in resolving this problem. :)
Thanks,
R.Pradeep

---------------------------------------------------------------
EDIT: The problem still exists. It was my mistake, I didnt revert back to the original AEENet.h when copying "inc" and "src" to ..\gnude\2.1.3\ as specified by Tyndal.
And after that I reverted back the original file only in the BREW SDK install. So naturally when compiling by Tyndal's method, it used the "inc" from ..\gnude\2.1.3
which had the change specified by rabidcow.
Sorry for the inconvenience. :o
The search for the solution starts again...... :confused:
---------------------------------------------------------------
Hi rabidcow,
Thanks for the reply, I had the problem solved by configuring the enviroment as said in this thread
The problem i had after configuring, was compiling multiple files that i had, as the above configuration worked for only single source file - projects. So I changed the make file a little to compile multiple files and it worked without a glitch.[using the original AEENet.h ]
I will post the changes that were made, after consolidating all the changes I made.
Also we need to look to see which settings caused the problem, so that we can use the auto-generated make file and also have a better understanding of the GNU ARM configuration.
Once again, thanks to you and skumar_rao for the support extended in resolving this problem. :)
Thanks,
R.Pradeep

---------------------------------------------------------------
EDIT: The problem still exists. It was my mistake, I didnt revert back to the original AEENet.h when copying "inc" and "src" to ..\gnude\2.1.3\ as specified by Tyndal.
And after that I reverted back the original file only in the BREW SDK install. So naturally when compiling by Tyndal's method, it used the "inc" from ..\gnude\2.1.3
which had the change specified by rabidcow.
Also removed the attachment as they are no longer useful..
Sorry for the inconvenience.
The search for the solution starts again......
---------------------------------------------------------------
Hi All,
Here are the build files which worked for me, i had to change the makefile a little to support mulitple source file compilation and etc...
Thanks to Tyndal for putting up a wonderful set of instructions in this thread
and also thanks to Simon for posting the make file for supporting .cpp which also supported multiple file compilation, provided in this thread
If you find any mistakes in the files, feel free to reply and help me in correcting it.
Thanks
R.Pradeep

---------------------------------------------------------------
EDIT: The problem still exists. It was my mistake, I didnt revert back to the original AEENet.h when copying "inc" and "src" to ..\gnude\2.1.3\ as specified by Tyndal.
And after that I reverted back the original file only in the BREW SDK install. So naturally when compiling by Tyndal's method, it used the "inc" from ..\gnude\2.1.3
which had the change specified by rabidcow.
Also removed the attachment as they are no longer useful..
Sorry for the inconvenience.
The search for the solution starts again......
---------------------------------------------------------------
Hi All,
Here are the build files which worked for me, i had to change the makefile a little to support mulitple source file compilation and etc...
Thanks to Tyndal for putting up a wonderful set of instructions in this thread
and also thanks to Simon for posting the make file for supporting .cpp which also supported multiple file compilation, provided in this thread
If you find any mistakes in the files, feel free to reply and help me in correcting it.
Thanks
R.Pradeep

Hi All,
The solution I posted was short-lived, it was due to a small :D mistake I did as explained above.
Anyways I will look out for a solution which does not change the SDK files. Till then I will use the solution that rabidcow mentioned.
Thanks,
R.Pradeep
P.S: Has anyone else had the same problem and is there any solution to put an end to this problem. :confused:

Hi All,
The solution I posted was short-lived, it was due to a small :D mistake I did as explained above.
Anyways I will look out for a solution which does not change the SDK files. Till then I will use the solution that rabidcow mentioned.
Thanks,
R.Pradeep
P.S: Has anyone else had the same problem and is there any solution to put an end to this problem. :confused:

I changed the AEENet.h file with the changes specified by rabidcow. And then compiled the .dll for emulator. The app launches fine but when a network request is made, the emulator crashes.
I think this is similar to the PACKED issue with 1.1 sdk, which was updated later in BREW SDK.
as given in this thread:
http://brewforums.qualcomm.com/showthread.php?t=1370
http://brewforums.qualcomm.com/showpost.php?p=4690&postcount=7
The above post in that thread mentions that editing causes crashes on the devices
A question for rabidcow: :confused:
did you to generate .dll and did it work fine in the emulator?
Once Again: :eek:
Is there anyone else in this forum, who was able to use AEENet.h with multiple source files and compile successfully in GNU ARM???

I changed the AEENet.h file with the changes specified by rabidcow. And then compiled the .dll for emulator. The app launches fine but when a network request is made, the emulator crashes.
I think this is similar to the PACKED issue with 1.1 sdk, which was updated later in BREW SDK.
as given in this thread:
http://brewforums.qualcomm.com/showthread.php?t=1370
http://brewforums.qualcomm.com/showpost.php?p=4690&postcount=7
The above post in that thread mentions that editing causes crashes on the devices
A question for rabidcow: :confused:
did you to generate .dll and did it work fine in the emulator?
Once Again: :eek:
Is there anyone else in this forum, who was able to use AEENet.h with multiple source files and compile successfully in GNU ARM???

RPDP wrote:
A question for rabidcow: :confused:
did you to generate .dll and did it work fine in the emulator?
Yes, of course. It works on the emulator and on the handset. These functions are not part of the binary interface, and are written entirely using documented APIs themselves. And even if that did matter, the macros should generate the same code as you would get from inlining the functions.
The changes mentioned in the other thread change structure layouts for the API. Structure layout is part of the binary interface. That's the key difference here: code on either side of the API depends on exact structure representation, but only your code sees how these functions are inlined.

RPDP wrote:
A question for rabidcow: :confused:
did you to generate .dll and did it work fine in the emulator?
Yes, of course. It works on the emulator and on the handset. These functions are not part of the binary interface, and are written entirely using documented APIs themselves. And even if that did matter, the macros should generate the same code as you would get from inlining the functions.
The changes mentioned in the other thread change structure layouts for the API. Structure layout is part of the binary interface. That's the key difference here: code on either side of the API depends on exact structure representation, but only your code sees how these functions are inlined.

hi rabidcow,
The options you specified does generate the the .dll and .mod file and the application also launches and works fine. But I dont understand why the emulator crashes when a network request is made. The same code generates a .dll that works fine when compiled with VS. The only difference seems to be the size of the .dll 80K for VS and just 20K for GCC :confused:. [ I confirmed that all the .o files are linked in this case]
So it seems that I am missing some option while compiling and linking multiple files using GCC.
It would be helpful if you can post a sample make file to generate .dll, which compiles multiple files and worked for you.
Thanks,
R.Pradeep

hi rabidcow,
The options you specified does generate the the .dll and .mod file and the application also launches and works fine. But I dont understand why the emulator crashes when a network request is made. The same code generates a .dll that works fine when compiled with VS. The only difference seems to be the size of the .dll 80K for VS and just 20K for GCC :confused:. [ I confirmed that all the .o files are linked in this case]
So it seems that I am missing some option while compiling and linking multiple files using GCC.
It would be helpful if you can post a sample make file to generate .dll, which compiles multiple files and worked for you.
Thanks,
R.Pradeep

RPDP wrote:
The options you specified does generate the the .dll and .mod file and the application also launches and works fine. But I dont understand why the emulator crashes when a network request is made. The same code generates a .dll that works fine when compiled with VS. The only difference seems to be the size of the .dll 80K for VS and just 20K for GCC :confused:. [ I confirmed that all the .o files are linked in this case]
Ah... well... to make the dll, I use the Visual C++ Toolkit (2003). Using two different compilers will catch more oddities in the code, because you get different sets of warnings. (And I'm not sure I want to deal with keeping two sets of GNU compiler tools working on one machine...)
RPDP wrote:
It would be helpful if you can post a sample make file to generate .dll, which compiles multiple files and worked for you.
Unfortunately my build system is a combination of several make files and a perl script, so it's not really good as a sample. I can get you the command lines generated in the end, but again I use MSVC for compiling the dll.

RPDP wrote:
The options you specified does generate the the .dll and .mod file and the application also launches and works fine. But I dont understand why the emulator crashes when a network request is made. The same code generates a .dll that works fine when compiled with VS. The only difference seems to be the size of the .dll 80K for VS and just 20K for GCC :confused:. [ I confirmed that all the .o files are linked in this case]
Ah... well... to make the dll, I use the Visual C++ Toolkit (2003). Using two different compilers will catch more oddities in the code, because you get different sets of warnings. (And I'm not sure I want to deal with keeping two sets of GNU compiler tools working on one machine...)
RPDP wrote:
It would be helpful if you can post a sample make file to generate .dll, which compiles multiple files and worked for you.
Unfortunately my build system is a combination of several make files and a perl script, so it's not really good as a sample. I can get you the command lines generated in the end, but again I use MSVC for compiling the dll.

I could not find out any suitable solutions for this problem till now. I tried out almost all of the options specified in this forum and also in other gcc related forums.
Some information about GCC and inline keyword found in gcc info.
An Inline Function is As Fast As a Macro
========================================
By declaring a function `inline', you can direct GCC to integrate
that function's code into the code for its callers. This makes
execution faster by eliminating the function-call overhead; in
addition, if any of the actual argument values are constant, their known
values may permit simplifications at compile time so that not all of the
inline function's code needs to be included. The effect on code size is
less predictable; object code may be larger or smaller with function
inlining, depending on the particular case. Inlining of functions is an
optimization and it really "works" only in optimizing compilation. If
you don't use `-O', no function is really inline.
Inline functions are included in the ISO C99 standard, but there are
currently substantial differences between what GCC implements and what
the ISO C99 standard requires.
To declare a function inline, use the `inline' keyword in its
declaration, like this:
inline int
inc (int *a)
{
(*a)++;
}
[B](If you are writing a header file to be included in ISO C programs,
write `__inline__' instead of `inline'. *Note Alternate Keywords::.)
You can also make all "simple enough" functions inline with the option
`-finline-functions'.
Note that certain usages in a function definition can make it
unsuitable for inline substitution. Among these usages are: use of
varargs, use of alloca, use of variable sized data types (*note
Variable Length:: ), use of computed goto (*note Labels as Values:: ),
use of nonlocal goto, and nested functions (*note Nested Functions:: ).
Using `-Winline' will warn when a function marked `inline' could not be
substituted, and will give the reason for the failure.
Note that in C and Objective-C, unlike C++, the `inline' keyword
does not affect the linkage of the function.
GCC automatically inlines member functions defined within the class
body of C++ programs even if they are not explicitly declared `inline'.
(You can override this with `-fno-default-inline'; *note Options
Controlling C++ Dialect: C++ Dialect Options..)
When a function is both inline and `static', if all calls to the
function are integrated into the caller, and the function's address is
never used, then the function's own assembler code is never referenced.
In this case, GCC does not actually output assembler code for the
function, unless you specify the option `-fkeep-inline-functions'.
Some calls cannot be integrated for various reasons (in particular,
calls that precede the function's definition cannot be integrated, and
neither can recursive calls within the definition). If there is a
nonintegrated call, then the function is compiled to assembler code as
usual. The function must also be compiled as usual if the program
refers to its address, because that can't be inlined.
When an inline function is not `static', then the compiler must
assume that there may be calls from other source files; since a global
symbol can be defined only once in any program, the function must not
be defined in the other source files, so the calls therein cannot be
integrated. Therefore, a non-`static' inline function is always
compiled on its own in the usual fashion.
If you specify both `inline' and `extern' in the function
definition, then the definition is used only for inlining. In no case
is the function compiled on its own, not even if you refer to its
address explicitly. Such an address becomes an external reference, as
if you had only declared the function, and had not defined it.
This combination of `inline' and `extern' has almost the effect of a
macro. The way to use it is to put a function definition in a header
file with these keywords, and put another copy of the definition
(lacking `inline' and `extern') in a library file. The definition in
the header file will cause most calls to the function to be inlined.
If any uses of the function remain, they will refer to the single copy
in the library.
Since GCC eventually will implement ISO C99 semantics for inline
functions, it is best to use `static inline' only to guarentee
compatibility. (The existing semantics will remain available when
`-std=gnu89' is specified, but eventually the default will be
`-std=gnu99' and that will implement the C99 semantics, though it does
not do so yet.)
GCC does not inline any functions when not optimizing unless you
specify the `always_inline' attribute for the function, like this:
/* Prototype. */
inline void foo (const char) __attribute__((always_inline));
[/B]
I maybe wrong, but I feel that the __inline declaration in AEENet.h is not so GCC-friendly and is causing trouble.
Hope BREW SUPPORT people has an answer for this problem :confused: .

I could not find out any suitable solutions for this problem till now. I tried out almost all of the options specified in this forum and also in other gcc related forums.
Some information about GCC and inline keyword found in gcc info.
An Inline Function is As Fast As a Macro
========================================
By declaring a function `inline', you can direct GCC to integrate
that function's code into the code for its callers. This makes
execution faster by eliminating the function-call overhead; in
addition, if any of the actual argument values are constant, their known
values may permit simplifications at compile time so that not all of the
inline function's code needs to be included. The effect on code size is
less predictable; object code may be larger or smaller with function
inlining, depending on the particular case. Inlining of functions is an
optimization and it really "works" only in optimizing compilation. If
you don't use `-O', no function is really inline.
Inline functions are included in the ISO C99 standard, but there are
currently substantial differences between what GCC implements and what
the ISO C99 standard requires.
To declare a function inline, use the `inline' keyword in its
declaration, like this:
inline int
inc (int *a)
{
(*a)++;
}
[B](If you are writing a header file to be included in ISO C programs,
write `__inline__' instead of `inline'. *Note Alternate Keywords::.)
You can also make all "simple enough" functions inline with the option
`-finline-functions'.
Note that certain usages in a function definition can make it
unsuitable for inline substitution. Among these usages are: use of
varargs, use of alloca, use of variable sized data types (*note
Variable Length:: ), use of computed goto (*note Labels as Values:: ),
use of nonlocal goto, and nested functions (*note Nested Functions:: ).
Using `-Winline' will warn when a function marked `inline' could not be
substituted, and will give the reason for the failure.
Note that in C and Objective-C, unlike C++, the `inline' keyword
does not affect the linkage of the function.
GCC automatically inlines member functions defined within the class
body of C++ programs even if they are not explicitly declared `inline'.
(You can override this with `-fno-default-inline'; *note Options
Controlling C++ Dialect: C++ Dialect Options..)
When a function is both inline and `static', if all calls to the
function are integrated into the caller, and the function's address is
never used, then the function's own assembler code is never referenced.
In this case, GCC does not actually output assembler code for the
function, unless you specify the option `-fkeep-inline-functions'.
Some calls cannot be integrated for various reasons (in particular,
calls that precede the function's definition cannot be integrated, and
neither can recursive calls within the definition). If there is a
nonintegrated call, then the function is compiled to assembler code as
usual. The function must also be compiled as usual if the program
refers to its address, because that can't be inlined.
When an inline function is not `static', then the compiler must
assume that there may be calls from other source files; since a global
symbol can be defined only once in any program, the function must not
be defined in the other source files, so the calls therein cannot be
integrated. Therefore, a non-`static' inline function is always
compiled on its own in the usual fashion.
If you specify both `inline' and `extern' in the function
definition, then the definition is used only for inlining. In no case
is the function compiled on its own, not even if you refer to its
address explicitly. Such an address becomes an external reference, as
if you had only declared the function, and had not defined it.
This combination of `inline' and `extern' has almost the effect of a
macro. The way to use it is to put a function definition in a header
file with these keywords, and put another copy of the definition
(lacking `inline' and `extern') in a library file. The definition in
the header file will cause most calls to the function to be inlined.
If any uses of the function remain, they will refer to the single copy
in the library.
Since GCC eventually will implement ISO C99 semantics for inline
functions, it is best to use `static inline' only to guarentee
compatibility. (The existing semantics will remain available when
`-std=gnu89' is specified, but eventually the default will be
`-std=gnu99' and that will implement the C99 semantics, though it does
not do so yet.)
GCC does not inline any functions when not optimizing unless you
specify the `always_inline' attribute for the function, like this:
/* Prototype. */
inline void foo (const char) __attribute__((always_inline));
[/B]
I maybe wrong, but I feel that the __inline declaration in AEENet.h is not so GCC-friendly and is causing trouble.
Hope BREW SUPPORT people has an answer for this problem :confused: .