[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: spiped build issues on OS X
- To: Frederick Akalin <akalin@gmail.com>, spiped@tarsnap.com
- Subject: Re: spiped build issues on OS X
- From: Colin Percival <cperciva@tarsnap.com>
- Date: Sat, 30 Aug 2014 15:37:26 -0700
- In-reply-to: <CAC0aHXbphjmCdLm__=BkdkR7femTb+nKYNaByRYKn7cemrEB=Q@mail.gmail.com>
- References: <CAC0aHXbphjmCdLm__=BkdkR7femTb+nKYNaByRYKn7cemrEB=Q@mail.gmail.com>
Hi everybody,
On 08/30/14 14:04, Frederick Akalin wrote:
> I ran into a few issues when trying to build spiped from trunk on OS
> X. Colin mentioned that the Makefiles from the SVN tree were for his
> own use and would probably not work on anything other than FreeBSD,
> but the issues I ran into are inherently interesting and may be worth
> fixing anyway. (And also may be useful for other people trying to get
> a development environment set up on non-FreeBSD platforms.)
>
> I ended up trying to get 'bsdmake -f Makefile.POSIX' to work. Both
> Makefile and Makefile.POSIX recurse into spipe/ and spiped/, and the
> Makefiles in those directories assume bsdmake, but using
> Makefile.POSIX leverages the existing code to detect the POSIX
> failures.
Oh wow. I'm surprised this didn't go even worse. The Makefiles in the
individual spipe and spiped directories aren't designed to be used with
Makefile.POSIX...
> ../libcperciva/datastruct/ptrheap.c:7:1: error: unused function
> 'ptrlist_resize' [-Werror,-Wunused-function]
> ELASTICARRAY_DECL(PTRLIST, ptrlist, void *);
> ^
> ../libcperciva/datastruct/elasticarray.h:114:2: note: expanded from macro
> 'ELASTICARRAY_DECL'
> prefix##_resize(struct prefix##_struct * EA, size_t nrec) \
> ^
> <scratch space>:101:1: note: expanded from here
> ptrlist_resize
>
> (BTW, the long list of warning flags comes from bsd.sys.mk.)
>
> This seems like a legit warning
Well... sort of. Yes, it is true that ptrlist_resize is unused. On the other
hand, it is declared as inline, and "declare lots of inline functions in a
header" is a very common idiom.
> not sure why it's not firing on
> FreeBSD. Here's OS X 10.9.4 + XCode 5.1.1's compiler:
>
> $ cc --version
> Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
> Target: x86_64-apple-darwin13.3.0
> Thread model: posix
Ah, I'm using clang 3.3 on my development box; clang34 does indeed produce
this warning on FreeBSD. Interestingly the warning does not show up when
compiling code which includes sysendian.h, which also has lots of static
inline functions which are mostly unused... I'll see if I can find some
clang people to explain what's going on here.
> That's easily worked around by appending -Wno-unused-function to
> CFLAGS. A better solution might be to avoid defining that function
> unless needed, but that is a bit ugly since it would involve defining
> two ELASTICARRAY_DECL macros.
Or in the extreme case, 512 macros, for each subset of the 9 inline
functions which may or may not be used by a particular module...
> In file included from ../libcperciva/util/asprintf.c:2:
> In file included from /usr/include/stdio.h:71:
> /usr/include/sys/_types/_va_list.h:31:26: error: redefinition of typedef
> 'va_list' is a C11 feature [-Werror,-Wtypedef-redefinition]
I suppose technically this is true... but it's also a feature in C99 and
C89, so I have no idea where this complaint is coming from.
> typedef __darwin_va_list va_list;
> ^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.1/include/stdarg.h:30:27:
> note:
> previous definition is here
> typedef __builtin_va_list va_list;
> ^
> 1 error generated.
>
> This seems like just a problem with OS X's system headers. This is
> also easily worked around by appending -Wno-system-headers to CFLAGS
> (which is better than -Wno-typedef-redefinition, I think).
Either way, it's something very broken in either OS X or clang.
> The third problem is that CFLAGS_POSIX isn't used in
> spipe{,d}/Makefile. This is expected since those Makefiles are
> assuming FreeBSD. I just simply appended ${CFLAGS_POSIX} to CFLAGS.
Or more precisely, because those Makefiles aren't designed to be launched
by the code in Makefile.POSIX. ;-)
> ../libcperciva/crypto/crypto_aes.c:114:2: error: 'AES_set_encrypt_key' is
> deprecated: first deprecated in OS X 10.7
> [-Werror,-Wdeprecated-declarations]
> AES_set_encrypt_key(key, len * 8, kexp);
> ^
> /usr/include/openssl/aes.h:92:5: note: 'AES_set_encrypt_key' declared here
> int AES_set_encrypt_key(const unsigned char *userKey, const int bits,
> ^
>
> It looks like this is because libcrypto (i.e., OpenSSL) is entirely
> deprecated in OS X 10.7: see
> https://stackoverflow.com/questions/7475914/libcrypto-deprecated-on-mac-os-x-10-7-lion
> .
>
> In fact, it looks like libcrypto/OpenSSL on OS X is stuck on an old version:
>
> $ openssl version
> OpenSSL 0.9.8y 5 Feb 2013
>
> (As an aside, I believe this version doesn't have Heartbleed.)
Correct.
> I'm not sure this is an actual problem, but it might be better to have
> the Homebrew spiped use Homebrew's OpenSSL (1.0.1i) instead. Colin, do
> you think this is worth doing?
It certainly can't hurt to use a supported version of OpenSSL.
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid