bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Teeson
Subject: Re: [Bug-apl] libapl load problem....UPDATE 2
Date: Fri, 15 Jun 2018 11:25:46 -0400

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]