Skip to content
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.

Sign up for GitHub

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

Jump to bottom

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

Closed
vszakats opened this issue Nov 3, 2023 · 5 comments
Closed

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

vszakats opened this issue Nov 3, 2023 · 5 comments
Labels
build regression

Comments

@vszakats
Copy link
Member

vszakats commented Nov 3, 2023 •
edited

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
Copy link
Member

bagder commented Nov 3, 2023

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
Copy link
Member

bagder commented Nov 3, 2023

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
Copy link

botovq commented Nov 3, 2023

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
Copy link
Member Author

vszakats commented Nov 3, 2023

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.)

@botovq botovq mentioned this issue Nov 3, 2023
Open
@vszakats
Copy link
Member Author

vszakats commented Nov 4, 2023

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.

vszakats added a commit to curl/curl-for-win that referenced this issue Nov 5, 2023
@vszakats
curl-autotools.sh: workaround for arc4random + LibreSSL build bug [ci…
1ae9fb2 
… skip]

curl/curl#12257
libressl/portable#928
vszakats added a commit to vszakats/curl that referenced this issue Nov 5, 2023
@vszakats
rand: fix build error with autotools + LibreSSL
35ee47e 
autotools unexpectedly detects `arc4random` because it is also looking
into dependency libs. One dependency, LibreSSL, happens to publish an
`arc4random` function (via its shared lib before v3.7, also via static
lib as of v3.8.2). When trying to use this function in `lib/rand.c`,
its protoype is missing. To fix that, curl included a prototype, but
that used a C99 type without including `stdint.h`, causing:

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

This patch improves this by dropping the local prototype and instead
limiting `arc4random` use for non-OpenSSL builds. OpenSSL builds provide
their own random source anyway.

The better fix would be to teach autotools to not link dependency libs
while detecting `arc4random`.

LibreSSL publishing a non-namespaced `arc4random` tracked here:
libressl/portable#928

Regression from 755ddbe curl#10672

Fixes curl#12257
Closes #xxxxx
@vszakats vszakats mentioned this issue Nov 5, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
build regression
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

rand: fix build error with autotools + LibreSSL vszakats/curl
3 participants
@bagder @vszakats @botovq