linux, openssl: where is THIRTY_TWO_BIT defined? - c++

I can't compile the openssl headers for c++ on Angstrom distribution, arm core. The file "bn.h" in openssl needs some extra definitions. One of them is THIRTY_TWO_BIT. I don't want to define it manually cause I may dismiss some other defines.
What header files should I include to have the THIRTY_TWO_BIT defined and openssl headers compiled as a result?

Googling for #define THIRTY_TWO_BIT yields the result that opensslconf.h seems to define THIRTY_TWO_BIT, see Apples codebase here

where is THIRTY_TWO_BIT defined?
Its defined by Configure based on the platform:
$ cd <openssl src dir>
$ grep -R THIRTY_TWO_BIT *
...
Configure:"BS2000-OSD","c89:-O -XLLML -XLLMK -XL -DB_ENDIAN -DTERMIOS -DCHARSET_EBCDIC::(unknown)::-lsocket -lnsl:THIRTY_TWO_BIT DES_PTR DES_UNROLL MD2_CHAR RC4_INDEX RC4_CHAR BF_PTR:::",
Configure:"OS390-Unix","c89.sh:-O -DB_ENDIAN -DCHARSET_EBCDIC -DNO_SYS_PARAM_H -D_ALL_SOURCE::(unknown):::THIRTY_TWO_BIT DES_PTR DES_UNROLL MD2_CHAR RC4_INDEX RC4_CHAR BF_PTR:::",
Configure:"tandem-c89","c89:-Ww -D__TANDEM -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED=1 -D_TANDEM_SOURCE -DB_ENDIAN::(unknown):::THIRTY_TWO_BIT:::",
...
Its used in other files, and available in opensslconf.h if it was defined during configure (as Uli pointed out):
...
crypto/opensslconf.h.in:#define THIRTY_TWO_BIT
crypto/bn/bn_lib.c:#if defined(THIRTY_TWO_BIT) || defined(SIXTY_FOUR_BIT) || defined(SIXTY_FOUR_BIT_LONG)
crypto/bn/bn_lib.c:#if defined(THIRTY_TWO_BIT) || defined(SIXTY_FOUR_BIT) || defined(SIXTY_FOUR_BIT_LONG)
crypto/bn/bn_gf2m.c:#ifdef THIRTY_TWO_BIT
crypto/bn/bn_gf2m.c:#ifdef THIRTY_TWO_BIT
crypto/bn/bn.h:#ifdef THIRTY_TWO_BIT
MacOS/opensslconf.h:#define THIRTY_TWO_BIT
I can't compile the openssl headers for c++ on Angstrom distribution, arm core. The file "bn.h" in openssl needs some extra definitions.
You might check in Configure for a similar platform, and then copy/add/modify it for your platform. Then, run ./Configure <your new platform> followed by a make all.
Your platform may already be available. There is no Angstrom, but there are ARM's available:
$ ./Configure
Usage: Configure [no-<cipher> ...] [enable-<cipher> ...] [experimental-<cipher> ...]
[-Dxxx] [-lxxx] [-Lxxx] [-fxxx] [-Kxxx] [no-hw-xxx|no-hw] [[no-]threads] [[no-]shared]
[[no-]zlib|zlib-dynamic] [no-asm] [no-dso] [no-krb5] [sctp] [386] [--prefix=DIR]
[--openssldir=OPENSSLDIR] [--with-xxx[=vvv]] [--test-sanity] os/compiler[:flags]
pick os/compiler from:
BC-32 BS2000-OSD BSD-generic32 BSD-generic64 BSD-ia64 BSD-sparc64 BSD-sparcv8
BSD-x86 BSD-x86-elf BSD-x86_64 Cygwin Cygwin-pre1.3 DJGPP MPE/iX-gcc OS2-EMX
OS390-Unix QNX6 QNX6-i386 ReliantUNIX SINIX SINIX-N UWIN VC-CE VC-WIN32
VC-WIN64A VC-WIN64I aix-cc aix-gcc aix3-cc aix64-cc aix64-gcc android
android-armv7 android-x86 aux3-gcc beos-x86-bone beos-x86-r5 bsdi-elf-gcc cc
cray-j90 cray-t3e darwin-i386-cc darwin-ppc-cc darwin64-ppc-cc
darwin64-x86_64-cc dgux-R3-gcc dgux-R4-gcc dgux-R4-x86-gcc dist gcc hpux-cc
hpux-gcc hpux-ia64-cc hpux-ia64-gcc hpux-parisc-cc hpux-parisc-cc-o4
hpux-parisc-gcc hpux-parisc1_1-cc hpux-parisc1_1-gcc hpux-parisc2-cc
hpux-parisc2-gcc hpux64-ia64-cc hpux64-ia64-gcc hpux64-parisc2-cc
hpux64-parisc2-gcc hurd-x86 iphoneos-cross irix-cc irix-gcc irix-mips3-cc
irix-mips3-gcc irix64-mips4-cc irix64-mips4-gcc linux-alpha+bwx-ccc
linux-alpha+bwx-gcc linux-alpha-ccc linux-alpha-gcc linux-aout linux-armv4
linux-elf linux-generic32 linux-generic64 linux-ia32-icc linux-ia64
linux-ia64-ecc linux-ia64-icc linux-ppc linux-ppc64 linux-sparcv8
linux-sparcv9 linux-x86_64 linux32-s390x linux64-s390x linux64-sparcv9 mingw
mingw64 ncr-scde netware-clib netware-clib-bsdsock netware-clib-bsdsock-gcc
netware-clib-gcc netware-libc netware-libc-bsdsock netware-libc-bsdsock-gcc
netware-libc-gcc newsos4-gcc nextstep nextstep3.3 osf1-alpha-cc osf1-alpha-gcc
purify qnx4 rhapsody-ppc-cc sco5-cc sco5-gcc solaris-sparcv7-cc
solaris-sparcv7-gcc solaris-sparcv8-cc solaris-sparcv8-gcc solaris-sparcv9-cc
solaris-sparcv9-gcc solaris-x86-cc solaris-x86-gcc solaris64-sparcv9-cc
solaris64-sparcv9-gcc solaris64-x86_64-cc solaris64-x86_64-gcc sunos-gcc
tandem-c89 tru64-alpha-cc uClinux-dist uClinux-dist64 ultrix-cc ultrix-gcc
unixware-2.0 unixware-2.1 unixware-7 unixware-7-gcc vos-gcc vxworks-mips
vxworks-ppc405 vxworks-ppc60x vxworks-ppc750 vxworks-ppc750-debug
vxworks-ppc860 vxworks-ppcgen vxworks-simlinux ...

Related

Breakpad Client not generated when cross-compiling

I'm trying to cross-compile Google Breakpad. I'm executing the following commands:
$ ./configure --prefix=/opt/breakpad CFLAGS="-Os" CC=PATH_ARM_COMPILER/arm-linux-gcc CXX=PATH_ARM_COMPILER/arm-linux-g++ --host=arm
$ make
$ make install
It generates and installs some files in the prefix path. In the include path it has:
|-common
|-google_breakpad
|-processor
but it should has:
|-client
|-common
|-google_breakpad
|-processor
|-third_party
It seems to be a problem related to Breakpad client. What should be the right way to cross-compile Breakpad?
My host is a Ubuntu 18.04 x86-64, target ARM-32.
I have reproduced your problem on my side. In fact, the issue is related to --host compilation flag.
Breakpad documentation shows that:
when building on Linux it will also build the client libraries.
So, In order to get the client binaries and headers, you should use the correct compiler prefix.
For example if you are using the GNU cross compiler arm-linux-gnueabihf-gcc, the --host flag value should be arm-linux-gnueabihf.
In your case (arm-linux-gcc) try to change your configure command as following:
./configure --prefix=/opt/breakpad CFLAGS="-Os" CC=PATH_ARM_COMPILER/arm-linux-gcc CXX=PATH_ARM_COMPILER/arm-linux-g++ --host=arm-linux

Openssl, arm, windows, msys2, dirent.h

I am trying to build a windows openssl library for a rasbery pi pico microcontroller, with an arm cortex m0 processor.
I downloaded the openssl library from the official site and unzipped it. Installed MSYS2 and launched it. It indicated the path to the directory with the openssl library:
cd /C/openssl-3.0.0-beta1
Selected settings for the config file:
./Configure gcc --cross-compile-prefix=arm-none-eabi- --prefix=/K/OpenSSL-x32-arm -mcpu=cortex-m0plus PROCESSOR=ARM -DL_ENDIAN no-shared -DNO_SYSLOG -DOPENSSL_NO_X509 -DOPENSSL_NO_X509V3 -DOPENSSL_NO_X509_VFY no-idea no-camellia no-seed no-bf no-cast no-des no-rc4 no-rc5 no-md2 no-md4 no-ripemd no-mdc2 no-dsa no-dh no-ec no-ecdsa no-ecdh no-sock no-ssl2 no-ssl3 no-err no-engine no-hw
and started compiling:
make depend && make
it throws an error:
In file included from c:\msys64\mingw64\arm-none-eabi\include\dirent.h:39,
from crypto/LPdir_unix.c:44,
from crypto/o_dir.c:28:
c:\msys64\mingw64\arm-none-eabi\include\sys\dirent.h:10:2: error: #error "<dirent.h> not supported"
10 | #error "<dirent.h> not supported"
What am I doing wrong?
The raspberry pi pico does not actually have a filesystem, so it does not support file operations. Furthermore, it only has 246kb of programmable memory. Are you sure you want to blow it all on OpenSSL? There are far smaller TLS stacks such as Mbed-TLS (<30kb) and WolfSSL (<100kb).

How to install GMP Mp on windows? (C++)

I've followed every single guide I could possibly find but to be completely honest I have no idea what some installation 'steps' even mean.
I tried installing Cygwin (and MYSY) and running the commands that the guides told me to, but the terminal either doesn't do anything or it gives me the error: 'no such file or directory'. (I changed the folder directory to where my files where)
Also I'm not entirely sure I installed everything correctly because I should've checked some add-ons during the installation right? I did as in the guide but still I maybe missed something...
Could someone please explain to me step by step how to install it saying explicitly all that has to be done, (I'm running windows 7) considering It's the first time I do such thing and I have no idea what ./configure , make and all the other commands even mean...
The following is a simple step by step using only cygwin tools.
To compile C++ we need the g++ compiler; to locate the correct package to be installed the cygwin tool is cygcheck (that is installed by default), with the -p switch it interrogates the database at https://cygwin.com/packages/:
$ cygcheck -p bin/g++
Found 3 matches for bin/g++
gcc-g++-7.3.0-1 - gcc-g++: GNU Compiler Collection (C++)
gcc-g++-7.3.0-2 - gcc-g++: GNU Compiler Collection (C++)
gcc-g++-7.3.0-3 - gcc-g++: GNU Compiler Collection (C++)
so we need the gcc-g++ package.
To install it, we run the cygwin setup, select the Full view, search the gcc-g to filter the thousands of packages and click on skip at the gcc-g++ row
after complety the installation, to verify we have it correctly installed:
$ cygcheck -c gcc-g++
Cygwin Package Information
Package Version Status
gcc-g++ 7.3.0-3 OK
Installing gcc-g++ will pull also the installation of the C compiler package gcc-core.
To compile a gmp program we need the proper header and shared library; that are usually included in a "*-devel" package:
$ cygcheck -p include/gmpxx.h
Found 9 matches for include/gmpxx.h
libgmp-devel-6.1.0-3p1 - libgmp-devel: Library for arbitrary precision arithmetic (development) (installed binaries and support files)
libgmp-devel-6.1.1-1 - libgmp-devel: Library for arbitrary precision arithmetic (development) (installed binaries and support files)
libgmp-devel-6.1.2-1 - libgmp-devel: Library for arbitrary precision arithmetic (development)
mingw64-i686-gmp-6.0.0a-2 - mingw64-i686-gmp: Multiple Precision arithmetic library for Win32 toolchain (installed binaries and support files)
...
All the packages with mingw64 are for cross compiling and we can ignore, so it is libgmp-devel. Verifying that is properly installed
$ cygcheck -c libgmp-devel
Cygwin Package Information
Package Version Status
libgmp-devel 6.1.2-1 OK
And the package content is the header files and the import libraries
$ cygcheck -l libgmp-devel
/usr/include/gmp.h
/usr/include/gmpxx.h
/usr/lib/libgmp.dll.a
/usr/lib/libgmpxx.dll.a
Now we can program one example, I am taking it from
https://gmplib.org/manual/C_002b_002b-Interface-General.html
and written in a file called mpz_add.cpp
You can use whatever editor you want. The important is that the file follows
the Unix line termination standard LF and not the Windows CR+LF (see note below if not)
$ file mpz_add.cpp
mpz_add.cpp: C++ source, ASCII text
$ cat mpz_add.cpp
#include <gmpxx.h>
#include <iostream>
using namespace std;
int main (void)
{
mpz_class a, b, c;
a = 1234;
b = "-5678";
c = a+b;
cout << "sum is " << c << "\n";
cout << "absolute value is " << abs(c) << "\n";
return 0;
}
To compile our example and test it:
$ g++ mpz_add.cpp -lgmpxx -lgmp -o mpz_add
$ ./mpz_add
sum is -4444
absolute value is 4444
We can also verify which library are linked in the program mpz_add, I added some extra comment:
$ cygcheck ./mpz_add
D:\cyg_pub\tmp\gmp\mpz_add.exe
D:\cygwin64\bin\cygwin1.dll <= cygwin library
C:\WINDOWS\system32\KERNEL32.dll <= windows system library
C:\WINDOWS\system32\ntdll.dll ...
C:\WINDOWS\system32\KERNELBASE.dll ...
D:\cygwin64\bin\cyggmp-10.dll <= GMP C library
D:\cygwin64\bin\cyggmpxx-4.dll <= GMP C++ library
D:\cygwin64\bin\cyggcc_s-seh-1.dll <= C library
D:\cygwin64\bin\cygstdc++-6.dll <= C++ library
If the file has the wrong line termination, the best tool is d2u (Dos to Unix)
$ cygcheck -p bin/d2u
Found 6 matches for bin/d2u
...
dos2unix-7.4.0-1 - dos2unix: Line Break Conversion
$ file mpz_add.cpp
mpz_add.cpp: C++ source, ASCII text, with CRLF line terminators
$ d2u mpz_add.cpp
dos2unix: converting file mpz_add.cpp to Unix format...
$ file mpz_add.cpp
mpz_add.cpp: C++ source, ASCII text
As you added also the tag makefile and autotools, the first is in the package make:
$ cygcheck -p bin/make.exe
Found 6 matches for bin/make.exe
..
make-4.2.1-2 - make: The GNU version of the 'make' utility
The second is more complex and you need the packages autoconf automake and libtool,

C/C++ Cyanogenmod How to compile kernel using different version of toolchain?

I am trying to compile kernel for Cyanogenmod 13. I am getting error
ERROR: modpost: Found 2 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
To build the kernel despite the mismatches, build with:
'make CONFIG_NO_ERROR_ON_MISMATCH=y'
(NOTE: This is not recommended)
I read it here. That i need to compile my kernel using 4.7.
How can i choose the version of toolchain during cyanogenmod build ??
I believe you need to setup gcc version 4.7 and use CC variable to set it as a compiler. E.g. make target CC=/bin/gcc4.7
More information here and here.
Thanks to #nopasara and his valuable comment.
So i did little research further and discovered that the kernel is compatiable with arm-eabi tool chain not arm-linux-androideabi toolchain. So here is the command i used
export PATH=$PATH:~/android/system/prebuilts/gcc/linux-x86/arm/arm-linux-eabi-4.7/bin/ && export ARCH=arm && export SUBARCH=arm && export CROSS_COMPILE=arm-linux-eabi- && make msm8226_defconfig O=~/android/system/out/target/product/E6790/obj/KERNEL_OBJ
and
make O=~/android/system/out/target/product/E6790/obj/KERNEL_OBJ zImage -j4
To do with this Cyanogenmod add following line to your BoardConfig.mk
TARGET_KERNEL_CROSS_COMPILE_PREFIX := arm-eabi-
and either use
export TARGET_LEGACY_GCC_VERSION=4.7
Or edit ~/android/system/build/core/combo/TARGET_linux-arm.mk and set version in
$(combo_2nd_arch_prefix)TARGET_LEGACY_GCC_VERSION := 4.7

Is there a header identifying SunOS/Solaris version at compile time?

I am trying to detect Solaris/SunOS version at compile time so that I can enable/disable use of port_create() and other APIs.
Is there a header identifying SunOS/Solaris version at compile time?
If no header is giving you this information, you could of course parse the output of uname and generate -D preprocessor option(s) from your build script/makefile/...
Elaborating upon the suggestion by #meaning-matters, one can make a compile-time definition, say SUN_VERSION using the output of uname -r. That actually gives a floating point number, e.g., 5.10, which you could convert into a preprocessor-comparable form using a simple sed command, e.g., this compiler option:
-DSUN_VERSION=`uname -r | sed -e 's/\.\([0-9]\{1,1\}\)$/0\1/' -e 's/\.//'`
produces 510 for 5.10, 509 for 5.9, etc.
In your source program, you could use it like this
#if SUN_VERSION >= 510
(or whatever makes sense).
Identifying the OS release in order to assert an API is available or not is risky if not doomed. You cannot assume an API will stay in future releases nor if it is available in a parallel branch (eg. Illumos vs Solaris 11 which are both reporting SunOS 5.11 as their version).
The usual way to overcome this issue is simply to check if the API is available by compiling a small test source code to figure it out. This is usually done in a script traditionally named configure that builds a Makefile and an include file tailored to your system.
To expand upon #meaning-matters answer, use GNU make, and set a variable to the OS version. Pass that variable on to the compiler using the -D command-line option.
Makefile:
OS_VERSION := $(shell uname -r)
version:
$(CC) -DOS_VERSION=$(OS_VERSION) version.c -o version
test:
echo $(OS_VERSION)
version.c:
#include <stdio.h>
#define STRINGIFY(x) #x
#define TOSTRING(x) STRINGIFY(x)
int main()
{
printf( "OS Version: " TOSTRING(OS_VERSION) "\n" );
return( 0 );
}
Output:
bash 4.1$ gmake test
echo 5.11
5.11
bash 4.1$ gmake version
cc -DOS_VERSION=5.11 version.c -o version
bash 4.1$ ./version
OS Version: 5.11
bash 4.1$
Use := (assign if not already set) to only run the uname command once.
That will show "5.10" for Solaris 10, "5.11" for Solaris 11.