Compile binary on arm64 macos for x86_64 linux - c

I'm trying to compiled a C library using C make. I have three toolchain files:
MacOS arm64
MacOS x86_64
Linux x86_64
The files look like this:
# darwin.arm64.toolchain.cmake
set(CMAKE_SYSTEM_NAME Darwin)
set(CMAKE_SYSTEM_PROCESSOR arm64)
set(CMAKE_SYSTEM_VERSION "${CMAKE_HOST_SYSTEM_VERSION}")
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE NEVER)
# darwin.x86_64.toolchain.cmake
set(CMAKE_SYSTEM_NAME Darwin)
set(CMAKE_SYSTEM_PROCESSOR x86_64)
set(CMAKE_SYSTEM_VERSION "${CMAKE_HOST_SYSTEM_VERSION}")
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE NEVER)
# linux.x86_64.toolchain.cmake
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR x86_64)
set(CMAKE_SYSTEM_VERSION "${CMAKE_HOST_SYSTEM_VERSION}")
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE NEVER)
My cmake invocation looks something like this: cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_TOOLCHAIN_FILE=${ROOT_DIR}/toolchains/linux.x86_64.toolchain.cmake .
The issue I'm having is that both the MacOS builds work correctly. The linux build, however fails with:
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - broken
CMake Error at /opt/homebrew/Cellar/cmake/3.25.0/share/cmake/Modules/CMakeTestCCompiler.cmake:70 (message):
The C compiler
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /Users/maxgale/X/CMakeFiles/CMakeScratch/TryCompile-xBXBOz
Run Build Command(s):/usr/bin/make -f Makefile cmTC_8e560/fast && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/cmTC_8e560.dir/build.make CMakeFiles/cmTC_8e560.dir/build
Building C object CMakeFiles/cmTC_8e560.dir/testCCompiler.c.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -MD -MT CMakeFiles/cmTC_8e560.dir/testCCompiler.c.o -MF CMakeFiles/cmTC_8e560.dir/testCCompiler.c.o.d -o CMakeFiles/cmTC_8e560.dir/testCCompiler.c.o -c /Users/maxgale/X/CMakeFiles/CMakeScratch/TryCompile-xBXBOz/testCCompiler.c
Linking C executable cmTC_8e560
/opt/homebrew/Cellar/cmake/3.25.0/bin/cmake -E cmake_link_script CMakeFiles/cmTC_8e560.dir/link.txt --verbose=1
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc CMakeFiles/cmTC_8e560.dir/testCCompiler.c.o -o cmTC_8e560
ld: library not found for -lSystem
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [cmTC_8e560] Error 1
make: *** [cmTC_8e560/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:3 (project)
What am I missing to get this cross-compile to working?

To me it seems you expect to build a MacOSX binary and expect it to run on a Linux distro. Let's start by a simple distinction between MacOSX and Linux-based operating systems:
MacOSX is Unix-based. For binaries it uses the "Mach-O" format.
Linux is Unix-like. For binaries it uses the ELF format.
Expecting to build a binary for linux without the proper toolchain is probably not going to work out well. I'm judging this by the fact that you are technically only setting "aesthetic" options in CMake. i.e.
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR x86_64)
set(CMAKE_SYSTEM_VERSION "${CMAKE_HOST_SYSTEM_VERSION}")
These don't really do much. For example you need to configure the correct compiler, via e.g.:
set(CMAKE_C_COMPILER ... ) #This should point to a cross-compiler not your standard compiler
You also need to actually point to the correct libraries that the cross compiler should use. None of which you are doing.
As a side note: There is no -lSystem on linux. Most libraries (if not all) are lower-case.
So how do you fix this? Well the easiest way is to get a VM running with the linux kernel. Docker for desktop (on Mac) does this to provide you with docker containers. So if you already have that, you just need a docker container and build in it.
The last option you have is to check out something I found via a quick google search: osxcross on github. And even better (a docker image that handles everything for you): crossbuild on github

Related

CMake, cross-compilation for three main desktop platforms Win/Mac/Linux under MacOS

