Hi, I got this report about the build process of openssh portable only checking if arc4random_buf links, not if it is declared in a header. It should probably ensure that the function exists in a header and set the local compatibility header define appropriately. https://github.com/libressl-portable/portable/issues/109 Thanks!
So libressl implements this but doesn't provide a prototype for it? IMO that's broken - it should use symbol visibility to hide functions that it uses internally but doesn't intend to provide to library users.
We could perhaps conditionally provide a prototype, but it would be in a nonstandard location. It would be better if programs did not have to guess whether arc4random_buf is in stdlib.h or some random libressl header, no? In other words, even if we did expose the prototype, I believe openssh would still have to do a header check to see if it is stdlib.h or elsewhere. The symbol export is intentional, as the arc4random_buf in libcrypto then shared between libssl, openssl(1) and libtls.
I was wondering why this was causing problems at all - normally we wouldn't pick up these symbols from libcrypto because most library tests are done only against libc. So I checked this history to see why these were done late: > commit 00f9cd230709c04399ef5ff80492d70a55230694 > Author: Damien Miller <djm@mindrot.org> > Date: Tue Jul 15 10:41:38 2014 +1000 > > - (djm) [configure.ac] Delay checks for arc4random* until after libcrypto > has been located; fixes builds agains libressl-portable So this used to work. What changed? IMO if you're going to provide replacements for functions usually in libc, then you should provide prototypes for them too. You can't expect programs to pick up your symbols but provide their own prototypes - what if your prototype doesn't match ours?
Created attachment 2721 [details] unconditionally define prototypes for libressl
Created attachment 2722 [details] fixed diff
could you please try the patch on this bug and see if it fixes things for you?