cipher-aes tries to use aesni when it is not supported

[jsw-fnal]

When installing cipher-aes with cabal, I get a ton of error messages that various assembler instructions do not exist. This is because the system I am on, an older Xeon, does not support the AESNI instruction set.

When I look in cipher-aes.cabal, it appears that AESNI instructions are used whenever the OS is linux and we're on an x86 or x86_64 architecture. But, for CPUs older than AESNI, this won't work.

[jsw-fnal]

I guess I don't understand cabal: when I edited cipher-aes.cabal to remove -DWITH_AESNI, and tried again on the cabal install, nothing changed. So I #undef WITH_AESNI and #undef USE_AESNI throughout the C code. After that, cabal install cipher-aes seems to have succeeded. I just hope I didn't break anything, and that pandoc will work in the end.

[watercrossing]

I had the same issue, my Xeon L5609 does not support the AESNI instruction set either. However removing -DWITH_AESNI did help - could it be, @jsw-fnal, that instead of building from the unpacked directory with cabal build you did cabal install cipher-aes again?

[TomMD]

I'm curious if the cipher-aes128 package's install-time checks work on your system. Are either of you willing to check?

It's a rather similar package as cipher-aes (using all of Vincent's AES C code, thank you Vincent) but is centered around the crypto-api interface and has a more functional GCM API that divides out the mutable and immutable data.

[jsw-fnal]

@TomMD, I think that, as part of my efforts to get pandoc installed, I did try installing cipher-aes128. As best as I recall, cipher-aes128 installation proceeded with no problems, but it didn't help with pandoc installation, so I didn't pursue it any further. (It is not clear to me why pandoc needs a crypto library in the first place. I can only think that there must be some unnecessary dependency somewhere.)

@watercrossing, I found the package tarball in ~/.cabal, unpacked it, modified the .cabal file, and then replaced the tarball with a new one. Then I tried cabal install cipher-aes again. Not really knowing exactly how cabal works, this was all unsuccessful guesswork. When I modified the C code to #undef WITH_AESNI, I did the same thing with the tarball and ran cabal install cipher-aes again. This worked. I don't know why one did and the other didn't.

[watercrossing]

@TomMD: I just tried installing it, and after resolving a long list of dependencies, it failed too with

[2 of 2] Compiling Crypto.Cipher.AES128 ( Crypto/Cipher/AES128.hs, dist/build/Crypto/Cipher/AES128.o )
/tmp/ghc23130_0/ghc23130_0.s: Assembler messages:

/tmp/ghc23130_0/ghc23130_0.s:209:0:
     Error: unknown .loc sub-directive `discriminator'

/tmp/ghc23130_0/ghc23130_0.s:209:0:
     Error: junk at end of line, first unrecognized character is `2'

/tmp/ghc23130_0/ghc23130_0.s:212:0:
     Error: unknown .loc sub-directive `discriminator'

with these messages repeated for a lot of different lines - and the install failed.

[vincenthz]

@jsw-fnal @watercrossing The cpu support has nothing to do with the compilation of the package; Whereas your cpu support AES-NI or not is not going to affect compilation. the key thing you need to look into is which compilation environment you have: operating system, compiler, etc. The main reason for the issue is that your system is still using a gcc < 4.4 (gcc 4.4 was out in 2009 btw...)

@jsw-fnal pandoc requires cipher-aes, since pandoc have https support (which in turn requires tls support)

[jsw-fnal]

@vincenthz, on the contrary, I have gcc 4.4.6.

[vincenthz]

@jsw-fnal I can't guess the issue you're having without seeing the log.

[jsw-fnal]

The log is now in a gist.

[vincenthz]

your binutils is too old. (edit: actually, probably not ld's fault, but some assembly binutils utils)

[jsw-fnal]

I can't update binutils (or gcc) on a system I don't own. It might be wise to detect too-old binutils/gcc and disable -DWITH_AESNI, or at least warn the user. But I have my workaround.

[vincenthz]

(I appreciate that's not an easy thing to upgrade btw)

I already push a way to disable it at the configure level (which I thought was already upstream), cabal configure --flag -support_aesni.

as to autoconfiguration, that's not going to happens sadly, as cabal doesn't support anything I'm comfortable using (like Setup.hs)

[jsw-fnal]

Ah! I think that actually works. My apologies for not realizing that the flag was there -- how should I (or others) discover similar flags in the future? Keep in mind my position as someone who knows practically nothing of Haskell or cabal; I just want to get pandoc running on my system.

[vincenthz]

I just pushed it just now, so the flag wasn't there 1h ago ;)

I really thought I pushed this flag months ago, but apparently I just imagined it. In general to find them just reading the cabal file or they appears on the package hackage's page nowadays too.

[jsw-fnal]

Many thanks for your assistance!