I work on the native part of my C# lib written in C. This part provides native socket API for main platforms win/mac/linux. I'm already building sources independently on each platform using CMake.
My current goal builds lib for these platforms at my dev machine (MacOS).
Platforms list:
# 64 bit builds
- linux64
- osx
- win64
# 32 bit builds
- linux32
- win32
After reading CMake docs about cross-compiling, and search some examples on GitHub I still have trouble with this task.
Docs:
https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html
GitHub search:
https://github.com/search?q=CMake+cross+compiling&type=Repositories
Could anyone explain a detailed step-by-step algorithm of what could I do to reach this goal?
A Simple "Hello World!" example with shared lib would be very helpful or link on the existing sample/project.
Thanks.
Update:
Project structure:
build/
cmake/
x64-linux.cmake
x86_64-osx.cmake
src/
native_socket.c
native_socket.h
CMakeLists.txt
build_native.sh
CMakeLists.txt:
cmake_minimum_required(VERSION 3.20.1)
project(native_socket LANGUAGES C)
add_library(native_socket SHARED src/native_socket.c)
set_target_properties(native_socket PROPERTIES PREFIX "")
build_native.sh:
cmake -H. -B build/linux64 -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=cmake/x64-linux.cmake
cmake --build ./build/linux64 -v
cmake -H. -B build/osx -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=cmake/x86_64-osx.cmake
cmake --build ./build/osx
x86_64-osx.cmake:
set(CMAKE_SYSTEM_NAME Darwin)
set(CMAKE_C_COMPILER gcc)
x64-linux.cmake:
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_VERSION 1)
set(CMAKE_C_COMPILER gcc)
set(CMAKE_CROSSCOMPILING TRUE)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
After running build script, I see a linker error in the terminal:
% ./build_native.sh
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/rdcm/dev/projects/PInvoke/PInvoke/build/linux64
/Applications/CMake.app/Contents/bin/cmake -S/Users/rdcm/dev/projects/PInvoke/PInvoke -B/Users/rdcm/dev/projects/PInvoke/PInvoke/build/linux64 --check-build-system CMakeFiles/Makefile.cmake 0
/Applications/CMake.app/Contents/bin/cmake -E cmake_progress_start /Users/rdcm/dev/projects/PInvoke/PInvoke/build/linux64/CMakeFiles /Users/rdcm/dev/projects/PInvoke/PInvoke/build/linux64//CMakeFiles/progress.marks
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/Makefile2 all
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/native_socket.dir/build.make CMakeFiles/native_socket.dir/depend
cd /Users/rdcm/dev/projects/PInvoke/PInvoke/build/linux64 && /Applications/CMake.app/Contents/bin/cmake -E cmake_depends "Unix Makefiles" /Users/rdcm/dev/projects/PInvoke/PInvoke /Users/rdcm/dev/projects/PInvoke/PInvoke /Users/rdcm/dev/projects/PInvoke/PInvoke/build/linux64 /Users/rdcm/dev/projects/PInvoke/PInvoke/build/linux64 /Users/rdcm/dev/projects/PInvoke/PInvoke/build/linux64/CMakeFiles/native_socket.dir/DependInfo.cmake --color=
Dependencies file "CMakeFiles/native_socket.dir/src/native_socket.c.o.d" is newer than depends file "/Users/rdcm/dev/projects/PInvoke/PInvoke/build/linux64/CMakeFiles/native_socket.dir/compiler_depend.internal".
Consolidate compiler generated dependencies of target native_socket
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/native_socket.dir/build.make CMakeFiles/native_socket.dir/build
[ 50%] Linking C shared library native_socket.so
/Applications/CMake.app/Contents/bin/cmake -E cmake_link_script CMakeFiles/native_socket.dir/link.txt --verbose=1
/usr/bin/gcc -fPIC -O3 -DNDEBUG -shared -Wl,-soname,native_socket.so -o native_socket.so CMakeFiles/native_socket.dir/src/native_socket.c.o
ld: unknown option: -soname
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [native_socket.so] Error 1
make[1]: *** [CMakeFiles/native_socket.dir/all] Error 2
make: *** [all] Error 2
Questions:
Should I additional install dev tools on my dev machine for building .so/.dll lib for Linux/Win?
How should I change CMake config files for the successful build?
A real simple example that works will be very helpful. I think no matter in which environment Linux/MacOS because I have plans to automate this process.

MIPS GCC cross-compiler build fails: "cannot find -lc"

