[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
