bug-apl
[Top][All Lists]
Advanced

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

Re: compiling ap/libapl


From: Dr . Jürgen Sauermann
Subject: Re: compiling ap/libapl
Date: Sun, 20 Jun 2021 13:45:22 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

Hi,

generally speaking, the APserver is looked for in two directories:

1. the directory in which apl lives, and
2. the subdirectory APs of that
directory.

Case 1. above is the normal case: both apl and APserver are installed in, for example, /usr/local/bin.
Case 2. above is the developer case: apl is in src and APserver is in src/APs.

If you copy the apl binary into some other directory and start it there (like directory "."
if it is not src or the installation directory) then you must also copy the APserver there
(or else apl will be unable to find it). Note that $PATH is not consulted in order to
find APserver even though
$PATH is consulted to find apl.

You can start apl with command line option -l 37 to see how APserver is looked for.

Best Regads,
Jürgen


On 6/20/21 12:02 AM, enztec@gmx.com wrote:
Hello

>From the  make install  the APserver is in /usr/local/bin/APserver along with apl and AP100 and AP210

but according to the strace log it never looks for /usr/local/bin/APserver just in the current dir

access("./APserver", X_OK)              = -1 ENOENT (No such file or directory)
access("./APs/APserver", X_OK)          = -1 ENOENT (No such file or directory)

i disabled the APserver in the preferences so the message isn't displayed



On Sat, 19 Jun 2021 11:34:12 +0200
Dr. Jürgen Sauermann <mail@xn--jrgen-sauermann-zvb.de> wrote:

Hi,

at a first glance:

You cannot simply skip init_libapl() because that will leave many
C++ variables undefined and because of that your program will crash
sooner or later.

Instead: make sure your program finds the APserver (a non-libapl build
and makle install) should install it in a proper place). strace is your
friend in figuring where libapl looks for the APserver.

Alternatively you can start the APserver manually and libapl should then
find it without knowing where the APserver binary is located

Best Regards,
Jürgen

On 6/18/21 10:49 PM, enztec@gmx.com wrote:

Hello

Here is my situation with regards to my compiling apl/libapl

i have a working 1182 apl/libapl which works perfectly - the 1182 libapl.so and libapl.a both compile the libapl_test.c code fine

i tried to compile 1474 apl/libapl and the apl compiled with no problem but segfaylts when i display a var of 30000 integers and when i use )copy on the same file a second time it won't copy because of some recursive warning (there is nothing recursive in the file)
the ]nextfile and ]pushfile both work fine however

but compiling the 1474 libapl had problems but i was finally able to compile it. but the resulting libapl.so and libapl.a both give the floating point error with the following libapl_test.c code

i decided to backtrack and recompile the 1182 to get a floor on this situation

but now when i compile 1182 the apl seems okay but the libapl.so and libapl.a both give the floating point error from libapl_test.c

something changed from the original 1182 compile now and i would like to find/fix what is now wrong so the 1475 compile will be good

none of the libraries linked into libapl.so or used for the libapl.a have changed

---

libapl_test.c
// libapl_test.c   stl
#include <stdio.h>
#include <stdlib.h>
#include <apl/libapl.h>
//#include "/usr/local/include/apl/libapl.h"
int main (int argc, char * argv[])
{
// causes  Executable ./APs/APserver not found.
//init_libapl(argv[0], 0);
apl_exec("2 3⍴⍳6");
return 0;
}

----

f=libapl_test

here is good dynamic compile on old 1182 libapl.so
gcc $f.c -L /usr/local/lib/apl -lapl -o $f -O2
./$f

this is good static compile on old 1182 libapl.a
gcc $f.c -lpthread -lncurses -lxcb -ldl -lm -lc -lsqlite3 -lstdc++ /usr/local/lib/apl/libapl.a -o $f -O2
./$f

---

any help would be appreciated

thanks




    


reply via email to

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