You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by "Senaka Fernando (JIRA)" <ji...@apache.org> on 2008/03/01 20:44:51 UTC
[jira] Issue Comment Edited: (AXIS2C-1040) Use of AXIS2_EXPORT
instead of AXIS2_EXTERN in a few places causes errors in static build
[ https://issues.apache.org/jira/browse/AXIS2C-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12574143#action_12574143 ]
senakafdo edited comment on AXIS2C-1040 at 3/1/08 11:44 AM:
------------------------------------------------------------------
Hi Frank,
Let me take the block,
#elif defined(AXIS2_DECLARE_STATIC)
#define AXIS2_EXTERN
#define AXIS2_EXTERN_NONSTD
#define AXIS2_DECLARE_DATA
#elif defined(AXIS2_DECLARE_EXPORT)
#define AXIS2_EXTERN AXIS2_EXPORT
#define AXIS2_EXTERN_NONSTD AXIS2_EXPORT
#define AXIS2_DECLARE_DATA
#else
#define AXIS2_EXTERN AXIS2_IMPORT
#define AXIS2_EXTERN_NONSTD AXIS2_IMPORT
#define AXIS2_DECLARE_DATA
#endif
from axutil_utils_defines.h
As you see, if you won't define AXIS2_DECLARE_STATIC, as well as AXIS2_DECLARE_EXPORT, then AXIS2_EXTERN will be defined as AXIS2_IMPORT. Thus, in a situation where you find some methods need the AXIS2_IMPORT, and some need AXIS2_EXPORT, you won't be able to build the source. Thus, defining the ones that are always going to be AXIS2_EXPORT as in the code you pointed out, and using AXIS2_EXTERN for the rest, gives us the opportunity to undefine both AXIS2_DECLARE_STATIC and AXIS2_DECLARE_EXPORT build.
That's the reason to why I came up with the solution discussed above. This will be the most realistic solution to suit all such situations. Therefore, Frank, AXIS2_EXTERN should only be used for methods that can either be used as AXIS2_EXPORT and AXIS2_IMPORT according to the situation. I hope the use of AXIS_EXPORT in place of AXIS_EXTERN was intentional rather.
Regards,
Senaka
was (Author: senakafdo):
Hi Frank,
Let me take the block,
#elif defined(AXIS2_DECLARE_STATIC)
#define AXIS2_EXTERN
#define AXIS2_EXTERN_NONSTD
#define AXIS2_DECLARE_DATA
#elif defined(AXIS2_DECLARE_EXPORT)
#define AXIS2_EXTERN AXIS2_EXPORT
#define AXIS2_EXTERN_NONSTD AXIS2_EXPORT
#define AXIS2_DECLARE_DATA
#else
#define AXIS2_EXTERN AXIS2_IMPORT
#define AXIS2_EXTERN_NONSTD AXIS2_IMPORT
#define AXIS2_DECLARE_DATA
#endif
from axutil_utils_defines.h
As you see, if you won't define AXIS2_DECLARE_STATIC, as well as AXIS2_DECLARE_EXPORT, then AXIS2_EXTERN will be defined as AXIS2_IMPORT. Thus, in a situation where you find some methods need the AXIS2_IMPORT, and some need AXIS2_EXPORT, you won't be able to build the source. Thus, defining the ones that are always going to be AXIS2_EXPORT as in the code you pointed out, and using AXIS2_EXTERN for the rest, gives us the opportunity to undefine both AXIS2_DECLARE_STATIC and AXIS2_DECLARE_EXPORT build.
That's the reason to why I came up with the solution discussed above. This will be the most realistic solution to suit all such situations. Therefore, Frank, AXIS2_EXTERN should only be used for methods that can either be used as AXIS2_EXPORT and AXIS2_IMPORT according to the situation. I hope the use of AXIS_EXPORT in place on AXIS_EXTERN was intentional rather.
Regards,
Senaka
> Use of AXIS2_EXPORT instead of AXIS2_EXTERN in a few places causes errors in static build
> -----------------------------------------------------------------------------------------
>
> Key: AXIS2C-1040
> URL: https://issues.apache.org/jira/browse/AXIS2C-1040
> Project: Axis2-C
> Issue Type: Bug
> Components: util
> Reporter: Frank Huebbers
>
> I have seen a few places where the typedef AXIS2_EXPORT is used instead of AXIS2_EXTERN. Doing a simple search, I have seen this in the following fiels:
> - axis2_msg_recv.h
> - msg_recv.c
> - raw_xml_in_out_msg_recv.c
> - svr_callback.c
> - mod_addr.c
> - http_transport_sender.c
> - http_receiver.c
> - http_svr_thread.c
> - tcp_transport_sender.c
> - tcp_svr_thread.c
> - tcp_receiver.c
> Note that the definitions are correct in the header files.
> Frank
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org