[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-apl] libapl load problem....UPDATE 2
From: |
Xiao-Yong Jin |
Subject: |
Re: [Bug-apl] libapl load problem....UPDATE 2 |
Date: |
Wed, 13 Jun 2018 14:59:14 -0500 |
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
>>>
>>
>
- Re: [Bug-apl] libapl load problem....UPDATE 2, Peter Teeson, 2018/06/13
- Re: [Bug-apl] libapl load problem....UPDATE 2, Juergen Sauermann, 2018/06/13
- Re: [Bug-apl] libapl load problem....UPDATE 2, Peter Teeson, 2018/06/13
- Re: [Bug-apl] libapl load problem....UPDATE 2, Juergen Sauermann, 2018/06/13
- Re: [Bug-apl] libapl load problem....UPDATE 2,
Xiao-Yong Jin <=
- Re: [Bug-apl] libapl load problem....UPDATE 2, Juergen Sauermann, 2018/06/15
- Message not available
- Re: [Bug-apl] libapl load problem....UPDATE 5, Peter Teeson, 2018/06/17
- Re: [Bug-apl] libapl load problem....UPDATE 5 P.S., Peter Teeson, 2018/06/18
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Re: [Bug-apl] libapl load problem....UPDATE 7, Peter Teeson, 2018/06/29
- Re: [Bug-apl] libapl load problem....UPDATE 7, Juergen Sauermann, 2018/06/30
- Re: [Bug-apl] libapl load problem....UPDATE 8, Peter Teeson, 2018/06/30
- Re: [Bug-apl] libapl load problem....UPDATE 2, Peter Teeson, 2018/06/15