Hi, Just to inform what I successfully resolved the issue by running aclocal, automake and autoconf and reconfiguring && building again.
Br, /Alexey Juergen Sauermann <[email protected]> writes: > Hi Alexey, > > GNU APL uses the C functions dlopen() to open the library and dlsym() to > locate functions > inside > the library. > > From the printout we see that GNU APL finds the library file but the dlopen() > of the existing file > fails. > > Although the dlopen() and dlsym() functions are quite standard among > different platforms, the > way > in which the dynamic library files are linked from the compiled object files > differs considerably > between > platforms. > > In this particular case there could be 2 reasons for dlopen() to fail: > > 1. a bug in the platform as one of the posts below suggests. Somebody who had > the same > problem (although > with a different library) has reported that after an OS-X update his problem > disappeared. > > 2. The library must be constructed in a specific way. On GNU/Linux this is > often properly handled > by libtool, > but I do not know if libtool even exists on OS-X and if it works properly. On > GNU/Linux there is > another > tool called libtoolize which prepares autoconf projects that do not use > libtoolize into projects > that do. > libtoolize does some magic to make shared library work and you may need to do > something > similar on > your box. > > My proposal would be: > > 1. upgrade your OS-X as proposed in the post below. > > 2. If that does not fix the problem then learn from your platform > documentation how shared > libraries > for use with dlopen() shall be built. And what namespaces are (they do not > exist on GNU/Linux). > > Good Luck! > /// Jürgen > > On 12/12/2017 12:27 PM, Alexey Veretennikov wrote: > > Hi, > > Could you please hint me how to specify these flags so I can experiment > myself? > > Br, > /Alexey > > 2017-12-11 16:19 GMT+01:00 Juergen Sauermann <[email protected]>: > > Hi Alexey, > > I suppose that you need some platform specific linker flags when building > libemacs.dylib. > Since I do not have access to a Mac OS-X machine, I can't tell you which > ones. > > Best Regards, > /// Jürgen > > On 12/06/2017 08:18 PM, Alexey Veretennikov wrote: > > It is really strange but reporting with otool shows two level: > > otool -hV /Users/alexey/Applications/gnu-apl/lib/apl/libemacs.dylib > /Users/alexey/Applications/gnu-apl/lib/apl/libemacs.dylib: > Mach header > magic cputype cpusubtype caps filetype ncmds sizeofcmds flags > MH_MAGIC_64 X86_64 ALL 0x00 DYLIB 14 2272 NOUNDEFS DYLDLINK > TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK NO_REEXPORTED_DYLIBS > > For flat libraries there should be no TWOLEVEL flag. > > Br, > /Alexey > > 2017-12-04 17:33 GMT+01:00 Juergen Sauermann > <[email protected]>: > > Hi, > > from the GNU APL printout it looks like the file was found, but something is > wrong with the file: > > file /Users/alexey/Applications/gnu-apl/lib/apl/libemacs.dylib ( flat > namespace > in /Users/alexey/Applications/gnu-apl/lib/apl/libemacs.dylib ) > > So GNU APL was able to open the file (using dlopen()) but then gets the > "flat namespace" error at some point. > > The second link below says: > > amandogra commented on Oct 2, 2016 > > It got solved by OS upgrade. > For someone who comes to this... > I was on Mac OSX El Capitan, but I upgraded to macOS Sierra. > Then, I executed the following command > > brew unlink libevent && brew link libevent > > This fixed my issue. > > The posting was related to a different library but the (rest of the) error > message looks very similar (considering > that GNU APL cuts off the start the error message text until the last : in > it). > The full error message was most likely: > Expected in: flat namespace > Maybe "nm -D" on the dylib file reveals some more information. > > Best Regards, > /// Jürgen > > On 12/04/2017 04:06 AM, Elias Mårtenson wrote: > > Perhaps adding the path to the dylib file in DYLIB_LIBRARY_PATH will > help? Don't forget to exprt the variable before starting apl. > > Regards, > Elias > > On 4 December 2017 at 01:56, Juergen Sauermann > <[email protected]> wrote: > > Hi, > > I haven't changed anything in that area. One poster in one of the > links below mentioned that an OS-X upgrade > had fixed a similar problem that the poster had, so my impression > is that this is a problem than cannot be fixed > inside GNU APL. > > Best Regards, > /// Jürgen > > On 12/03/2017 12:02 PM, Elias Mårtenson wrote: > > 10.6.8 is indeed very old. I thought my Macbook was old and > it's running 10.10. > > I have to admit that I haven't tried the Emacs mode on OSX in > a while since I don't use Macs anymore. That said, last time I > did try, it worked fine. > > Jürgen, could there be an issue with the way the libraries are > built? Did anything change in the last couple of years? > > Regards, > Elias > > On 3 December 2017 at 18:58, Juergen Sauermann > <[email protected]> wrote: > > Hi Alexey, > > I am not really familiar with emacs or OS X, so Elias is > probably better informed than me. > > Unfotunately shared libraries are rather platform > dependent and so are the error messages that > they produce. From the output below it seems that the > file libemacs.dylib exists and was found, > but could not be opened with dlopen(). It might be that > your platform needs additional linker flags > for dynamic libraries to work, but I have no idea which > ones. > > See also: > > https://github.com/tmux/tmux/issues/547 or > > > https://developer.apple.com/library/content/documentation/Porting/Conceptual/PortingUnix/compiling/compiling.html > > > Best Regards, > /// Jürgen > > On 11/30/2017 08:39 PM, Alexey Veretennikov wrote: > > Hi, > > I've built GNU APL with the following parameters on > my old (OSX 10.6.8) macbook: > > ./configure > --prefix=/Users/alexey/Applications/gnu-apl > make install > > So nothing special(I did a small change though > since strndup is not yet supported on this OS). I'm > using gcc 7.2.0. > However when I try to run apl from emacs, I get the > following error: > > Could not find shared library 'libemacs' > The following directories and file names were tried: > file > /Users/alexey/Applications/gnu-apl/lib/apl/libemacs.so > (No such file or directory) > file > /Users/alexey/Applications/gnu-apl/lib/apl/libemacs.dylib > ( flat namespace > in > /Users/alexey/Applications/gnu-apl/lib/apl/libemacs.dylib > ) > file > /Users/alexey/Applications/gnu-apl/lib/apl/libemacs > (No such file or directory) > directory /usr/lib/apl > directory /usr/local/lib/apl > file ./libemacs.so (No such file or directory) > file ./libemacs.dylib (No such file or directory) > file ./libemacs (No such file or directory) > directory ./native > directory ./emacs_mode > > The file > /Users/alexey/Applications/gnu-apl/lib/apl/libemacs.dylib > exists. > > Br, > /Alexey > > -- Br, /Alexey
