Re: [Bug-apl] libapl load problem....UPDATE 2

[Xiao-Yong Jin]

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 <address@hidden> 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 <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
>>> 
>> 
>