I am trying to set up a GCC 4.9.4 cross-compiler for a QCA955X-based router with Linux 2.6.31. This is a MIPS32R2-abi CPU that uses uClibc-0.9.30.1 (as found in /lib.) Due to this, I have decided to compile a GCC 4.x with the matching uClibc and binutils-2.19.1a. My host system is Ubuntu 18.04 with Linux 4.17-rc5 and gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)
~/mips-cross-gcc/staging_dir is my prefix, and ~/mips-cross-gcc/staging_dir/sysroot is the makeshift sysroot for my system.
1) I downloaded binutils-2.19.1a.tar.bz2, gcc-4.9.4.tar.bz2, linux-2.6.31.9.tar.xz, and uClibc-0.9.30.1.tar.bz2 into ~/mips-cross-gcc/sources.
2) I untar'd all the sources.
3) Install linux headers:
make ARCH=mips INSTALL_HDR_PATH=/home/user/mips-cross-gcc/staging_dir/sysroot/usr headers_install
4) Build binutils:
cd binutils-2.19.1
./configure --prefix=/home/user/mips-cross-gcc/staging_dir --target=mips-linux-uclibc --disable-multilib --disable-werror --enable-shared --without-newlib --with-sysroot=/home/user/mips-cross-gcc/staging_dir/sysroot --enable-languages=c,c++ --disable-libgomp
make all-binutils
make all-ld
make all-gas
make install-binutils
make install-ld
make install-gas
5) Build "stage 1" gcc, to bootstrap uClibc:
cd gcc-4.9.4
mkdir -p build/gcc-stage1
../../configure --target=mips-linux-uclibc --prefix=/home/user/mips-cross-gcc/staging_dir --disable-werror --disable-libgomp --without-newlib --disable-multilib --enable-languages=c,c++ --enable-shared --disable-__cxa_atexit --enable-target-optspace --disable-nls --disable-libmudflap --disable-libssp --with-float=soft --with-sysroot=/home/user/mips-cross-gcc/staging_dir/sysroot --with-gnu-ld --without-headers
make all-gcc
make install-gcc
6) Install uClibc headers:
cd uClibc-0.9.30.1
make PREFIX=/home/user/mips-cross-gcc/staging_dir/sysroot install_headers
7) Build libgcc for target arch:
cd gcc-4.9.4
make all-target-libgcc
Libgcc is compiled all the way until the final libgcc_s linking stage:
/home/daniel/mips-cross-gcc/staging_dir/mips-linux-uclibc/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
Makefile:937: recipe for target 'libgcc_s.so' failed
I thought that bootstrapping a GCC would not require a libc, because it has not been compiled yet, right? What could I be doing wrong? I would use this compiled GCC to build uClibc, and then I would compile GCC again with my new uClibc so that I can cross-compile software. The fact that GCC requires libc in the first build seems wrong.
I tried to use the first gcc without compiling libgcc for building uClibc, but nearly instantly I received:
LD ld-uClibc-0.9.30.1.so
mips-linux-uclibc-gcc: error: libgcc.a: No such file or directory
ldso/ldso/Makefile.in:54: recipe for target 'lib/ld-uClibc.so' failed
So, uClibc needs libgcc to link itself, and gcc needs a libc (of any type, including uClibc) to link its own libgcc. This seems like a chicken-and-egg problem. How would one fix this?
I fixed it. Apparently, GCC has to be built without shared libraries enabled (--disable-shared) so that it doesn't link the generated libraries like libgcc dynamically (i.e to libc,) but that still didn't work. -lc was still not found.
I did some more googling, and I found this helpful message from eglibc, about making their own toolchain with gcc: eglibc.org
The First GCC
For our work, we need a cross-compiler targeting a PowerPC Linux
system. However, that configuration includes the shared library
'libgcc_s.so', which is compiled against the EGLIBC headers (which we
haven't installed yet) and linked against 'libc.so' (which we haven't
built yet).
Fortunately, there are configuration options for GCC which tell it not
to build 'libgcc_s.so'. The '--without-headers' option is supposed to
take care of this, but its implementation is incomplete, so you must
also configure with the '--with-newlib' option. While '--with-newlib'
appears to mean "Use the Newlib C library", its effect is to tell the
GCC build machinery, "Don't assume there is a C library available."
Looks like with enough digging, someone's bound to find the exact problem one has.
In short, changing --enable-shared to --disable-shared and adding --with-newlib to GCC's
./configure solved the issue and compiled + linked a libgcc_s.so that I used to compile uClibc, and then recompiled gcc with the newly generated libc, from uClibc. Indeed, it is possible to compile a 2016 GCC 4.x with a 2011 uClibc on a 2018 GCC 7.x.

How to compile neon on ARM

