You need a dylib to link against at compile time. Passing `-dynamiclib` to the compiler should to the trick to generate a dylib. We need something like:
g++ -dynamiclib -o libapl.dylib all_the_o_files.o ... A bundle is what a so file is, which in general is generated by the compiler when `-bundle` is passed. My knowledge is still limited in this aspect, but I hope this helps. Best, Xiao-Yong > On Jun 13, 2018, at 2:49 PM, Juergen Sauermann > <juergen.sauerm...@t-online.de> wrote: > > Hi Peter, > > I don't know what a MH_BUNDLE vs. a MH_DYLIB is but meybe this helps: > > https://github.com/yallop/ocaml-ctypes-inverted-stubs-example/issues/4 > > /// Jürgen > > > On 06/13/2018 09:26 PM, Peter Teeson wrote: >> Hi Jürgen: >> Well that trivial program confirms my hypothesis which is that I am the >> first person to try using libapl on macOS. >> I have been doing similar things to your program using both the command >> line (Terminal) >> and also within Xcode (Apple’s GUI Developer tool). From my experiments I >> had concluded that libapl.so, >> which is a bundle, will not work on macOS. >> >> We need a dylib. What I have not yet fully figured out is how to change >> things for libtool so as to fix things. >> Not sure if I have to change the compile args or just the linker ones. >> My understanding is that the .o files are PIC and it is the linker which >> builds them into an image that's relocatable. >> >> For dynamic libs the linker jus puts a reference in the exec file to the >> library image but does not include it’s content in the exec. >> The dynamic loader will take care of that and also resolving addresses at >> launch time. >> >> =================== >> 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 >>> <juergen.sauerm...@t-online.de> 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: >>> >>> >>> eedjsa@server66:~/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 <dirk.lau...@gmail.com> >>>>> 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 >>> >> >
