Conan-center-index: [package] zlib/1.2.11: crypt.h is in the include directory leading to problems

[jmarrec]

A zlib internal-only header is installed at ~/.conan/data/zlib/1.2.11/_/_/package/<SHA>/include/crypt.h, which is making my build fail when trying to link against python as Python.h is expecting the system crypt(3) at /usr/lib/crypt.h but finding the zlib one due to -isystem~/.conan/data/zlib/1.2.11/_/_/package//include`

A similar PR is reported upstream FYI (https://github.com/madler/zlib/pull/229), and is used by official linux distributions for sure, but that concerns the Makefile, whereas the conan zlib is also defining the headers independently:

https://github.com/conan-io/conan-center-index/blob/da4c194576212941e63c8de3a81fa07eb02855e1/recipes/zlib/1.2.11/CMakeLists_minizip.txt#L8

https://github.com/conan-io/conan-center-index/blob/da4c194576212941e63c8de3a81fa07eb02855e1/recipes/zlib/1.2.11/CMakeLists_minizip.txt#L40

Package and Environment Details (include every applicable attribute)

• Package Name/Version: zlib/1.2.11
• Operating System+version: Linux Ubuntu 18.04
• Compiler+version: GCC 7
• Conan version: conan 1.24.1
• Python version: Python 3.8.0

Conan profile (output of conan profile show default or conan profile show <profile> if custom profile is in use)

Put your profile output here

Steps to reproduce (Include if Applicable)

Logs (Include/Attach if Applicable)

Click to expand log

Put your log output here

[SSE4]

yeah, I think we already run into this several times in the past. this is a general problem with non-namespaced C-style headers. I'd wish we had #include <openssl/crypto.h> and #include <zlib/crypto.h> instead of just #include <crypto.h>. otherwise, I am not sure how to deal with such situations.

[jmarrec]

@SSE4 yes ideally that would be the case upstream, with namespaces. Otherwise that can be patched in conan, but that's annoying for sure to maintain.

As for this specific issue, I'm proposing a fix in #1526

[prince-chrismc]

@jmarrec if you could edit ur PR's opening comment with "fixes #1525" so this issue will automatic close, that would be greatly appreciated!

[jmarrec]

@jmarrec if you could edit ur PR's opening comment with "fixes #1525" so this issue will automatic close, that would be greatly appreciated!

Done, it was missing the # in the issue number...