Gandalf:~ pteeson$ cd
/Volumes/Data/Development/apl-1053\ after\ Make/src
Gandalf:src pteeson$ cat libapl_test.c
#include "libapl.h"
int
main(int argc, char * argv[])
{
init_libapl(argv[0], 0);
return apl_exec("⎕←2 3 ⍴⍳6");
}
Gandalf:src pteeson$ gcc -o libapl_test
libapl_test.c -L .libs -lapl
ld: can't link with bundle (MH_BUNDLE) only
dylibs (MH_DYLIB) file '.libs/libapl.so' for architecture
x86_64
clang: error: unable to execute command:
Segmentation fault: 11
clang: error: linker command failed due to
signal (use -v to see invocation)
==========================
I also ran the command with the -v option and
this is what was produced:
I understand everything below. Just don’t know
how to fix libtool for macOS
This is the key line with the args to ld:
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld"
-demangle -dynamic -arch x86_64 -macosx_version_min
10.10.0 -o libapl_test -L.libs
>>>>>>>>>>>>>>>>>
Gandalf:src pteeson$ gcc -v -o libapl_test
libapl_test.c -L .libs -lapl
Apple LLVM version 6.1.0 (clang-602.0.53)
(based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.5.0
Thread model: posix
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
-cc1 -triple x86_64-apple-macosx10.10.0 -emit-obj
-mrelax-all -disable-free -disable-llvm-verifier
-main-file-name libapl_test.c -mrelocation-model pic
-pic-level 2 -mdisable-fp-elim -masm-verbose
-munwind-tables -target-cpu core2 -target-linker-version
242.2 -v -dwarf-column-info -resource-dir
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0
-fdebug-compilation-dir
/Volumes/Data/Development/apl-1053 after Make/src
-ferror-limit 19 -fmessage-length 139 -stack-protector 1
-mstackrealign -fblocks -fobjc-runtime=macosx-10.10.0
-fencode-extended-block-signature -fmax-type-align=16
-fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/w1/081y692x5x30c39mcr8lxwkh0000gn/T/libapl_test-2b7dfd.o
-x c libapl_test.c
clang -cc1 version 6.1.0 based upon LLVM
3.6.0svn default target x86_64-apple-darwin14.5.0
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/usr/include
/System/Library/Frameworks (framework
directory)
/Library/Frameworks (framework directory)
End of search list.
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld"
-demangle -dynamic -arch x86_64 -macosx_version_min
10.10.0 -o libapl_test -L.libs
/var/folders/w1/081y692x5x30c39mcr8lxwkh0000gn/T/libapl_test-2b7dfd.o
-lapl -lSystem
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0/lib/darwin/libclang_rt.osx.a
ld: can't link with bundle (MH_BUNDLE) only
dylibs (MH_DYLIB) file '.libs/libapl.so' for
architecture x86_64
clang: error: linker command failed with
exit code 1 (use -v to see invocation)
On Jun 13, 2018, at 1:58 PM, Juergen
Sauermann <
address@hidden>
wrote:
Hi
Peter,
a simple C program, say libapl_test.c
would be this:
#include "libapl.h"
int
main(int argc, char * argv[])
{
init_libapl(argv[0], 0);
return apl_exec("⎕←2 3⍴⍳6");
}
Compile it in src
like so:
gcc -o libapl_test
libapl_test.c -L .libs -lapl
Executing it gives:
address@hidden:~/projects/juergen/apl-1.7/src$
./libapl_test
1 2 3
4 5 6
/// Jürgen
On 06/13/2018 05:34 PM,
Peter Teeson wrote:
Hi Dirk:
Please tell me what OS you were using?
thanks….
Peter
On May 20, 2018, at 4:59 PM, Dirk Laurie <address@hidden> wrote:
I did this three years ago, using SVN 570 of GNU APL. In an ideal
world, I would have checked after every SVN update that my application
still works. In the real world, I have not touched it since and cannot
remember much. :-(
I currently have SVN 1048. When I tried it my application [1] (which
runs GNU APL in parallel with Lua) just now, the Lua 5.2 version that
I made on 29 May 2015 still works in a simple test.
$ lua -l gnuapl
Lua 5.3.4 Copyright (C) 1994-2017 Lua.org, PUC-Rio
…/gnuapl$ lua5.2 -l gnuapl
Lua 5.2.4 Copyright (C) 1994-2015 Lua.org, PUC-Rio
=gnuapl.exec"4 4⍴⍳16"
1 2 3 4
5 6 7 8
9 10 11 12
13 14 15 16
This seems to confirm that there is nothing wrong with libapl.so.
Unfortunately I have no simple C main program, since everything runs
through Lua. In particular, Lua's 'package.loadlib' function is used
to load the current libapl.so. The code for that function is way above
my code-reading ability.
Sorry that I can't offer more help.
-- Dirk
[1] Those that are reasonably fluent in Lua and its C API can try it
out: https://github.com/dlaurie/lua-gnuapl
signature.asc