-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Regression: MBEDTLS_THREADING_ALT defined, but not all prerequisites #390
Comments
ARM Internal Ref: IOTSSL-597 |
This is weird.
As you can see, it's commented out. Did you run any other Make target |
https://kojipkgs.fedoraproject.org//work/tasks/7643/12487643/build.log is the complete build log. We are basically running:
|
Ok, the issue is you can't use |
But we are using the same build command on Fedora and it works fine? The source RPM for RHEL 5, 6 and 7 is exactly the same as for Fedora. |
Well, the issue with |
@mpg Overall, I think it's not the best solution to build with make -j1. Maybe you can revert these apidoc changes? Especially with a minor version like 2.2.1. |
The cause of this happing on RHEL only is definitely an old version of CMake. I tried with CMake 3.4 and 2.8.9 (easiest to get on Debian). CMake 3.4 inserts a |
@mortenstevens Yes, as I was saying in #391, I think I'll revert that change, I failed to anticipate that it would break parallel builds with multiple targets, and I think that's a good enough reason to revert it. However, as there are at least two workarounds (using |
This partially reverts 1989caf (only the changes to Makefile and CMakeLists, the addition to scripts/config.pl is kept). Modifying config.h in the apidoc target creates a race condition with make -j4 all apidoc where some parts of the library, tests or programs could be built with the wrong config.h, resulting in all kinds of (semi-random) errors. Recent versions of CMake mitigate this by adding a .NOTPARALLEL target to the generated Makefile, but people would still get errors with older CMake versions that are still in use (eg in RHEL 5), and with plain make. An additional issue is that, by failing to use cp -p, the apidoc target was updating the timestamp on config.h, which seems to cause further build issues. Let's get back to the previous, safe, situation. The improved apidoc building will be resurrected in a script in the next commit. fixes Mbed-TLS#390 fixes Mbed-TLS#391
…alpn_compile_error Fix compiler error when ALPN is enabled in server.
bitvector of length zero is not valid
Since mbedtls 2.2.1, building fails on RHEL 7, 6 and 5 like this (all architectures):
Note that mbedtls 2.2.0 was building fine on RHEL 7, 6 and 5 on all architectures.
The text was updated successfully, but these errors were encountered: