Are all ARMs created equal? - arm

I have a toolchain from an older piece of hardware (W315 from Moxa), and when I run file on its library files, I get this:
[bf#localhost arm-linux-gnueabi]$ file /usr/local/arm-linux/lib/libssl.so.0.9.8
/usr/local/arm-linux/lib/libssl.so.0.9.8: ELF 32-bit LSB shared object, ARM, version 1 (ARM), dynamically linked, not stripped
As you can see, this OpenSSL library is quite old and does not support TLSv1.2, which I need (at least). So I am trying to find an ARM binary of that library of a newer version. I have found 1.0.0 from Debian, but that has a little different signature:
[bf#localhost arm-linux-gnueabi]$ file libssl.so.1.0.0
libssl.so.1.0.0: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=83c83f5d3da36759c7adc837405b28539569d26e, stripped
They are both 32 bit, and ELF, but I am not sure if the "ARM" part is comparable.
Could I use that 1.0.0 library in my application? And if not, what should I look for in searching for the right binary?
Results from cat /proc/cpuinfo:
root#Moxa:/home/fabs# cat /proc/cpuinfo
Processor : ARM922Tid(wb) rev 1 (v4l)
BogoMIPS : 76.59
Features : swp half thumb
CPU implementer : 0x66
CPU architecture: 4
CPU variant : 0x0
CPU part : 0x526
CPU revision : 1
Cache type : VIVT write-back
Cache clean : cp15 c7 ops
Cache lockdown : format B
Cache format : Harvard
I size : 16384
I assoc : 2
I line length : 16
I sets : 512
D size : 16384
D assoc : 2
D line length : 16
D sets : 512
Hardware : Moxa CPU development platform
Revision : 0000
Serial : 0000000000000000

No, they are not. But You can build a recent/supported/secure version of openssl for your platform by using the following procedure:
# openssl
wget https://www.openssl.org/source/openssl-1.1.1k.tar.gz
tar zxf openssl-1.1.1k.tar.gz
# a toolchain I know is working for arm922t according to gcc documentation
wget "https://releases.linaro.org/components/toolchain/binaries/latest-6/arm-linux-gnueabi/gcc-linaro-6.4.1-2018.05-x86_64_arm-linux-gnueabi.tar.xz" -O gcc-linaro-6.4.1-2018.05-x86_64_arm-linux-gnueabi.tar.xz
mkdir -p /opt/arm/6
tar Jxf gcc-linaro-6.4.1-2018.05-x86_64_arm-linux-gnueabi.tar.xz -C /opt/arm/6
# building
cd openssl-1.1.1k
./Configure linux-generic32 --cross-compile-prefix=/opt/arm/6/gcc-linaro-6.4.1-2018.05-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi- --prefix=/opt/openssl-1.1.1k --openssldir=/opt/openssl-1.1.1k
Edit the Makefile, and replace
CFLAGS=-Wall -O3
by:
CFLAGS=-Wall -O3 -march=armv4t -mcpu=arm922t
Then:
make install
ls -gG /opt/openssl-1.1.1k/bin/
total 576
-rwxr-xr-x 1 6214 Jun 30 12:53 c_rehash
-rwxr-xr-x 1 579740 Jun 30 12:53 openssl
ls -gG /opt/openssl-1.1.1k/lib
total 6432
drwxr-xr-x 2 4096 Jun 30 12:53 engines-1.1
-rw-r--r-- 1 3312034 Jun 30 12:53 libcrypto.a
lrwxrwxrwx 1 16 Jun 30 12:53 libcrypto.so -> libcrypto.so.1.1
-rwxr-xr-x 1 2152072 Jun 30 12:53 libcrypto.so.1.1
-rw-r--r-- 1 603100 Jun 30 12:53 libssl.a
lrwxrwxrwx 1 13 Jun 30 12:53 libssl.so -> libssl.so.1.1
-rwxr-xr-x 1 502704 Jun 30 12:53 libssl.so.1
file /opt/openssl-1.1.1k/bin/openssl
/opt/openssl-1.1.1k/bin/openssl: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=7b0e69c478f4c7390d416247f95ac60d9a632bd8, with debug_info, not stripped
If needed, you can build a static version by adding the -static option at the end of the configuration command:
./Configure linux-generic32 --cross-compile-prefix=/opt/arm/6/gcc-linaro-6.4.1-2018.05-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi- --prefix=/opt/openssl-1.1.1k --openssldir=/opt/openssl-1.1.1k -static

Related

Issues cross compiling iptables for arm

I am trying to cross compile iptables for ARM. I have tried versions 1.6.1 and 1.8.5 and both have similiar problems. iptables has three dependencies, libmnl, libnftnl and libnfnetlink. I have ensured all these are cross compiled and available in these locations -
/home/badri/arm_libs/nftnl2
/home/badri/arm_libs/mnl
/home/badri/arm_libs/nfnetlink
I had a similiar problem yesterday and it was related to configure. But now i feel configure is done right, but don't know what the problem is. This similiar problem can be seen here -
Issues cross compiling libnftnl for arm
My configure for iptables is as below -
./configure --build=x86_64-pc-linux-gnu --host=aarch64-linux-gnu --enable-static=no --prefix=/home/badri/arm_libs/iptables2 libmnl_LIBS=-L/home/badri/arm_libs/mnl/lib libmnl_CFLAGS=-I/home/badri/arm_libs/mnl/include/ libnftnl_LIBS=-L/home/badri/arm_libs/nftnl2/lib/ libnftnl_CFLAGS=-I/home/badri/arm_libs/nftnl2/include libnfnetlink_LIBS=-L/home/badri/arm_libs/nfnetlink/lib libnfnetlink_CFLAGS=-I/home/badri/arm_libs/nfnetlink/include
configure is successful and make results in these errors. Has anyone faced this problem ?
/home/badri/Downloads/iptables-1.8.5/utils/nfnl_osf.c:381: undefined reference to `nfnl_fill_hdr'
/home/badri/Downloads/iptables-1.8.5/utils/nfnl_osf.c:387: undefined reference to `nfnl_addattr_l'
/home/badri/Downloads/iptables-1.8.5/utils/nfnl_osf.c:389: undefined reference to `nfnl_query'
/home/badri/Downloads/iptables-1.8.5/utils/nfnl_osf.c:384: undefined reference to `nfnl_fill_hdr'
/home/badri/Downloads/iptables-1.8.5/utils/nfnl_osf.c:387: undefined reference to `nfnl_addattr_l'
/home/badri/Downloads/iptables-1.8.5/utils/nfnl_osf.c:389: undefined reference to `nfnl_query'
./configure --help looks like this.
badri#badri-All-Series:~/Downloads/iptables-1.6.1$ ./configure --help
`configure' configures iptables 1.6.1 to adapt to many kinds of systems.
Usage: ./configure [OPTION]... [VAR=VALUE]...
To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE. See below for descriptions of some of the useful variables.
Defaults for the options are specified in brackets.
Configuration:
-h, --help display this help and exit
--help=short display options specific to this package
--help=recursive display the short help of all the included packages
-V, --version display version information and exit
-q, --quiet, --silent do not print `checking ...' messages
--cache-file=FILE cache test results in FILE [disabled]
-C, --config-cache alias for `--cache-file=config.cache'
-n, --no-create do not create output files
--srcdir=DIR find the sources in DIR [configure dir or `..']
Installation directories:
--prefix=PREFIX install architecture-independent files in PREFIX
[/usr/local]
--exec-prefix=EPREFIX install architecture-dependent files in EPREFIX
[PREFIX]
By default, `make install' will install all the files in
`/usr/local/bin', `/usr/local/lib' etc. You can specify
an installation prefix other than `/usr/local' using `--prefix',
for instance `--prefix=$HOME'.
For better control, use the options below.
Fine tuning of the installation directories:
--bindir=DIR user executables [EPREFIX/bin]
--sbindir=DIR system admin executables [EPREFIX/sbin]
--libexecdir=DIR program executables [EPREFIX/libexec]
--sysconfdir=DIR read-only single-machine data [PREFIX/etc]
--sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com]
--localstatedir=DIR modifiable single-machine data [PREFIX/var]
--libdir=DIR object code libraries [EPREFIX/lib]
--includedir=DIR C header files [PREFIX/include]
--oldincludedir=DIR C header files for non-gcc [/usr/include]
--datarootdir=DIR read-only arch.-independent data root [PREFIX/share]
--datadir=DIR read-only architecture-independent data [DATAROOTDIR]
--infodir=DIR info documentation [DATAROOTDIR/info]
--localedir=DIR locale-dependent data [DATAROOTDIR/locale]
--mandir=DIR man documentation [DATAROOTDIR/man]
--docdir=DIR documentation root [DATAROOTDIR/doc/iptables]
--htmldir=DIR html documentation [DOCDIR]
--dvidir=DIR dvi documentation [DOCDIR]
--pdfdir=DIR pdf documentation [DOCDIR]
--psdir=DIR ps documentation [DOCDIR]
Program names:
--program-prefix=PREFIX prepend PREFIX to installed program names
--program-suffix=SUFFIX append SUFFIX to installed program names
--program-transform-name=PROGRAM run sed PROGRAM on installed program names
System types:
--build=BUILD configure for building on BUILD [guessed]
--host=HOST cross-compile to build programs to run on HOST [BUILD]
Optional Features:
--disable-option-checking ignore unrecognized --enable/--with options
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]
--enable-silent-rules less verbose build output (undo: "make V=1")
--disable-silent-rules verbose build output (undo: "make V=0")
--enable-dependency-tracking
do not reject slow dependency extractors
--disable-dependency-tracking
speeds up one-time build
--enable-static[=PKGS] build static libraries [default=no]
--enable-shared[=PKGS] build shared libraries [default=yes]
--enable-fast-install[=PKGS]
optimize for fast installation [default=yes]
--disable-libtool-lock avoid locking (might break parallel builds)
--disable-ipv4 Do not build iptables
--disable-ipv6 Do not build ip6tables
--disable-largefile Do not build largefile support
--enable-devel Install Xtables development headers
--enable-libipq Build and install libipq
--enable-bpf-compiler Build bpf compiler
--enable-nfsynproxy Build SYNPROXY configuration tool
--disable-nftables Do not build nftables compat
--disable-connlabel Do not build libnetfilter_conntrack
Optional Packages:
--with-PACKAGE[=ARG] use PACKAGE [ARG=yes]
--without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
--with-pic[=PKGS] try to use only PIC/non-PIC objects [default=use
both]
--with-gnu-ld assume the C compiler uses GNU ld [default=no]
--with-sysroot=DIR Search for dependent libraries within DIR
(or the compiler's sysroot if not specified).
--with-kernel=PATH Path to kernel source/build directory
--with-kbuild=PATH Path to kernel build directory
[[/lib/modules/CURRENT/build]]
--with-ksource=PATH Path to kernel source directory
[[/lib/modules/CURRENT/source]]
--with-xtlibdir=PATH Path where to install Xtables extensions
[[LIBEXECDIR/xtables]]
--with-pkgconfigdir=PATH
Path to the pkgconfig directory [[LIBDIR/pkgconfig]]
Some influential environment variables:
CC C compiler command
CFLAGS C compiler flags
LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
nonstandard directory <lib dir>
LIBS libraries to pass to the linker, e.g. -l<library>
CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
you have headers in a nonstandard directory <include dir>
CPP C preprocessor
PKG_CONFIG path to pkg-config utility
PKG_CONFIG_PATH
directories to add to pkg-config's search path
PKG_CONFIG_LIBDIR
path overriding pkg-config's built-in search path
libnfnetlink_CFLAGS
C compiler flags for libnfnetlink, overriding pkg-config
libnfnetlink_LIBS
linker flags for libnfnetlink, overriding pkg-config
libmnl_CFLAGS
C compiler flags for libmnl, overriding pkg-config
libmnl_LIBS linker flags for libmnl, overriding pkg-config
libnftnl_CFLAGS
C compiler flags for libnftnl, overriding pkg-config
libnftnl_LIBS
linker flags for libnftnl, overriding pkg-config
YACC The `Yet Another Compiler Compiler' implementation to use.
Defaults to the first program found out of: `bison -y', `byacc',
`yacc'.
YFLAGS The list of arguments that will be passed by default to $YACC.
This script will default YFLAGS to the empty string to avoid a
default value of `-d' given by some make applications.
libnetfilter_conntrack_CFLAGS
C compiler flags for libnetfilter_conntrack, overriding
pkg-config
libnetfilter_conntrack_LIBS
linker flags for libnetfilter_conntrack, overriding pkg-config
Use these variables to override the choices made by `configure' or to help
it to find libraries and programs with nonstandard names/locations.
Report bugs to the package provider.
badri#badri-All-Series:~/Downloads/iptables-1.6.1$
looks like it is also expecting LDFLAGS which shouldn't be the case. If i configured alongwith the options
LDFLAGS=-L/home/badri/arm_libs/nfnetlink/lib LIBS=-lnfnetlink
I can see that it seems to get past the linker errors for nfnl. And now it gets stuck at nftnl. Although ideally i would have expected the existing configure options to suffice.
This is difficult to say what exactly is causing your issue, but I would say that you may be missing -lnftnl linker option - my two cents.
This being said, I tried to cross-compile libmnl-1.0.4.tar.bz2, libnftnl-1.1.7.tar.bz2 and iptables-1.8.5.tar.bz2 using the following script, and all three compilations did succeed:
build.sh:
#/bin/bash
CROSS_COMPILE=/opt/arm/9/gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-
mkdir sysroot
PREFIX=$(pwd)/sysroot
wget https://www.netfilter.org/projects/libmnl/files/libmnl-1.0.4.tar.bz2
wget https://www.netfilter.org/projects/libnftnl/files/libnftnl-1.1.7.tar.bz2
wget https://www.netfilter.org/projects/iptables/files/iptables-1.8.5.tar.bz2
tar jxf libmnl-1.0.4.tar.bz2
tar jxf libnftnl-1.1.7.tar.bz2
tar jxf iptables-1.8.5.tar.bz2
pushd libmnl-1.0.4
CC=${CROSS_COMPILE}gcc ./configure --build=x86_64-pc-linux-gnu --host=aarch64-linux-gnu --enable-static=no --prefix=${PREFIX}
make install
popd
pushd libnftnl-1.1.7
CC=${CROSS_COMPILE}gcc LIBMNL_CFLAGS="-I${PREFIX}/include" LIBMNL_LIBS="-L${PREFIX}/lib" ./configure --build=x86_64-pc-linux-gnu --host=aarch64-linux-gnu --enable-static=no --prefix=${PREFIX}
make install
popd
pushd iptables-1.8.5
CC=${CROSS_COMPILE}gcc libnftnl_CFLAGS="-I${PREFIX}/include" libnftnl_LIBS="-L${PREFIX}/lib -lnftnl" ./configure --build=x86_64-pc-linux-gnu --host=aarch64-linux-gnu --enable-static=no --prefix=${PREFIX}
make install
popd
After the script completed, iptables was available in sysroot/sbin:
ls -gG sysroot/sbin/
total 1424
lrwxrwxrwx 1 17 Aug 17 14:24 arptables -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 arptables-nft -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 arptables-nft-restore -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 arptables-nft-save -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 arptables-restore -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 arptables-save -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 ebtables -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 ebtables-nft -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 ebtables-nft-restore -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 ebtables-nft-save -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 ebtables-restore -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 ebtables-save -> xtables-nft-multi
lrwxrwxrwx 1 20 Aug 17 14:24 ip6tables -> xtables-legacy-multi
lrwxrwxrwx 1 14 Aug 17 14:24 ip6tables-apply -> iptables-apply
lrwxrwxrwx 1 20 Aug 17 14:24 ip6tables-legacy -> xtables-legacy-multi
lrwxrwxrwx 1 20 Aug 17 14:24 ip6tables-legacy-restore -> xtables-legacy-multi
lrwxrwxrwx 1 20 Aug 17 14:24 ip6tables-legacy-save -> xtables-legacy-multi
lrwxrwxrwx 1 17 Aug 17 14:24 ip6tables-nft -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 ip6tables-nft-restore -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 ip6tables-nft-save -> xtables-nft-multi
lrwxrwxrwx 1 20 Aug 17 14:24 ip6tables-restore -> xtables-legacy-multi
lrwxrwxrwx 1 17 Aug 17 14:24 ip6tables-restore-translate -> xtables-nft-multi
lrwxrwxrwx 1 20 Aug 17 14:24 ip6tables-save -> xtables-legacy-multi
lrwxrwxrwx 1 17 Aug 17 14:24 ip6tables-translate -> xtables-nft-multi
lrwxrwxrwx 1 20 Aug 17 14:24 iptables -> xtables-legacy-multi
lrwxrwxrwx 1 20 Aug 17 14:24 iptables-legacy -> xtables-legacy-multi
lrwxrwxrwx 1 20 Aug 17 14:24 iptables-legacy-restore -> xtables-legacy-multi
lrwxrwxrwx 1 20 Aug 17 14:24 iptables-legacy-save -> xtables-legacy-multi
lrwxrwxrwx 1 17 Aug 17 14:24 iptables-nft -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 iptables-nft-restore -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 iptables-nft-save -> xtables-nft-multi
lrwxrwxrwx 1 20 Aug 17 14:24 iptables-restore -> xtables-legacy-multi
lrwxrwxrwx 1 17 Aug 17 14:24 iptables-restore-translate -> xtables-nft-multi
lrwxrwxrwx 1 20 Aug 17 14:24 iptables-save -> xtables-legacy-multi
lrwxrwxrwx 1 17 Aug 17 14:24 iptables-translate -> xtables-nft-multi
-rwxr-xr-x 1 373064 Aug 17 14:23 xtables-legacy-multi
lrwxrwxrwx 1 17 Aug 17 14:24 xtables-monitor -> xtables-nft-multi
-rwxr-xr-x 1 1079440 Aug 17 14:23 xtables-nft-multi
file sysroot/sbin/xtables-nft-multi
sysroot/sbin/xtables-nft-multi: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, not stripped
This may help you investigating your issue or cross-compiling iptables using the procedure above.

How to build a portable static C library for macOS

I'd like to build a portable static C library that can be linked into macOS binaries regardless of macOS version. The C library does not have any dependencies (i.e. no stdlib, no OS specific calls). The only dependency is the CPU which has to be x86_64.
When extracting the relevant compiler triplet, I get x86_64-apple-darwin16.7.0 for Sierra, and x86_64-apple-darwin17.2.0 for High Sierra. Also, when I build on High Sierra, there is a warning if I use the static library from Sierra (even when I specify --target x86_64-apple-darwin16.7.0 for clang).
How can I build a truly portable static library for macOS? If it is not possible, what is the way to go? One different version per major macOS release that is built from the same release? Some hackery by copying SDKs from outdated Xcode versions? Keep in mind, my library is completely portable and does not depend on macOS or the stdlib in any way.
Does the version part at the end of the compiler triplet matter?
You can just create a static library directly by using macosx libtool
Here's what I just tested out on 3 different versions of Mac OS X (Sierra, High Sierra and Mavrick):
$ ls -al ⏎
total 64
drwxr-xr-x 8 masud staff 272 Dec 5 11:12 .
drwxr-xr-x 7 masud staff 238 Dec 5 10:35 ..
-rw-r--r-- 1 masud staff 386 Dec 5 11:11 Makefile
-rwxr-xr-x 1 masud staff 8464 Dec 5 10:38 bar
-rw-r--r-- 1 masud staff 69 Dec 5 11:11 bar.c
-rw-r--r-- 1 masud staff 53 Dec 5 11:10 foo.c
-rw-r--r-- 1 masud staff 84 Dec 5 11:11 foo.h
-rw-r--r-- 1 masud staff 83 Dec 5 11:11 test.c
$ cat Makefile⏎
LIBTOOL=libtool
STATIC=-static
LIBFOO_A=libfoo.a
SRC=foo.c bar.c
OBJ=$(SRC:.c=.o)
LIBFOOCFLAGS=-mmacosx-version-min=10.1
TESTSRC=test.c
TESTCFLAGS=-mmacosx-version-min=10.7
$(LIBFOO_A): $(OBJ)
$(LIBTOOL) $(STATIC) -o $# $(OBJ)
%.o: %.c
$(CC) $(LIBFOOCFLAGS) -c -o $# $<
test: $(LIBFOO_A) test.c
$(CC) $(TESTCFLAGS) -o $# test.c -L. -lfoo
clean:
$(RM) test $(LIBFOO_A) $(OBJ)
$ cat foo.c⏎
int foo(void) {
volatile int a = 0;
return a;
}
$ cat foo.h⏎
#ifndef __FOO_H
#define __FOO_H
extern int foo(void);
#endif
$ cat bar.c⏎
#include "foo.h"
int bar(int k) {
return k-1;
}
In my tests, libfoo.a could be generated on any (of the three) platform(s) and copied to any (of the three) platform(s) and be used to generate test locally.
nm test on all three shows library statically linked into the binary.
Hope this helps.
on macosx libtool
P.S.: macosx libtool is NOT the same as the gnu libtool except in name. Completely different usage and functionality. the macosx libtool is essentially AR + ranlib + some darwinisms.

Why I am getting libhdf5_hl not loaded error during executing the HDF5 example code?

I am trying to executing the c program to execute the HDF5 basic code. That is here below.
/*
* This example illustrates how to create a dataset that is a 4 x 6
* array. It is used in the HDF5 Tutorial.
*/
#include "hdf5.h"
#define FILE "dset.h5"
int main() {
hid_t file_id, dataset_id, dataspace_id; /* identifiers */
hsize_t dims[2];
herr_t status;
/* Create a new file using default properties. */
file_id = H5Fcreate(FILE, H5F_ACC_TRUNC, H5P_DEFAULT, H5P_DEFAULT);
/* Create the data space for the dataset. */
dims[0] = 4;
dims[1] = 6;
dataspace_id = H5Screate_simple(2, dims, NULL);
/* Create the dataset. */
dataset_id = H5Dcreate2(file_id, "/dset", H5T_STD_I32BE, dataspace_id,
H5P_DEFAULT, H5P_DEFAULT, H5P_DEFAULT);
/* End access to the dataset and release resources used by it. */
status = H5Dclose(dataset_id);
/* Terminate access to the data space. */
status = H5Sclose(dataspace_id);
/* Close the file. */
status = H5Fclose(file_id);
}
I am not getting any compile time error, but run time error saying it is not able load some lib. The error is pasted below -
19:36:27 macOS_ ⚡ h5cc -show myprog.c
clang -arch x86_64 myprog.c -L/Users/Ajay/anaconda/lib -lhdf5_hl -lhdf5 -arch x86_64 -lpthread -lz -ldl -lm
19:36:33 macOS_ ⚡ ./a.out
dyld: Library not loaded: #rpath/libhdf5_hl.10.dylib
Referenced from: /Users/Ajay/opensource/HDF5-Examples/./a.out
Reason: image not found
Abort trap: 6
19:36:35 macOS_ ⚡
more information on configuration -
09:11:59 macOS_ ⚡ h5cc -showconfig
SUMMARY OF THE HDF5 CONFIGURATION
=================================
General Information:
-------------------
HDF5 Version: 1.8.17
Configured on: Tue Aug 2 08:44:51 BST 2016
Configured by: ray#rays-Mac.local
Configure mode: production
Host system: i386-apple-darwin11.4.2
Uname information: Darwin rays-Mac.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
Byte sex: little-endian
Libraries: shared
Installation point: /Users/Ajay/anaconda
Compiling Options:
------------------
Compilation Mode: production
C Compiler: /usr/bin/clang ( Apple LLVM version 4.2 )
CFLAGS: -arch x86_64
H5_CFLAGS: -O3
AM_CFLAGS:
CPPFLAGS:
H5_CPPFLAGS: -DNDEBUG -UH5_DEBUG_API
AM_CPPFLAGS:
Shared C Library: yes
Static C Library: no
Statically Linked Executables: no
LDFLAGS: -arch x86_64
H5_LDFLAGS:
AM_LDFLAGS:
Extra libraries: -lpthread -lz -ldl -lm
Archiver: ar
Ranlib: ranlib
Debugged Packages:
API Tracing: no
Languages:
----------
Fortran: no
C++: yes
C++ Compiler: /usr/bin/clang++ ( Apple LLVM version 4.2 )
C++ Flags: -arch x86_64
H5 C++ Flags: -O3
AM C++ Flags:
Shared C++ Library: yes
Static C++ Library: no
Features:
---------
Parallel HDF5: no
High Level library: yes
Threadsafety: yes
Default API Mapping: v18
With Deprecated Public Symbols: yes
I/O filters (external): deflate(zlib)
MPE: no
Direct VFD: no
dmalloc: no
Clear file buffers before write: yes
Using memory checker: no
Function Stack Tracing: no
Strict File Format Checks: no
Optimization Instrumentation: no
lib locations
09:11:56 macOS_ ⚡ ls /Users/Ajay/anaconda/lib | grep hdf5
-rwxr-xr-x 2 Ajay staff 17232 Aug 2 2016 libhdf5_hl_cpp.11.dylib
-rwxr-xr-x 2 Ajay staff 123256 Aug 2 2016 libhdf5_hl.10.dylib
-rwxr-xr-x 2 Ajay staff 445776 Aug 2 2016 libhdf5_cpp.12.dylib
-rwxr-xr-x 2 Ajay staff 2622428 Aug 2 2016 libhdf5.10.dylib
lrwxr-xr-x 1 Ajay staff 20 Mar 25 09:11 libhdf5_cpp.dylib -> libhdf5_cpp.12.dylib
lrwxr-xr-x 1 Ajay staff 16 Mar 25 09:11 libhdf5.dylib -> libhdf5.10.dylib
-rwxr-xr-x 1 Ajay staff 1087 Mar 25 09:11 libhdf5_hl_cpp.la
lrwxr-xr-x 1 Ajay staff 23 Mar 25 09:11 libhdf5_hl_cpp.dylib -> libhdf5_hl_cpp.11.dylib
-rwxr-xr-x 1 Ajay staff 988 Mar 25 09:11 libhdf5_hl.la
lrwxr-xr-x 1 Ajay staff 19 Mar 25 09:11 libhdf5_hl.dylib -> libhdf5_hl.10.dylib
-rwxr-xr-x 1 Ajay staff 993 Mar 25 09:11 libhdf5_cpp.la
-rw-r--r-- 1 Ajay staff 2243 Mar 25 09:11 libhdf5.settings
-rwxr-xr-x 1 Ajay staff 937 Mar 25 09:11 libhdf5.la
Based on the comment I can now run using
DYLD_LIBRARY_PATH=/Users/Ajay/anaconda/lib ./a.out
How to make it permanent ?
I am not on a Mac and don't use Anaconda. I'll try to guess-diagnose your problem anyway :-)
The program builds but will not execute. There is a mismatch between the libraries that are requested by the executable (libhdf5_hl.10.dylib) and the ones that are in your system.
You are using Anaconda installed hdf5. You must check what is the compiler used by Anaconda to build hdf5 and use the same.
The easiest way out is if all that is missing is the DYLD_LIBRARY_PATH path to /Users/Ajay/anaconda/lib. Try
DYLD_LIBRARY_PATH=/Users/Ajay/anaconda/lib ./a.out
For further info, please provide the output of
ls /Users/Ajay/anaconda/lib | grep hdf5
h5cc -showconfig

OSX 10.11.6 lldb says Breakpoint 1: no locations (pending)

I have what should be an elementary activity with C, Make and lldb on OSX, that seems to not be working as-specified in the documentation. The simple C-coding exercise to learn the "lldb" Debugger, is Exercise-4 from "Learning C The Hard Way" (Shaw, Zed A., 2015), so it's a well-worn, no complexities example of how this should work. Only OSX doesn't behave the way its Man and Help pages say it should.
Is there something fundamentally missing from the Makefile? Is the documentation giving me incorrect syntax? Is there a bug with this version of OSX or the compiler, or lldb? Can you just not set Breakpoints on the main() method in C on OSX, so the exercise is fundamentally flawed and no-one noticed for two years?
Thanks for taking the time to look it over ...
Here's the whole use-case output:
My-MacBook-Pro:Exercises Me$ ls -als total 48
0 drwxr-xr-x 7 Me staff 238 Mar 12 20:56 .
0 drwxr-xr-x 8 Me staff 272 Feb 26 02:11 ..
24 -rw-r--r--# 1 Me staff 10244 Mar 12 20:56 .DS_Store
0 drwxr-xr-x 5 Me staff 170 Mar 3 02:48 BonusContent
8 -rw-r--r--# 1 Me staff 48 Mar 12 20:56 Makefile
8 -rw-r--r--# 1 Me staff 322 Feb 28 00:50 ex1.c
8 -rw-r--r-- 1 v staff 184 Mar 12 19:53 ex3.c
My-MacBook-Pro:Exercises Me$ cat ex3.c
#include <stdio.h>
int main(int argc, char *argv[])
{
int age = 10;
int height = 72;
printf(" I am %d years old.\n", age);
printf(" I am %d inches tall.\n", height);
return 0;
}
My-MacBook-Pro:Exercises Me$ cat Makefile
CFLAGS=-Wall -g
all: ex3
clean:
rm -f ex3
My-MacBook-Pro:Exercises Me$ make ex3
cc -Wall -g ex3.c -o ex3
My-MacBook-Pro:Exercises Me$
My-MacBook-Pro:Exercises Me$ lldb ex3
(lldb) target create "ex3"
Current executable set to 'ex3' (x86_64).
(lldb) breakpoint set --method main
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
(lldb)
My-MacBook-Pro:Exercises Me$ ls -als
total 72
0 drwxr-xr-x 9 Me staff 306 Mar 12 20:57 .
0 drwxr-xr-x 8 Me staff 272 Feb 26 02:11 ..
24 -rw-r--r--# 1 Me staff 10244 Mar 12 20:57 .DS_Store
0 drwxr-xr-x 5 Me staff 170 Mar 3 02:48 BonusContent
8 -rw-r--r--# 1 Me staff 48 Mar 12 20:56 Makefile
8 -rw-r--r--# 1 Me staff 322 Feb 28 00:50 ex1.c
24 -rwxr-xr-x 1 Me staff 8712 Mar 12 20:57 ex3
8 -rw-r--r-- 1 Me staff 184 Mar 12 19:53 ex3.c
0 drwxr-xr-x 3 Me staff 102 Mar 12 20:57 ex3.dSYM
My-MacBook-Pro:Exercises Me$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.11.6
BuildVersion: 15G1217
My-MacBook-Pro:Exercises Me$
My-MacBook-Pro:Exercises Me$ clang --version -g
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
My-MacBook-Pro:Exercises Me$
My-MacBook-Pro:Exercises Me$ make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i386-apple-darwin11.3.0
My-MacBook-Pro:Exercises Me$
My-MacBook-Pro:Exercises Me$ lldb --version
lldb-360.1.70
In response to "Olaf":
LLDB Documentation
(lldb) breakpoint set --name main
(lldb) br s -n main
(lldb) b main
There is one other thread with a similar error message from 2015 on an older version of OSX, but its 'solution' does NOT work, and indeed ignores the issue by not using Make at all.
I'd like to try and avoid orthogonal or complex 'suggestions' along the lines of "Why don't you not use C, try using some other language", or "I prefer using a different debugger, so use this one" ... those won't answer the question :)
The b command and the breakpoint set command are quite different. b is a DWIM type command that tries as much as possible to emulate the gdb breakpoint parser's syntax. It eventually dispatches to break set with the appropriate breakpoint type.
breakpoint set -n foo creates a general "symbol name matching" breakpoint. So for instance, it will match a function called "foo" or an ObjC selector "foo" or a C++ method called "foo"... b foo dispatches to breakpoint set -n foo.
But sometimes you know you only want to set a breakpoint on class methods (C++ or Swift) in which case you can use the --method option to limit the search appropriately. Ditto for ObjC selectors and the --selector option.
In your case, that --name worked but --method didn't is correct behavior. Your main is a pure C function, not a class method.
BTW, the b is actually an lldb "regex command", see
(lldb) help command regex
for more details. You can see what the command is actually doing by turning on echoing the regex command resolution with:
(lldb) set set interpreter.expand-regex-aliases 1
then try some breakpoints:
(lldb) b main
breakpoint set --name 'main'
(lldb) b foo.c:11
breakpoint set --file 'foo.c' --line 11
etc...
From one person's attempt to reproduce the conditions, a valuable observation that in his installation he could get the commands to work synonymously as prescribed was helpful, and indirectly provided the solution.
I uninstalled the entire XCode module and the other supporting C development modules I had, and re-installed with fresh downloads. After that, I had the same functionality he observed.
The issue was therefore somewhere in the binary installations on my specific MacBook, perhaps due to an update not having properly applied somewhere along the way, and this was not a generic issue.

How can I use a GMP library I just built from source?

I've got a tiny C program with the following header:
#include <gmp.h>
I compile it doing:
gcc test.c -o test.o -L/gmp_install/lib -lgmp
And then I can run it fine. But it is using the "stock" GMP library on my system.
Now I'd like to compile it using another version of the GMP lib, which I installed locally and I can't make it work.
The new library is apparently installed in /usr/local/lib:
... $ ls -l /usr/local/lib
-rw-r--r-- 1 root staff 1276320 Jun 15 02:22 libgmp.a
-rwxr-xr-x 1 root staff 914 Jun 15 02:22 libgmp.la
lrwxrwxrwx 1 root staff 16 Jun 15 02:22 libgmp.so -> libgmp.so.10.2.0
lrwxrwxrwx 1 root staff 16 Jun 15 02:22 libgmp.so.10 -> libgmp.so.10.2.0
-rwxr-xr-x 1 root staff 528715 Jun 15 02:22 libgmp.so.10.2.0
But no matter what I try, it's apparently the old library that is used.
Even using:
gcc perf.c -o perf.o -O3 -L/ -lgmp
But it's using the GMP version in /usr/lib/x86_64-linux-gnu/.
What is the correct way to use the GMP version in /usr/local/bin, knowing I'd like to keep the old version too?
Also, once the executable is created, is there an easy way to see which library it shall use at runtime? (can I create the executable with one version of GMP and then execute it with another version of GMP, knowing the lib is dynamically linked?)
Do two things:
Use -L/usr/local/lib flag while compiling
Set LD_LIBRARY_PATH variable while running your program to have /usr/local/lib. Thus, if you are using a bash shell, you will have to do something like
$ export LD_LIBRARY_PATH=/usr/local/lib
$ ./your_program
to use the /usr/local/lib version at runtime. Also, in order to see which one it will use at runtime, you can always do ldd <your binary name> which will print out all the dynamic dependencies.

Resources