[
https://issues.apache.org/jira/browse/PROTON-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14143520#comment-14143520
]
Andrew Stitcher commented on PROTON-660:
----------------------------------------
I don't have a setup to try this on windows, but I have some suggestions:
I think Bozo's direction is the closet to the way we\ve done this in the code
base already. With a few points:
* I don't understand the need to undefine symbols - the windows header file
that defines them shouldn't be included in any "include chain", and if it is
then that is a problem. The only files in our code base that should include
windows (or more broadly platform specific headers) is platform.c and c files
that are only compiled on specific platforms. None of the .h files should (need
to) include windows headers.
* The use of strncasecmp() should be abstracted the same way we've abstracted
snprintf() - by adding a definition to platform.h using some implementation
probably in platform.c or util.c
> Fix openssl.c build on windows
> ------------------------------
>
> Key: PROTON-660
> URL: https://issues.apache.org/jira/browse/PROTON-660
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Affects Versions: 0.8
> Environment: Windows 7, VS2013
> Reporter: Bozo Dragojevic
> Attachments: 0001-PROTON-660-Fix-openssl.c-build-on-windows.patch,
> 25_openssl_fix_for_windows_CMakeLists.patch,
> 25_openssl_fix_for_windows_data.h.patch,
> 25_openssl_fix_for_windows_platform.h.patch
>
>
> Compiled openssl-1.0.1i from source
> Proton finds it, but openssl.c does not compile without small adjustments.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
