my aim is to install cjson with luarocks on Windows 10 (64 Bit), what i've done so far:
Try the installation via make:
put this luajit installation on the path "C:\torch" and set all the following path variables manually (see issues)
Path = "C:\torch\bin;"%PATH%
LUA_CPATH="C:\torch\bin\?.dll;;"
LUA_DEV="C:\torch;"
LUA_PATH="C:\torch\lua\?;C:\torch\lua\?.lua;C:\torch\lua\?\init.lua;;"
put this version of lua-cjson-2.1.0 on the following folder: "C:\Users\username\Desktop\lua-cjson-2.1.0"
install mingw with make version 3.81, cmake 3.13.2 and add "C:\MinGW\msys\1.0\bin\" and "C:\Program Files\CMake\bin\" to the Path variable
uncomment variables for Windows(MingGW) and setting the PREFIX = C:\torch\ in the Makefile of lua-cjson-2.1.0
go via admin-shell to "C:\Users\username\Desktop\lua-cjson-2.1.0"
"make install" yields the following output:
cc -c -O3 -Wall -pedantic -DNDEBUG -IC:\torch CJSON_CFLAGS = -DDISABLE_INVALID_NUMBERS/include -fpic -o lua_cjson.o lua_cjson.c
make: cc: Command not found
make: *** [lua_cjson.o] Error 127`
Another try with luarocks doesn´t work too:
call ""C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64"
then call "luarocks make" as described in the cjson-manual
this yields the following output:
cl /nologo /MD /O2 -c -Folua_cjson.obj -IC:/torch/include lua_cjson.c -DDISABLE_INVALID_NUMBERS lua_cjson.c
cl /nologo /MD /O2 -c -Fostrbuf.obj -IC:/torch/include strbuf.c -DDISABLE_INVALID_NUMBERS strbuf.c
strbuf.c(98): warning C4311: "type conversion": pointer truncation from "strbuf_t *" to "long"
strbuf.c(172): warning C4311: "type conversion": pointer truncation from "strbuf_t *" to"long"
cl /nologo /MD /O2 -c -Fofpconv.obj -IC:/torch/include fpconv.c -DDISABLE_INVALID_NUMBERS fpconv.c
link -dll -def:cjson.def -out:cjson.dll C:/torch/lib/libluajit.lib lua_cjson.obj strbuf.obj fpconv.obj
Microsoft (R) Incremental Linker Version 14.10.25019.0
Copyright (C) Microsoft Corporation. All rights reserved.
Bibliothek "cjson.lib" und Objekt "cjson.exp" werden erstellt.
lua_cjson.obj : error LNK2019: Reference to unresolved external symbol "strncasecmp" in function "json_is_invalid_number".
cjson.dll : fatal error LNK1120: 1 nicht aufgelöste Externe
Error: Build error: Failed compiling module cjson.dll`
Whats wrong with the installation procedure?
Related
I am working on a C++ project with drake, using bazel as the build system. Previously, I use the drake source code as the external, following the drake_bazel_external example. Everything works fine.
Since I want to use the SNOPT solver in drake, I want to change to use the pre-compiled drake. I follow the drake_bazel_installed example. However, I got the following errors.
Compiling kuka/diffIK_controller.cc failed: (Exit 1): gcc failed: error executing command /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -g0 -O2 '-D_FORTIFY_SOURCE=1' -DNDEBUG -ffunction-sections ... (remaining 27 arguments skipped)
Use --sandbox_debug to see verbose messages from the sandbox
In file included from bazel-out/k8-opt/bin/external/drake/_virtual_includes/.drake_headers/drake/common/default_scalars.h:3,
from bazel-out/k8-opt/bin/external/drake/_virtual_includes/.drake_headers/drake/systems/framework/leaf_system.h:14,
from ./kuka/diffIK_controller.h:3,
from kuka/diffIK_controller.cc:3:
bazel-out/k8-opt/bin/external/drake/_virtual_includes/.drake_headers/drake/common/autodiff.h:12:10: fatal error: Eigen/Core: No such file or directory
12 | #include <Eigen/Core>
| ^~~~~~~~~~~~
compilation terminated.
I also find that the apps in the drake_bazel_external cannot be compiled successfully by drake_bazel_installed setting. The error message is
ERROR: error loading package 'app': Label '#drake//tools/skylark:py.bzl' is invalid because 'tools/skylark' is not a package; perhaps you meant to put the colon here: '#drake//:tools/skylark/py.bzl'?
Update
The bug can be produced by both the http_archive fetched drake and the apt installed drake (the latest stable drake I think, since I just installed it yesterday). I have isolated the relevant code to reproduce the bug in a github repo. Currently, I can get the original apps in drake_bazel_installed to work.
Update
By adding
# solve the eigen not found bug
build --cxxopt=-I/usr/include/eigen3
to the .bazelrc file, I can solve the above problem. However, when I try to build a program that uses iiwa_status_receiver.h, I encounter a new problem.
ERROR: /home/chenwang/repro_drake_bazel_external/drake_bazel_installed/apps/BUILD.bazel:102:10: Compiling apps/connection_test.cc failed: (Exit 1): gcc failed: error executing command /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -g0 -O2 '-D_FORTIFY_SOURCE=1' -DNDEBUG -ffunction-sections ... (remaining 32 arguments skipped)
Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
In file included from apps/connection_test.cc:10:
bazel-out/k8-opt/bin/external/drake/_virtual_includes/.drake_headers/drake/manipulation/kuka_iiwa/iiwa_status_receiver.h:6:10: fatal error: drake/lcmt_iiwa_status.hpp: No such file or directory
6 | #include "drake/lcmt_iiwa_status.hpp"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
INFO: Elapsed time: 2.967s, Critical Path: 0.24s
INFO: 2 processes: 2 internal.
FAILED: Build did NOT complete successfully
This problem is also a missing header file problem. I have update the github repo to reproduce this problem.
This is a bug in Drake (filed as https://github.com/RobotLocomotion/drake/issues/17965 now).
To work around it, pass --cxxopt=-I/usr/include/eigen3 on all of your bazel commands, e.g., by adding this line to your projects' .bazelrc file:
build --cxxopt=-I/usr/include/eigen3
Edit: The nightly builds of Apt packages as of 20220923 should have this fixed as well.
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.
I'm running into the following problem trying to cabal install reactive-banana-sdl:
c:/program files/haskell platform/7.10.2-a/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lSDL_ttf
collect2: ld returned 1 exit status
linking dist\build\Graphics\UI\SDL\TTF\Version_hsc_make.o failed (exit code 1)
command was: C:\Program Files\Haskell Platform\7.10.2-a\mingw\bin\gcc.exe dist\build\Graphics\UI\SDL\TTF\Version_hsc_make.o dist\build\Graphics\UI\SDL\TTF\Version_hsc_utils.o -o dist\build\Graphics\UI\SDL\TTF\Version_hsc_make.exe -LC:PFSDL_ttf-2.0.11-win32-x64 -lSDL_ttf -LC:\Users\Owner\AppData\Roaming\cabal\x86_64-windows-ghc-7.10.2\SDL-0.6.5.1-26jmephxohM5v84vz7MqXX -LC:/PF/sdl/lib -lSDL -L/mingw64/lib -lmingw32 -lSDLmain -lSDL -mwindows -LC:\Program Files\Haskell Platform\7.10.2-a\lib\base_GDytRqRVSUX7zckgKqJjgw -lwsock32 -luser32 -lshell32 -LC:\Program Files\Haskell Platform\7.10.2-a\lib\integ_2aU3IZNMF9a7mQ0OzsZ0dS -LC:\Program Files\Haskell Platform\7.10.2-a\lib\ghcpr_8TmvWUcS1U1IKHT0levwg3 -LC:\Program Files\Haskell Platform\7.10.2-a\lib/rts -lm -lwsock32 -lgdi32 -lwinmm
C:\Program Files\Haskell Platform\7.10.2-a\bin\hsc2hs.exe returned ExitFailure 1
Failed to install SDL-ttf-0.6.2.1
What do I do?
Some details: I'm using Windows 7, and doing this in MINGW64. I've installed sdl-ttf through pacman, downloaded SDL_ttf from https://www.libsdl.org/projects/SDL_ttf/release-1.2.html, and replaced SDL_platform.h (https://hg.libsdl.org/SDL/raw-file/e217ed463f25/include/SDL_platform.h) to fix another error ("winapifamily.h: No such file or directory" when compiling SDL in Code::Blocks). I made sure to include extra directories.
cabal install -v3 reactive-banana-sdl --extra-include-dirs=C:\PF\SDL_ttf-2.0.11-win32-x64 --extra-lib-dirs=C:\PF\SDL_ttf-2.0.11-win32-x64
I'm using Luarocks 2.2.0beta1 to install luafilesystem on windows 7 with lua 5.2 and mingw. I got this error:
>luarocks install luafilesystem
Installing http://rocks.moonscript.org/luafilesystem-1.6.2-2.src.rock...
Using http://rocks.moonscript.org/luafilesystem-1.6.2-2.src.rock... switching to 'build' mode
mingw32-gcc -O2 -c -o src/lfs.o -IC:/lua/include/src/lfs.c
mingw32-gcc -shared -o lfs.dll src/lfs.o C:/lua/bin/lua52.dll -lm
C:\lua\bin\lua52.dll: file not recognized: File format not recognized
collect2.exe: error: Id returned 1 exit status
Error: Build error: Failed compiling module lfs.dll
any idea how to fix this?
note: until now, I have no problem installing other module with luarocks that have no dependency with luafilesystem.
Solved, this problem arise because actually I'm not using the same MinGW compiler when building lua52.dll. I don't know which compiler I use at the first time. Thanks to #siffiejoe
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.