libtom / libtomcrypt

LibTomCrypt is a fairly comprehensive, modular and portable cryptographic toolkit that provides developers with a vast array of well known published block ciphers, one-way hash functions, chaining modes, pseudo-random number generators, public key cryptography and a plethora of other routines.
https://www.libtom.net
Other
1.55k stars 457 forks source link

reported build issues with mac os 10.12.6 #338

Open rofl0r opened 6 years ago

rofl0r commented 6 years ago

pixiewps user @DJDan reported the following issues:

n file included from src/crypto/tc/tomcrypt.h:82:
src/crypto/tc/tomcrypt_cfg.h:203:31: warning: redefinition of typedef 'ulong64' is a C11 feature
      [-Wtypedef-redefinition]
   typedef unsigned long long ulong64;
                              ^
src/crypto/tfm/tfm.h:276:31: note: previous definition is here
   typedef unsigned long long ulong64;
                              ^

seems both tomsfastmath and libtomcrypt typedef ulong64, which is not quite conforming. maybe it'd be a good idea to add a #define ULONG64_DEFINED and only do the typedef if it wasnt defined already.

In file included from src/crypto/tc/tomcrypt_argchk.h:14:
/usr/include/signal.h:69:42: error: use of undeclared identifier 'NSIG'
extern __const char *__const sys_signame[NSIG];
                                         ^
/usr/include/signal.h:70:42: error: use of undeclared identifier 'NSIG'
extern __const char *__const sys_siglist[NSIG];
                                         ^

i just added tomcrypt this week, so we're using the latest bleeding edge sources of both tfm and tc.

sjaeckel commented 6 years ago

seems both tomsfastmath and libtomcrypt typedef ulong64, which is not quite conforming. maybe it'd be a good idea to add a #define ULONG64_DEFINED and only do the typedef if it wasnt defined alrea

well I guess that's caused by an incomplete rip-apart of ltc normally either you use tfm and include tfm.h OR ltc+tfm and include tomcrypt.h which includes tfm.h which has the typedef protected by #ifndef CRYPT

regarding the signal.h error... that smells like an error in the toolchain to me... CMIIW

rofl0r commented 6 years ago

normally either you use tfm and include tfm.h OR ltc+tfm and include tomcrypt.h which includes tfm.h which has the typedef protected by #ifndef CRYPT

i see

regarding the signal.h error... that smells like an error in the toolchain to me... CMIIW

from what i've heard you would need to define #define _DARWIN_C_SOURCE to get NSIG for some reason, but as i do not have access to a mac, i can't tell for sure.

sjaeckel commented 6 years ago

... but as i do not have access to a mac, i can't tell for sure

...neither do I.

@wiire-a you gave a :+1: to the issue, can you please elaborate on what we can/should do?

wiire-a commented 6 years ago

The issue was reported to me by @rofl0r after he integrated tomcrypt e tomsfastmath. It was a quick job so we probably missed the correct way of doing things.

Later I just pushed some quick changes to fix all the issues / warnings:

https://github.com/wiire-a/pixiewps/commit/65dd9975da8c22d14e495183af5ee35425b213a2

https://github.com/wiire-a/pixiewps/commit/61e73e570312370ed8ca43c3b32cf89fa54e19ab https://github.com/wiire-a/pixiewps/commit/c14f1227af347fbdd2f190f83e4a26a1abf0abed

Other minor issues (tomsfastmath):

https://github.com/wiire-a/pixiewps/commit/d6de90fb181b8b8d0c6760d15be6835ead035e5b

https://github.com/wiire-a/pixiewps/blob/master/src/crypto/tfm/tfm.h#L19

The NSIG issue might be due to the fact that we define _POSIX_C_SOURCE ?

From Apple's signal.h:

#if !defined(_ANSI_SOURCE) && (!defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE))
#define NSIG    __DARWIN_NSIG
#endif

But I don't have a Mac either and I never used tomcrypt and tomsfastmath before so I'm not sure what the best strategy is in that regard.