I used the
arm-linux-gnueabi-g++ test.cpp -march=armv7-a -mfloat-abi=softfp -mfpu=neon -o test
on ubantu to get an excecutable file on ARM, but when I ran
adb push ./test /data/test
adb shell
cd data
chmod 777 test
./test
I got the following error:
./system/bin/sh: ./test: No such file or directory
I was confused about this.
If you intend to run the executable on Android (as it seems), you should ideally build it using the Android NDK. The problem is that your executable links to glibc which is available on normal linux systems, but not on Android. (In detail, the executable can't start because it requires the dynamic linker /lib/ld-linux.so.3 which isn't available on Android. In addition, it also requires glibc in the form of libc.so.6.)
If you build executables using the Android NDK, it will link to the Bionic libc, which is what is available on Android.
Alternatively, if you add -static when linking (in your case, in your single compile+link command), you'll get a static executable, which should work on both normal linux and Android.

compiling Vim 7.4 under AIX 6.1

I have a problem while compiling Vim 7.4 under AIX 6.1.
My options for the configure script are: "--prefix /opt/freeware/bin" and "--enable-pythoninterp".
There where no Errors while running the configure Script but when I try to run "make" I get the error message:
cd src && make first
cc -qlanglvl=extc89 -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_ATHENA -DFUNCPROTO=15 -g -o objects/regexp.o regexp.c "regexp_nfa.c"
line 4410.1: 1506-046 (S) Syntax error.
make: 1254-004 > The error code from the last command is
1.
Stop. make: 1254-004 The error code from the last command is 2.
Stop.
Does anyone know what to do?
I had compiled Vim 7.4 in my home directory so I know that there is a workaround but I can't find it anymore.
AIX's built in make (based on standard AT&T make) is not compatible with the Makefiles built by autoconf tools. Use GNU make (gmake) instead. You may already have it installed (check /opt/freeware/bin), install from the Linux Toolbox for AIX set (from IBM), or from one of the websites providing prebuilt GNU tools for AIX systems (perzl, bullfreeware, etc). Just provide an alias from make to gmake, or override the use of make in the Makefile itself.

CMAKE cross compile libraries are not found

