tl;dr
How can I compile Ada source code to a static library file suitable for apps on iPad targets running iOS to link against? (GCC is not a requirement. Solutions using LLVM or others are also welcome!)
I have a large library of portable Ada code that I would like to use in an iPad/iOS project. My host OS is Mac OS X 10.9 (running GCC 4.8.1 installed at /opt/local with MacPorts). To do this, I'm trying to build a GCC ARM cross-compiler with Ada support.
I am able to build a working GCC and GNAT that creates ARM executables, but I can't seem to build or install the Ada standard library, which is required for building my Ada code
The source packages I'm using:
gcc-4.8.1
binutils-2.24
libiconv-1.14
gmp-5.1.3
mpc-1.0.2
mpfr-3.1.2
The GCC build configuration:
$ bin/arm-none-eabi-gcc -v --version
Using built-in specs.
COLLECT_GCC=bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/Users/ardnew/cross/libexec/gcc/arm-none-eabi/4.8.1/lto-wrapper
arm-none-eabi-gcc (GCC) 4.8.1
Copyright (C) 2013 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.
Target: arm-none-eabi
Configured with: /Users/ardnew/cross/src/gcc-4.8.1/configure --target=arm-none-eabi --prefix=/Users/ardnew/cross --with-cpu=cortex-a8 --enable-languages=c,ada --disable-multilib --enable-interwork --disable-threads --disable-shared --disable-nls --disable-lto --disable-libssp --disable-decimal-float --disable-libgomp --disable-libmudflap
Thread model: single
gcc version 4.8.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '--version' '-mcpu=cortex-a8'
/Users/ardnew/cross/libexec/gcc/arm-none-eabi/4.8.1/cc1 -quiet -v -D__USES_INITFINI__ help-dummy -quiet -dumpbase help-dummy -mcpu=cortex-a8 -auxbase help-dummy -version --version -o /var/folders/4c/y_sll7bj6b9bt15389wr66_80000gn/T//ccrSSKFx.s
GNU C (GCC) version 4.8.1 (arm-none-eabi)
compiled by GNU C version 4.8.1, GMP version 5.1.3, MPFR version 3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-v' '--version' '-mcpu=cortex-a8'
/Users/ardnew/cross/lib/gcc/arm-none-eabi/4.8.1/../../../../arm-none-eabi/bin/as -mcpu=cortex-a8 -meabi=5 --version -o /var/folders/4c/y_sll7bj6b9bt15389wr66_80000gn/T//ccZYvQLp.o /var/folders/4c/y_sll7bj6b9bt15389wr66_80000gn/T//ccrSSKFx.s
GNU assembler (GNU Binutils) 2.24
Copyright 2013 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `arm-none-eabi'.
COMPILER_PATH=/Users/ardnew/cross/libexec/gcc/arm-none-eabi/4.8.1/:/Users/ardnew/cross/libexec/gcc/arm-none-eabi/4.8.1/:/Users/ardnew/cross/libexec/gcc/arm-none-eabi/:/Users/ardnew/cross/lib/gcc/arm-none-eabi/4.8.1/:/Users/ardnew/cross/lib/gcc/arm-none-eabi/:/Users/ardnew/cross/lib/gcc/arm-none-eabi/4.8.1/../../../../arm-none-eabi/bin/
LIBRARY_PATH=/Users/ardnew/cross/lib/gcc/arm-none-eabi/4.8.1/:/Users/ardnew/cross/lib/gcc/arm-none-eabi/4.8.1/../../../../arm-none-eabi/lib/
COLLECT_GCC_OPTIONS='-v' '--version' '-mcpu=cortex-a8'
/Users/ardnew/cross/libexec/gcc/arm-none-eabi/4.8.1/collect2 -X --version /Users/ardnew/cross/lib/gcc/arm-none-eabi/4.8.1/crti.o /Users/ardnew/cross/lib/gcc/arm-none-eabi/4.8.1/crtbegin.o crt0.o -L/Users/ardnew/cross/lib/gcc/arm-none-eabi/4.8.1 -L/Users/ardnew/cross/lib/gcc/arm-none-eabi/4.8.1/../../../../arm-none-eabi/lib /var/folders/4c/y_sll7bj6b9bt15389wr66_80000gn/T//ccZYvQLp.o --start-group -lgcc -lc --end-group /Users/ardnew/cross/lib/gcc/arm-none-eabi/4.8.1/crtend.o /Users/ardnew/cross/lib/gcc/arm-none-eabi/4.8.1/crtn.o
collect2 version 4.8.1
/Users/ardnew/cross/lib/gcc/arm-none-eabi/4.8.1/../../../../arm-none-eabi/bin/ld -X --version /Users/ardnew/cross/lib/gcc/arm-none-eabi/4.8.1/crti.o /Users/ardnew/cross/lib/gcc/arm-none-eabi/4.8.1/crtbegin.o crt0.o -L/Users/ardnew/cross/lib/gcc/arm-none-eabi/4.8.1 -L/Users/ardnew/cross/lib/gcc/arm-none-eabi/4.8.1/../../../../arm-none-eabi/lib /var/folders/4c/y_sll7bj6b9bt15389wr66_80000gn/T//ccZYvQLp.o --start-group -lgcc -lc --end-group /Users/ardnew/cross/lib/gcc/arm-none-eabi/4.8.1/crtend.o /Users/ardnew/cross/lib/gcc/arm-none-eabi/4.8.1/crtn.o
GNU ld (GNU Binutils) 2.24
Copyright 2013 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
Test program to ensure its building ARM binaries:
$ cat told_unit1.adb told_unit1.ads
--
-- FILE: told_unit1.adb
--
with Ada.Text_IO;
use Ada.Text_IO;
package body told_unit1 is
procedure hello is
begin
put_line("hello, world");
end hello;
function double(x : in float) return float is
begin
return x + x;
end double;
end told_unit1;
--
-- FILE: told_unit1.ads
--
package told_unit1 is
procedure hello;
pragma Export
(
convention => C,
entity => hello,
external_name => "ada_hello"
);
function double(x : in float) return float;
pragma Export
(
convention => C,
entity => double,
external_name => "ada_double"
);
end told_unit1;
Then compiling the Ada code and inspecting it with file:
$ arm-none-eabi-gcc -c told_unit1.adb
$ file told_unit1.o
told_unit1.o: ELF 32-bit LSB relocatable, ARM, version 1 (SYSV), not stripped
And then when I try to bind the library object file it pukes:
$ arm-none-eabi-gnatbind -aO$ADA_OBJECT_PATH -Ltold told_unit1
error: "a-textio.ali" not found, "a-textio.adb" must be compiled
Going back to my GCC build logs, I found that libada (which I believe is part of GNAT) wasn't ever built. When I try to run make all-target-libada from the GCC build directory, it eventually tells me:
Configuring in arm-none-eabi/libada
configure: loading cache ./config.cache
checking build system type... x86_64-apple-darwin13.1.0
checking host system type... arm-none-eabi
checking target system type... arm-none-eabi
checking for arm-none-eabi-gcc... /Users/ardnew/cross/src/gcc-4.8.1-obj/./gcc/xgcc -B/Users/ardnew/cross/src/gcc-4.8.1-obj/./gcc/ -B/Users/ardnew/cross/arm-none-eabi/bin/ -B/Users/ardnew/cross/arm-none-eabi/lib/ -isystem /Users/ardnew/cross/arm-none-eabi/include -isystem /Users/ardnew/cross/arm-none-eabi/sys-include
checking for C compiler default output file name...
configure: error: in `/Users/ardnew/cross/src/gcc-4.8.1-obj/arm-none-eabi/libada':
configure: error: C compiler cannot create executables
See `config.log' for more details.
make: *** [configure-target-libada] Error 1
And so I go inspect that config.log its referring to and find the following:
configure:2351: $? = 0
configure:2340: /Users/ardnew/cross/src/gcc-4.8.1-obj/./gcc/xgcc -B/Users/ardnew/cross/src/gcc-4.8.1-obj/./gcc/ -B/Users/ardnew/cross/arm-none-eabi/bin/ -B/Users/ardnew/cross/arm-none-eabi/lib/ -isystem /Users/ardnew/cross/arm-none-eabi/include -isystem /Users/ardnew/cross/arm-none-eabi/sys-include -v >&5
COLLECT_LTO_WRAPPER=/Users/ardnew/cross/src/gcc-4.8.1-obj/./gcc/lto-wrapper
Target: arm-none-eabi
Configured with: /Users/ardnew/cross/src/gcc-4.8.1/configure --target=arm-none-eabi --prefix=/Users/ardnew/cross --with-cpu=cortex-a8 --enable-languages=c,ada --disable-multilib --enable-interwork --disable-threads --disable-shared --disable-nls --disable-lto --disable-libssp --disable-decimal-float --disable-libgomp --disable-libmudflap
configure:2351: $? = 0
xgcc: error: unrecognized command line option '-qversion'
xgcc: fatal error: no input files
compilation terminated.
configure:2351: $? = 1
configure:2371: checking for C compiler default output file name
configure:2393: /Users/ardnew/cross/src/gcc-4.8.1-obj/./gcc/xgcc -B/Users/ardnew/cross/src/gcc-4.8.1-obj/./gcc/ -B/Users/ardnew/cross/arm-none-eabi/bin/ -B/Users/ardnew/cross/arm-none-eabi/lib/ -isystem /Users/ardnew/cross/arm-none-eabi/include -isystem /Users/ardnew/cross/arm-none-eabi/sys-include -g -O2 conftest.c >&5
/Users/ardnew/cross/arm-none-eabi/bin/ld: cannot find crt0.o: No such file or directory
/Users/ardnew/cross/arm-none-eabi/bin/ld: cannot find -lg
/Users/ardnew/cross/arm-none-eabi/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
configure:2397: $? = 1
configure:2434: result:
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2440: error: in `/Users/ardnew/cross/src/gcc-4.8.1-obj/arm-none-eabi/libada':
configure:2444: error: C compiler cannot create executables
See `config.log' for more details.
So at this point I'm way over my head and not really sure what to do next. It looks like I'm missing a C runtime library for ARM maybe?
Any help configuring GNAT/libada for ARM targets would be great.
Alternatively- is there a simpler way to link against Ada libraries from an Xcode iOS project?
Unfortunately, the answer is that there is no auto-magic tool to accomplish this. You can use tooling to validate the translations after the fact, but what you want isn't available yet.
I've had to deal with this same question in the past. A different answer would have dramatically changed one of my project's budgets, too. Perhaps someday.
Though I admit, I think there are ultimately enough incompatibilities that your source would need to be drastically altered - reducing the value of what you are looking to achieve here. In the end, the new investment is a bummer but will result in better source, if you can afford it.
Related
Although High Sierra is no longer supported by Homebrew, but I need to install llvm#13 formula as a dependency for other formulas. So I tried to install it this way:
$ brew install llvm
...
==> Downloading https://github.com/llvm/llvm-project/releases/download/llvmorg-13.0.0/llvm-project-13.0.0.src.tar.xz
Already downloaded: /Users/username/Library/Caches/Homebrew/downloads/8fd68fc8f968137c5080826db6e58682326235960fd8469363eb27d0799978ca--llvm-project-13.0.0.src.tar.xz
...
==> Installing llvm
==> cmake -G Unix Makefiles .. -DLLVM_ENABLE_PROJECTS=clang;clang-tools-extra;lld;lldb;mlir;polly -DLLVM_ENABLE_RUNTIMES=compiler-rt;libcxx;libcxxabi;libunwind;openmp -DLLVM_POLLY_L
==> cmake --build .
...
[ 79%] Built target lldELF
make: *** [all] Error 2
An error is occurred after a long time of compilation. I also found this error in ~/Library/Logs/Homebrew/llvm/02.cmake:
/tmp/llvm-20211109-12151-m0zvtm/llvm-project-13.0.0.src/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm:246:52: error: use of undeclared identifier 'CPU_SUBTYPE_ARM64E'
if (cputype == CPU_TYPE_ARM64 && cpusubtype == CPU_SUBTYPE_ARM64E) {
^
1 error generated.
make[2]: *** [tools/lldb/source/Host/macosx/objcxx/CMakeFiles/lldbHostMacOSXObjCXX.dir/HostInfoMacOSX.mm.o] Error 1
make[1]: *** [tools/lldb/source/Host/macosx/objcxx/CMakeFiles/lldbHostMacOSXObjCXX.dir/all] Error 2
How can I fix that compilation error?
Install llvm with debug mode enabled:
$ brew install --debug llvm
Installation process encounters with the same error mentioned in the question, but some options are provided to fix the issue. Choose option 5:
- raise
- ignore
- backtrace
- irb
- shell
Choose an action: 5
It gives a shell access to the current build directory of llvm formula. Find the current folder:
$ pwd
/private/tmp/llvm-20211109-12151-m0zvtm/llvm-project-13.0.0.src
Change the location to the build directory:
cd llvm/build
Edit the HostInfoMacOSX.mm and remove the second part of condition:
vi ../../lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm
You need to change the line 246 from:
if (cputype == CPU_TYPE_ARM64 && cpusubtype == CPU_SUBTYPE_ARM64E) {
to:
if (cputype == CPU_TYPE_ARM64) {
Then re-run the last command:
$ cmake --build .
It takes some time to be completed:
...
[100%] Linking CXX executable ../../../../bin/lldb-vscode
cd /tmp/llvm-20211109-12151-m0zvtm/llvm-project-13.0.0.src/llvm/build/tools/lldb/tools/lldb-vscode && /usr/local/Cellar/cmake/3.21.4/bin/cmake -E cmake_link_script CMakeFiles/lldb-v
scode.dir/link.txt --verbose=1
/usr/local/Homebrew/Library/Homebrew/shims/mac/super/clang++ -stdlib=libc++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wn
o-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-c
lass-memaccess -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wno-deprecated-declarations -Wno-unkn
own-pragmas -Wno-strict-aliasing -Wno-deprecated-register -Wno-vla-extension -O3 -DNDEBUG -Wl,-search_paths_first -Wl,-headerpad_max_install_names -stdlib=libc++ -Wl,-sectcreate,__
TEXT,__info_plist,/tmp/llvm-20211109-12151-m0zvtm/llvm-project-13.0.0.src/llvm/build/tools/lldb/tools/lldb-vscode/lldb-vscode-Info.plist -Wl,-dead_strip CMakeFiles/lldb-vscode.dir/
lldb-vscode.cpp.o CMakeFiles/lldb-vscode.dir/BreakpointBase.cpp.o CMakeFiles/lldb-vscode.dir/ExceptionBreakpoint.cpp.o CMakeFiles/lldb-vscode.dir/FifoFiles.cpp.o CMakeFiles/lldb-vsc
ode.dir/FunctionBreakpoint.cpp.o CMakeFiles/lldb-vscode.dir/IOStream.cpp.o CMakeFiles/lldb-vscode.dir/JSONUtils.cpp.o CMakeFiles/lldb-vscode.dir/LLDBUtils.cpp.o CMakeFiles/lldb-vsco
de.dir/OutputRedirector.cpp.o CMakeFiles/lldb-vscode.dir/ProgressEvent.cpp.o CMakeFiles/lldb-vscode.dir/RunInTerminal.cpp.o CMakeFiles/lldb-vscode.dir/SourceBreakpoint.cpp.o CMakeFi
les/lldb-vscode.dir/VSCode.cpp.o -o ../../../../bin/lldb-vscode -Wl,-rpath,#loader_path/../lib ../../../../lib/liblldb.13.0.0.dylib -lpthread ../../../../lib/libclang-cpp.dylib ../
../../../lib/libLLVM.dylib
[100%] Built target lldb-vscode
/usr/local/Cellar/cmake/3.21.4/bin/cmake -E cmake_progress_start /tmp/llvm-20211109-12151-m0zvtm/llvm-project-13.0.0.src/llvm/build/CMakeFiles 0
Then run the install command:
$ cmake --build . --target install
The tail of the result should be:
...
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/lib/cmake/llvm/./CheckAtomic.cmake
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/lib/cmake/llvm/./FindSphinx.cmake
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/lib/cmake/llvm/./FindGRPC.cmake
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/lib/cmake/llvm/./TableGen.cmake
Execute the last command:
$ cmake --build . --target install-xcode-toolchain
The tail of the results should be:
...
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/Toolchains/LLVM13.0.0.xctoolchain//usr/lib/cmake/llvm/./CheckAtomic.cmake
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/Toolchains/LLVM13.0.0.xctoolchain//usr/lib/cmake/llvm/./FindSphinx.cmake
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/Toolchains/LLVM13.0.0.xctoolchain//usr/lib/cmake/llvm/./FindGRPC.cmake
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/Toolchains/LLVM13.0.0.xctoolchain//usr/lib/cmake/llvm/./TableGen.cmake
Built target install-xcode-toolchain
/usr/local/Cellar/cmake/3.21.4/bin/cmake -E cmake_progress_start /tmp/llvm-20211109-12151-m0zvtm/llvm-project-13.0.0.src/llvm/build/CMakeFiles 0
Then press control+d to return to debug menu. Because the two last commands were run manually, you need to ignore the rest of errors by choosing the option 2:
- raise
- ignore
- backtrace
- irb
- shell
Choose an action: 2
==> cmake --build . --target install
...
cmake
--build
.
--target
install
Error: could not load cache
BuildError: Failed executing: cmake --build . --target install
1. raise
2. ignore
3. backtrace
4. irb
5. shell
Choose an action: 2
==> cmake --build . --target install-xcode-toolchain
...
cmake
--build
.
--target
install-xcode-toolchain
Error: could not load cache
BuildError: Failed executing: cmake --build . --target install-xcode-toolchain
1. raise
2. ignore
3. backtrace
4. irb
5. shell
Choose an action: 2
It will continue to install to the rest:
==> Fixing /usr/local/Cellar/llvm/13.0.0_1/bin/FileCheck permissions from 755 to 555
==> Fixing /usr/local/Cellar/llvm/13.0.0_1/bin/analyze-build permissions from 755 to 555
...
==> Changing dylib ID of /usr/local/Cellar/llvm/13.0.0_1/lib/libunwind.1.0.dylib
from #rpath/libunwind.1.dylib
to /usr/local/opt/llvm/lib/libunwind.1.dylib
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FromPathLoader): loading /usr/local/opt/llvm/.brew/llvm.rb
==> Caveats
To use the bundled libc++ please add the following LDFLAGS:
LDFLAGS="-L/usr/local/opt/llvm/lib -Wl,-rpath,/usr/local/opt/llvm/lib"
llvm is keg-only, which means it was not symlinked into /usr/local,
because macOS already provides this software and installing another version in
parallel can cause all kinds of trouble.
If you need to have llvm first in your PATH, run:
echo 'export PATH="/usr/local/opt/llvm/bin:$PATH"' >> ~/.zshrc
For compilers to find llvm you may need to set:
export LDFLAGS="-L/usr/local/opt/llvm/lib"
export CPPFLAGS="-I/usr/local/opt/llvm/include"
==> Summary
🍺 /usr/local/Cellar/llvm/13.0.0_1: 10,907 files, 1.8GB, built in 1418 minutes 39 seconds
It can be verified this way, the default llvm#10 pre-installed:
$ /usr/bin/clang --version
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
And the new Homebrew version of llvm#13:
$ /usr/local/opt/llvm/bin/clang --version
Homebrew clang version 13.0.0
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /usr/local/opt/llvm/bin
#HamidRohani provides a great solution for those still tinkering in High Sierra (10.13). Getting a recent version of LLVM to compile on my old MAC with an older XCode (clang version 10.0.1 in my case) was a great help. My nominal contribution...
Alternatively, you could define the symbol after line 41 in HostInfoMacOSX.mm:
// Kludge: Symbol definition extracted from a modern machine.h
#ifndef CPU_SUBTYPE_ARM64E
# define CPU_SUBTYPE_ARM64E ((cpu_subtype_t) 2)
#endif
Now, there's no need to modify line 246. And the definition would resolve any (possible) subsequent references. And let me aggregate the steps shown above conducted in brew's debug-shell:
cmake . -DLLVM_CREATE_XCODE_TOOLCHAIN=On
cmake --build .
cmake --build . --target install
cmake --build . --target install-xcode-toolchain
Regarding the LLVM-related variable, setting LLVM_CREATE_XCODE_TOOLCHAIN to On directs CMake to generate a target named 'install-xcode-toolchain'. 1 The target is a work-around to System Integrity Protection (SIP); "Xcode toolchains are a mostly-undocumented feature that allows multiple copies of low level tools to be installed to different locations, and users can easily switch between them." 2
Brew's Caveats
Brew gives you few caveats necessary to use the new compiler: "because macOS already provides this software and installing another version in parallel can cause all kinds of trouble." To use your new compiler, "You need to have llvm first in your PATH and for compilers to find llvm you may need to set" LDFLAGS and CDFLAGS. But since these gems-of-wisdom appear near the end of a million-lines of output, let me re-iterate here:
export PATH="/usr/local/opt/llvm/bin:$PATH"
export LDFLAGS="-L/usr/local/opt/llvm/lib"
export CPPFLAGS="-I/usr/local/opt/llvm/include"
Setting PATH is straight forward. I however, didn't need to set LDFLAGS or CPPFLAGS. Further, no joy with this additional caveat, "To use the bundled libc++ please add the following LDFLAGS":
export LDFLAGS="-L/usr/local/opt/llvm/lib -Wl,-rpath,/usr/local/opt/llvm/lib"
Anyway, moving on... To demonstrate that all's good, a C++ foo program that incorporates <filesystem>; a library not in High Sierra:
#include <iostream>
// C++17: Modern C++ compiler has std filesystem
#include <filesystem>
namespace fs = std::filesystem;
typedef std::filesystem::path my_path;
using namespace std;
int main ()
{
fs::path path{"/tmp"};
path /= "foo.txt";
ofstream ofs(path);
ofs << "Hello World." << endl;
ofs.close();
return 0;
}
Clearly, a nonsensical program, But to compile:
unset CPPFLAGS
unset LDFLAGS
clang++ -std=c++17 -L/usr/local/opt/llvm/lib foo.cpp -o foo
Again, showing That I didn't need CPPFLAGS and LDFLAGS. And so, The executable links to the correct libc++ library:
MacIntel:c++fs mjo$ otool -L foo
foo:
/usr/local/opt/llvm/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)
Enjoy.
Issue: Problem compiling bitcoin source code from https://github.com/bitcoin/bitcoin
Building bitcoin code requires Berkeley DB 4.8( https://github.com/tinybike/get-bdb-4.8).
No problem with that.
My system is running on Ubuntu 20.04.
$ cpp --version
cpp (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 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.
$ gcc --version
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 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.
$ g++ --version
g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 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.
When compiling the bitcoin code, after running 'configure' and 'make' an error occurs indicating that it could not find iostream.h
...
CXX libbitcoin_server_a-txrequest.o
CXX libbitcoin_server_a-txmempool.o
CXX libbitcoin_server_a-validation.o
CXX libbitcoin_server_a-validationinterface.o
CXX libbitcoin_server_a-versionbits.o
CXX wallet/libbitcoin_server_a-init.o
In file included from ./wallet/bdb.h:27,
from wallet/init.cpp:19:
/bitcoin/src/bdb/build_unix/build/include/db_cxx.h:59:10: fatal error: iostream.h: No such file or directory
59 | #include <iostream.h>
| ^~~~~~~~~~~~
compilation terminated.
make[2]: *** [Makefile:8933: wallet/libbitcoin_server_a-init.o] Error 1
make[2]: Leaving directory '/bitcoin/src'
make[1]: *** [Makefile:15214: all-recursive] Error 1
make[1]: Leaving directory '/bitcoin/src'
make: *** [Makefile:809: all-recursive] Error 1
On examining the header files location /usr/include/c++/9 I could not locate iostream.h
Is this a compiler package issue or bitcoin not using c++ iostream header file
I would guess you tried to build the "depends" BDB before installing the required system packages, and that produced an invalid/unusuable build.
Try removing your current "depends" builds and doing them over.
Alternatively, you could just use my db48 PPA for Ubuntu: https://launchpad.net/~luke-jr/+archive/ubuntu/db48
i got the same error,but it came when i build zero-ice with berkeley db. I found some usages about libdb and most of them add #define HAVE_CXX_STDHEADERS at the begining of codes, so i tried add this definition in ICEDIR/cpp/include/IceUtil/Config.h. It works.Wish it works for you.
something was completely wrong during db4.8 compilation
but as temporary fix, you may add in
include/db_cxx.h
#define HAVE_CXX_STDHEADERS 1
this may help, but depends.
imho
most correct way to build db-4.8 for bitcoin
wget http://download.oracle.com/berkeley-db/db-4.8.30.NC.tar.gz
tar zxvf db-4.8.30.NC.tar.gz
cd db-4.8.30.NC
build_unix/
../dist/configure --prefix=/usr/local/db48 --enable-cxx --with-pic --disable-replication --disable-shared
make install
cd ../bitcoin-x.x
export BDB_PREFIX=/usr/local/db48
export BDB_LIBS="-L/usr/local/db48/lib -ldb_cxx-4.8"
export BDB_CFLAGS="-I/usr/local/db48/include"
./configure
and etc.
I am trying to build LLVM compilers so that I can enable OpenMP on the Apple M1.
I am using the LLVM development tree, (since I saw some OpenMP runtime go into that for this recently).
I have ended up with this script to invoke cmake:
# Xcode, Ninja
BUILD_SYSTEM=Ninja
BUILD_TAG=Ninja
cmake ../llvm \
-G$BUILD_SYSTEM -B ${BUILD_TAG}_build \
-DCMAKE_OSX_ARCHITECTURES='arm64' \
-DCMAKE_C_COMPILER=`which clang` \
-DCMAKE_CXX_COMPILER=`which clang++` \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_BUILD_WITH_INSTALL_RPATH=1 \
-DCMAKE_INSTALL_PREFIX=$HOME/software/clang-12.0.0/arm64 \
-DLLVM_ENABLE_WERROR=FALSE \
-DLLVM_TARGETS_TO_BUILD='AArch64' \
-DLLVM_ENABLE_PROJECTS='clang;openmp,polly' \
-DLLVM_DEFAULT_TARGET_TRIPLE='aarch64-apple-darwin20.1.0'
The compilers used here are
$ /usr/bin/clang --version
Apple clang version 12.0.0 (clang-1200.0.32.27)
Target: arm64-apple-darwin20.1.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
ninja can then successfully build clang, clang++ and the OpenMp runtime and install them. (As simple, Arm64 images targeting Arms64)
$ file ~/software/clang-12.0.0/arm64/bin/clang
/Users/jcownie/software/clang-12.0.0/arm64/bin/clang: Mach-O 64-bit executable arm64
$ ~/software/clang-12.0.0/arm64/bin/clang --version
clang version 12.0.0 (https://github.com/llvm/llvm-project.git 879c15e890b4d25d28ea904e92497f091f796019)
Target: aarch64-apple-darwin20.1.0
Thread model: posix
InstalledDir: /Users/jcownie/software/clang-12.0.0/arm64/bin
Which all looks sane, except that when I try to compile anything with them they are missing the include path to get system headers.
$ ~/software/clang-12.0.0/arm64/bin/clang hello.c
hello.c:1:10: fatal error: 'stdio.h' file not found
#include <stdio.h>
^~~~~~~~~
1 error generated.
So, after all that,
Does anyone know how to fix that include path problem?
Does anyone know how to configure and build a fat binary for the compilers (and libraries) so that the x86_64 embedded compiler targets x86_64 and the aarch64 binary aarch64? (This is what the Xcode clang and clang++ do...)
My attempt at this ended up with a compiler fat binary where both architectures targeted x86_64 :-(
Thanks
You can set -DDEFAULT_SYSROOT=/path/to/MacOSX11.1.sdk at build time or do export SDKROOT=/path/to/MacOSX11.1.sdk at runtime.
You need to compile with clang -arch arm64 -arch x86_64 to get a fat binary out of clang. You need to do this for Apple clang as well.
UPDATED 8 Feb 2021
Homebrew now supports the M1 based Arm machines, so using that is a better answer than the one below.
The info below is potentially still useful if you want to do this on your own, but using brew is likely to be much simpler.
Pre-brew answer
I haven't found a clean solution, but in case it helps anyone else, I do have a horrible hack.
The full recipe, then is configure with this script, then build and install.
# Xcode, Ninja
BUILD_SYSTEM=Ninja
BUILD_TAG=ninja
INSTALLDIR=$HOME/software/clang-12.0.0/arm64
cmake ../llvm \
-G$BUILD_SYSTEM -B ${BUILD_TAG}_build \
-DCMAKE_OSX_ARCHITECTURES='arm64' \
-DCMAKE_C_COMPILER=`which clang` \
-DCMAKE_CXX_COMPILER=`which clang++` \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=$INSTALLDIR \
-DLLVM_LOCAL_RPATH=$INSTALLDIR/lib \
-DLLVM_ENABLE_WERROR=FALSE \
-DLLVM_TARGETS_TO_BUILD='AArch64' \
-DLLVM_DEFAULT_TARGET_TRIPLE='aarch64-apple-darwin20.1.0' \
-DDEFAULT_SYSROOT="$(xcrun --show-sdk-path)" \
-DLLVM_ENABLE_PROJECTS='clang;openmp;polly;clang-tools-extra;libcxx;libcxxabi' \
# -DLLVM_ENABLE_PROJECTS='clang;openmp;polly'
That gives a compiler that finds the right headers, but won't link successfully if OpenMP is used because it doesn't pass on any useful -L path or add a necessary rpath.
To overcome that I created a small shell script that sits in my ~/bin, at the front of my $PATH, which adds those extra linker flags.
#
# A truly awful hack, but it seems necessary.
# Install this with execute permissions as clang and clang++ in
# a directory early in your path, so that it is executed when clang or
# clang++ is needed.
#
# For brew...
INSTALLDIR=/usr/local/opt/llvm
# For a local build.
INSTALLDIR=${HOME}/software/clang-12.0.0/arm64/
# Find out the name of this file, and then invoke the same file in the
# compiler installation, adding the necessary linker directives
CMD=`echo $0 | sed "s/\/.*\///"`
${INSTALLDIR}/bin/${CMD} -L${INSTALLDIR}/lib -Wl,-rpath,${INSTALLDIR}/lib $*
I am not recommending this particularly; there should clearly be a better way to make it work, but it'll do for now, and lets me get back to using the compiler rather than building it!
I was able to build with -DDEFAULT_SYSROOT="$(xcrun --show-sdk-path)" -DCMAKE_INSTALL_PREFIX=/Users/foo/lokal/ and install into the lokal/bin lokal/lib path. Once that is done you can use LD_LIBRARY_PATH=/Users/foo/lokal/lib and all the libraries should be found without mucking with anything else rpath related.
I would like to have complete Win32 development toolchain without Microsoft SDKs. mingw64 works, but its linker is very slow. As an alternative, I am trying to use clang for windows. I can get clang 7.0.1 (but not 8.0.0) work with mingw headers/libraries, however only using mingw's ld.exe. If I force ldd.exe to be used (-fuse-ld=lld), everything compiles and links fine, but the application immediately crashes when started. Is there anything I can do here, like change something in the commandline?
This is how commandline and --verbose for the link step looks like:
Linking...
clang++ -static -o "C:\upp\out\MyApps\CLANG.Debug.Debug_Full\main.exe"
-ggdb -L"C:\upp\bin/mingw64/64/x86_64-w64-mingw32/lib"
-L"C:\uppbin/mingw64/64/opt/lib" -L"C:\upp\bin/SDL2/lib/x64"
-L"C:\upp\bin/pgsql/x64/bin"
-L"C:\upp\bin/mysql/lib64"
-Wl,--stack,20000000 --verbose -target x86_64-pc-windows-gnu
-fuse-ld=lld
"C:/upp/out/MyApps/main/CLANG.Debug.Debug_Full.Main\main.o"
-Wl,--start-group -Wl,--end-group
clang version 7.0.1 (tags/RELEASE_701/final)
Target: x86_64-pc-windows-gnu
Thread model: posix
InstalledDir: C:\xxx\LLVM2\bin
"C:\\xxx\\LLVM2\\bin\\ld.lld" -m i386pep -Bstatic
-o "C:\\upp\\out\\MyApps\\CLANG.Debug.Debug_Full\\main.exe"
"C:\\upp\\bin\\mingw64\\64\\x86_64-w64-mingw32\\lib\\crt2.o"
"C:\\upp\\bin\\mingw64\\64\\lib\\gcc\\x86_64-w64-mingw32\\8.1.0\\crtbegin.o"
"-LC:\\upp\\bin/mingw64/64/x86_64-w64-mingw32/lib"
"-LC:\\upp\\bin/mingw64/64/opt/lib"
"-LC:\\upp\\bin/SDL2/lib/x64" "-LC:\\upp\\bin/pgsql/x64/bin"
"-LC:\\upp\\bin/mysql/lib64"
"-LC:\\upp\\bin\\mingw64\\64\\lib\\gcc\\x86_64-w64-mingw32\\8.1.0"
"-LC:\\upp\\bin\\mingw64\\64\\x86_64-w64-mingw32\\lib"
"-LC:\\upp\\bin\\mingw64\\64\\lib"
"-LC:\\upp\\bin\\mingw64\\64\\x86_64-w64-mingw32/sys-root/mingw/lib"
--stack 20000000
"C:/upp/out/MyApps/main/CLANG.Debug.Debug_Full.Main\\main.o"
--start-group --end-group -lstdc++ --start-group -lmingw32
-lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32
-luser32 -lkernel32 --end-group
"C:\\upp\\bin\\mingw64\\64\\lib\\gcc\\x86_64-w64-mingw32\\8.1.0\\crtend.o"
The llvm-mingw toolchain is very easy to use and provides latest clang / libc++ / lld without any dependency on the Microsoft headers: https://github.com/mstorsjo/llvm-mingw
It links against the Microsoft ucrt and as such is compatible with MSVC-built DLLs (for the C API / ABI, not the C++ since it uses a different standard library implementation)
I tried this:
Alan#Alan ~/mercury
$ gfortran -o mercury6_2.for
gfortran.exe: fatal error: no input files; unwilling to write output files
compilation terminated
and:
Alan#Alan ~/mercury
$ gfortran -o mercury mercury6_2.for
gfortran.exe: error: CreateProcess: No such file or directory
My file exist:
Alan#Alan ~/mercury
$ ls
big.in element.in mercury.inc mercury6_2.for README.txt
close.in element6.for mercury6.man message.in small.in
close6.for files.in mercury6.tar param.in swift.incenter code here
gfortran seems to be running in Cygwin:
Alan#Alan ~/mercury
$ gfortran --version
GNU Fortran (GCC) 4.8.0 20130302 (experimental) [trunk revision 196403]
Copyright (C) 2013 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
So I don't know.
Is there away that I could do this differently?