autotools + libressl builds fail with: unknown type name 'uint32_t'

[vszakats]

I did this

LibreSSL publishes its own arc4random, which then gets detected by autotools
when building curl.

Then fails when compiling lib/rand.c:

../../lib/rand.c:37:1: error: unknown type name 'uint32_t'
   37 | uint32_t arc4random(void);
      | ^
1 error generated.

Probably caused by: 755ddbe #10672

I'm guessing autotools shouldn't detect HAVE_ARC4RANDOM when it's provided
not by the system, but by a library dependency (with its prototype also present
in that dependency's headers) (LibreSSL probably shouldn't publish such function
outside of its own namespace in the first place, but it does). If we want to use it
anyway, we should use a C89 type in our replacement prototype? Or, together with
HAVE_STDINT_H and after including stdint.h.

I expected the following

Successful build.

curl/libcurl version

8.5.0-DEV

operating system

any

[bagder]

Probably caused by: 755ddbe #10672

Actually, this is a gross overstep by libressl who is tainting the global namespace with this. This is entirely their fault. Their implementation should have a libressl-specific prefix.

[bagder]

But: we don't need arc4random when we have a TLS library to get random from. A work-around would then be to just skip the check for that function when libressl is used.

[botovq]

Actually, this is a gross overstep by libressl who is tainting the global namespace with this. This is entirely their fault. Their implementation should have a libressl-specific prefix.

Totally agreed. This was a historical leftover that was forgotten about and noticed too late to be fixed in 3.7. It was subsequently fixed in libressl/portable@54b31ce, so LibreSSL 3.8 and later should no longer have this problem.

[vszakats]

Thanks for jumping in @botovq.

I'm seeing this with LibreSSL 3.8.2.

The linked patch fixes this for shared libs, but when linking statically (like in this particular case), arc4random is still there. Renaming it to something like libressl_arc4random[_buf]() would avoid this issue fully I believe. (I can see other unprefixed function names as well, and I remember bumping into one of those in the past.)

[vszakats]

For ref, here is the fix for the similar issue mentioned above, in libssh2, with LibreSSL and explicit_bzero(): libssh2/libssh2@d4f58f0
This was fixed by adjusting an earlier commit that accidentally added the crypto lib while doing feature detections.