Hi Xiao-Yong Jin: Thanks for the information. Sorry for my late reply. Been studying and learning... Apple has some documentation and examples: <https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/000-Introduction/Introduction.html#//apple_ref/doc/uid/TP40001908-SW1 <https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/000-Introduction/Introduction.html#//apple_ref/doc/uid/TP40001908-SW1>> I’ve been working through them. Including the C++sample.
Autotools and friends is all new to me. How to figure out where to pass the correct args to libtool. In the libtool documentation there is a section, 6.1 item 2, saying use the compiler rather than the linker. How can I adjust things so that for macOS ./configure —with-libapl will pass the correct args to libtool? > On Jun 13, 2018, at 3:59 PM, Xiao-Yong Jin <[email protected]> wrote: > > 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 >> <[email protected]> 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 >>>> <[email protected]> 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 <[email protected]> >>>>>> 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 >>>> >>> >> >
