Hi Jürgen and all:
I’ve got some more information relating to this issue. Sorry it’s lengthy.
Where do I go from here?
How do I set things up so that configure uses the Apple libtool and not the
Debian one?
I’d like to do that a see if it works…. But Autotools is my nemesis at the
moment…..
(1) When the GNU apl project is checked out from svn there is no libtool script
at the top level build dir
(2) After doing ./configure there is a libtool script in that dir.
It is generated from the /m4/libtool.ma <http://libtool.ma/> script.
Doing a /src/libtool —help gives the following:
When reporting a bug, please describe a test case to reproduce it and
include the following information:
host-triplet: i386-apple-darwin14.5.0
shell: /bin/sh
compiler: gcc
compiler flags: -g -O2
linker:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
(gnu? no)
libtool: (GNU libtool) 2.4.2 Debian-2.4.2-1.7ubuntu1
automake:
autoconf:
So we have a Debian libtool and an Apple linker.
The Apple libtool produces this
Gandalf:~ pteeson$ /usr/bin/libtool -V
Apple Inc. version cctools-870
What’s more the Debian libtool does not support the required args for an Apple
dynamic lib.
(3) Here’s what man libtool says about dynamically linked libraries:
DYNAMICALLY LINKED SHARED LIBRARIES
Dynamically linked libraries, unlike statically linked libraries, are
Mach-O format files and not ar(5) format files. Dynamically linked
libraries have two restrictions: No symbol may be defined in more than
one object file and no common symbol can be used. To maximize sharing
of a dynamically linked shared library the objects should be compiled
with the -dynamic flag of cc(1) to produce indirect undefined refer-
ences and position-independent code. To build a dynamically linked
library, libtool, runs the link editor, ld(1), with -dylib once for
each architecture present in the input objects and then lipo(1) to cre-
ate a universal file if needed.
> On Jun 15, 2018, at 1:25 PM, Peter Teeson <peter.tee...@icloud.com> wrote:
>
> Hi Jürgen:
>
> I notice that configure.ac has LT_INIT([dlopen]).
> Would this be the best place to add additional args for libtool to
> override/replace the default ones?
>
> Earlier Alexy mentioned:
>> Last time I had a similar problem I had to run
>> autoconf/autoreconf/something like this to regenerate configure on OSX.
>
> Maybe there is an easier way.
>
> I’m going to look into how I can link from the Terminal.
> But I don’t feel like typing all the names. Just want to do something like ld
> /src/libapl*.o or whatever is the correct syntax.
> Right now I am studying the stdout from Make trying to understand the args to
> libtool mode=link.
>
> respect…
>
> Peter
>> On Jun 15, 2018, at 5:20 AM, Juergen Sauermann
>> <juergen.sauerm...@t-online.de> wrote:
>>
>> Hi Xiao-Yong,
>>
>> thanks for explaining this.
>>
>> /// Jürgen
>>
>>
>> On 06/13/2018 09:59 PM, Xiao-Yong Jin 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
>>>> <juergen.sauerm...@t-online.de> <mailto: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
>>>> <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> <mailto: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$
>>>>>> <mailto: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>
>>>>>>>> <mailto: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
>>>>>>>> <https://github.com/dlaurie/lua-gnuapl>
>>
>