I'm having strange problems with my cmake cross-compiler projects.
My own libraries are found but not the (system) libraries from my toolchain.
Previously I was using KDevelop on debian squeeze machine.
now on my new machine with debian wheezy the configuring fails.
It does not find the system libraries like m or pthread.
On my old machine the following was working perfectly, but I do not remember that I did something special to make this work.
Here is one of my CMakeLists.txt files
cmake_minimum_required(VERSION 2.8)
SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_SYSTEM_VERSION 2.6.36.4)
SET(CMAKE_C_COMPILER arm-angstrom-linux-gnueabi-gcc)
SET(CMAKE_CXX_COMPILER arm-angstrom-linux-gnueabi-g++)
include_directories(../include
../../../sample/include)
project(testmain)
add_executable(testmain
some_c-source-file.c)
set(CMAKE_LIBRARY_PATH ../lib/arm-26/lib
../../../sample/lib/arm-26/lib)
find_library(LIBS_TEST NAMES akku)
find_library(LIBS_M NAMES m)
find_library(LIBS_PTHREAD NAMES pthread )
target_link_libraries(akkumain
${LIBS_TEST}
${LIBS_M}
${LIBS_PTHREAD})
set(CMAKE_C_FLAGS "-Wall -Werror")
set(CMAKE_C_FLAGS_DEBUG "-g3 -O2 -rdynamic")
set(CMAKE_C_FLAGS_RELEASE "-g0 -O0")
set(CMAKE_CXX_FLAGS "-Wall -Werror")
set(CMAKE_CXX_FLAGS_DEBUG "-g3 -O2 -rdynamic")
set(CMAKE_CXX_FLAGS_RELEASE "-g0 -O0")
This is the message displayed when trying to compile using KDevelop: (to repeat myself: this was working on my old machine)
/home/user/testmain/build> /usr/bin/cmake -DCMAKE_BUILD_TYPE=Debug /home/user/testmain/
-- The C compiler identification is GNU 4.3.3
-- The CXX compiler identification is GNU 4.3.3
-- Check for working C compiler: /usr/local/angstrom/arm/bin/arm-angstrom-linux-gnueabi-gcc
-- Check for working C compiler: /usr/local/angstrom/arm/bin/arm-angstrom-linux-gnueabi-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/local/angstrom/arm/bin/arm-angstrom-linux-gnueabi-g++
-- Check for working CXX compiler: /usr/local/angstrom/arm/bin/arm-angstrom-linux-gnueabi-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
LIBS_M
linked by target "akkumain" in directory /home/user/testmain
LIBS_PTHREAD
linked by target "akkumain" in directory /home/user/testmain
So LIBS_TEST is found. But not libm or libpthread.
I tried this with different projects: All of my libraries are found, but none of the "system" libraries.
I already tried different things like
set(CMAKE_FIND_LIBRARY_PREFIXES lib )
set(CMAKE_FIND_LIBRARY_SUFFIXES .a )
and some more things I do not remember.
The only thing what IS WORKING is when I specify the directory manually:
find_library(ASTLIBS_M NAMES m PATHS /usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib)
After specifying this to my CMakeLists.txt the library is found and I can compile my project without any errors.
BUT: This is not what I want, because I have a LOT of projects and many libraries and I don't want to edit all my CMakeLists.txt... :(
Does anybody know what made my old machine find the system-libs without specifying anything special inside my IDE/CMake files?
Edit:
I just noticed for one of my executables that on Linker stage it throws some errors that it cannot find some symbols from glibc - seems there is something more wrong with my debian wheezy system. - I hope I can figure it out...
Edit:
Maybe I should give a short summary: My code compiles well, but all libraries from my toolchain are not found, but if I add the path to the libs of my toolchain manually it compiles but fails on linker stage.
Have you ever tried using a toolchain file? I also cross-compile to ARM and AVR a LOT and it works very well with no hassle (I also use KDevelop and it works beautifully along with CMake). The main point is specifying the path to your toolchain root filesystem through the CMAKE_FIND_ROOT_PATH variable. Try putting all this in a file, which I usually name after the architecture I'm cross-compiling to (in this case I called it arm-unknown-linux-gnueabi.cmake):
# the name of the target operating system
SET(CMAKE_SYSTEM_NAME Linux)
# which C and C++ compiler to use
SET(CMAKE_C_COMPILER arm-unknown-linux-gnueabi-gcc)
SET(CMAKE_CXX_COMPILER arm-unknown-linux-gnueabi-g++)
# here is the target environment located
SET(CMAKE_FIND_ROOT_PATH /home/claudio/TS-7400/rootfs)
# adjust the default behaviour of the FIND_XXX() commands:
# search headers and libraries in the target environment, search
# programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE BOTH)
Note the variables CMAKE_FIND_ROOT_PATH_MODE_xxx variables control where CMake will look for binaries, libraries and header files. I usually set PROGRAM to NEVER so it never uses binaries from your cross-architecture root filesystem, since they will not run on your host machine anyway. For libraries and header files BOTH means it will search first your specified ROOT_PATH and then if it doesn't find something it will go through your host machine system dirs.
That way, whenever you want to cross-compile a project all you have to do is to create a build directory (so it doesn't mix your sources with files created during build) and then run cmake from there specifying the toolchain file you want to use (I'm supposing your CMakeLists.txt is together with your toolchain file on the same dir your sources are located - project_sources_dir in my example):
cd project_sources_dir
mkdir build
cd build
cmake -DCMAKE_TOOLCHAIN_FILE=../arm-unknown-linux-gnueabi.cmake ..
The whole point of using a toolchain file is that, if you want to compile the exact same project for your host machine, you don't have to change a single line in your CMakeLists.txt. Just run cmake without specifying the toolchain file:
cd project_sources_dir
mkdir build
cd build
cmake ..
and your project is ready for compiling native for your host machine instead. If all that isn't enough, you can look for more details here on CMake Cross Compiling
There are certain default paths where CMake's find_library module searches. If your system libs on your old machine happen to be located in one such place, they will be found without any additional work needing to be done.
However, as your new machine's path to these libs seems to be "/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib", you'll need to tell CMake about this.
One such way, is as you have shown (adding the path explicitly). But in this case, the path is probably specific to just that machine - so you'd be better to only set that path when you invoke CMake on that machine. You can add it to CMAKE_PREFIX_PATH for example:
cmake . -DCMAKE_PREFIX_PATH=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr
(Note: the path in this case get "lib" appended when find_library is called).
Or if you only want to affect the find_library search paths, and not all find_xxx modules, set CMAKE_LIBRARY_PATH
cmake . -DCMAKE_LIBRARY_PATH=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib

Resources