Don't know about crypto. But any open source package, ported to a new environment (one not explicitly tested by the maintainter) is going to have issues. That's

Don't know about crypto. But any open source package, ported to a new environment (one not explicitly tested by the maintainter) is going to have issues. That's the nature of software. E.g. I just added pnglib to an embedded assembly. Has a display among other things. Wanted to put compressed PNG images into (limited) flash, then decompress into (plentiful) RAM at boot. Of course pnglib didn't build for my environment. Never mind it has a C library. There are 50+ compile switches in pnglib, and I was setting them in a pattern that wasn't part of the tested configurations. It didn't even compile. Once it compiled (after some source changes) it didn't run. More source changes and it would run until it hit some endianness issues. Fix those, and it would do (just) what I wanted, which was to decompress certain PNG image formats with limited features, once. No problem. That was my goal, achieved. But at no time did I blame the maintainers for not anticipating my use case. I would say this: maintainers, flag compile-time options that aren't tried both ways in your test environments. To give me some chance of estimating how hard my job is going to be.