ecl-devel

ecl-devel@common-lisp.net

231 discussions

Android question: how to connect to swank, running on android?
by PR 30 Sep '17

30 Sep '17

Hi again, so, the progress of the new android REPL is going well, it already runs Quicklisp and can start swank, and right there I'm stuck now: How does one connect from the local computer to the android device, which is running the SLIME-listener? They are connected via USB, and the device is /not/ rooted. Since this is certainly of public interest, I ask here, thanks for any help! Below the link to the current APK of the REPL (you'll need android version >= 4.1, API >= 16): http://lights-of-holiness.eu/tmp/repl.apk After launching the app, do (there is currently no feedback of the progress, sorry): (quicklisp) ; should take less than a minute, with a fast internet connection (start-swank) ; same as above (needs to byte-compile all 'contribs') If I run: (mp:all-processes) it lists the running "SLIME-listener" process, so it seems to work... Thanks for any help! Paul

2 17

Re: ECL + EQL Standalone Binary
by Joshua Kordani 26 Sep '17

26 Sep '17

So your binary is looking for whatever version of ecl lives at @libdir@/libecl.16.1.dylib. I still can't find a definition for the macros, but this <https://developer.apple.com/library/content/documentation/DeveloperTools/Co…> has a description of how the reference for libeql5.1.dylib will be resolved at runtime. On 9/26/17 2:06 PM, John Mercouris wrote: > Without performing any changes to the binary, e.g. copying libraries, > the output is as follows: > > > otool -L next.app/Contents/MacOS/next > next.app/Contents/MacOS/next: > @libdir@/libecl.16.1.dylib (compatibility version 16.1.3, current > version 0.0.0) > libeql5.1.dylib (compatibility version 1.0.0, current version 1.0.0) > /opt/local/libexec/qt5/lib/QtPrintSupport.framework/Versions/5/QtPrintSupport > (compatibility version 5.8.0, current version 5.8.0) > /opt/local/libexec/qt5/lib/QtWidgets.framework/Versions/5/QtWidgets > (compatibility version 5.8.0, current version 5.8.0) > /opt/local/libexec/qt5/lib/QtGui.framework/Versions/5/QtGui > (compatibility version 5.8.0, current version 5.8.0) > /opt/local/libexec/qt5/lib/QtCore.framework/Versions/5/QtCore > (compatibility version 5.8.0, current version 5.8.0) > /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration > (compatibility version 1.0.0, current version 1.0.0) > /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit > (compatibility version 1.0.0, current version 275.0.0) > /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL > (compatibility version 1.0.0, current version 1.0.0) > /System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility > version 1.0.0, current version 1.0.0) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version > 400.9.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 1252.0.0) > > -John >> On Sep 26, 2017, at 12:56, Joshua Kordani <jkordani(a)lsa2.com >> <mailto:jkordani@lsa2.com>> wrote: >> >> I cant speak to whether or not ecl is correctly built, but what is >> the output of otool -L on your app binary? >> >> >> On 9/26/17 12:32 PM, John Mercouris wrote: >>> Hi Joshua, sorry for the double email, it occurred to me to list the >>> dependencies as well: >>> >>> > otool -L libeql5.1.0.0.dylib >>> libeql5.1.0.0.dylib: >>> libeql5.1.dylib (compatibility version 1.0.0, current version 1.0.0) >>> @libdir@/libecl.16.1.dylib (compatibility version 16.1.3, current >>> version 0.0.0) >>> /opt/local/libexec/qt5/lib/QtPrintSupport.framework/Versions/5/QtPrintSupport >>> (compatibility version 5.8.0, current version 5.8.0) >>> /opt/local/libexec/qt5/lib/QtWidgets.framework/Versions/5/QtWidgets >>> (compatibility version 5.8.0, current version 5.8.0) >>> /opt/local/libexec/qt5/lib/QtGui.framework/Versions/5/QtGui >>> (compatibility version 5.8.0, current version 5.8.0) >>> /opt/local/libexec/qt5/lib/QtCore.framework/Versions/5/QtCore >>> (compatibility version 5.8.0, current version 5.8.0) >>> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration >>> (compatibility version 1.0.0, current version 1.0.0) >>> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit >>> (compatibility version 1.0.0, current version 275.0.0) >>> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL >>> (compatibility version 1.0.0, current version 1.0.0) >>> /System/Library/Frameworks/AGL.framework/Versions/A/AGL >>> (compatibility version 1.0.0, current version 1.0.0) >>> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current >>> version 400.9.0) >>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current >>> version 1252.0.0) >>> > otool -L libecl.16.1.3.dylib >>> libecl.16.1.3.dylib: >>> @libdir@/libecl.16.1.dylib (compatibility version 16.1.3, current >>> version 0.0.0) >>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current >>> version 1238.51.1) >>> >>> Could it be that when I use install_name_tool and change the binary, >>> it cannot find @libdir@/libecl? >>> >>> -John >>> >>>> On Sep 26, 2017, at 11:30, John Mercouris <jmercouris(a)gmail.com >>>> <mailto:jmercouris@gmail.com>> wrote: >>>> >>>> Hi Joshua, >>>> >>>> Very interesting article that you sent, interested in seeing >>>> exactly what the shared libraries were reporting as their names, I >>>> got the following: >>>> >>>> > otool -D libecl.16.1.3.dylib >>>> libecl.16.1.3.dylib: >>>> @libdir@/libecl.16.1.dylib >>>> >>>> > otool -D libeql5.1.0.0.dylib >>>> libeql5.1.0.0.dylib: >>>> libeql5.1.dylib >>>> >>>> Why is the directive for ECL say @libdir@? Is there a way for me to >>>> change it? Should I reinstall ECL in a different way? >>>> >>>> -John >>>> >>>>> On Sep 26, 2017, at 10:45, Joshua Kordani <jkordani(a)lsa2.com >>>>> <mailto:jkordani@lsa2.com>> wrote: >>>>> >>>>> The behavior you're seeing r.e @executable_path et al is osx >>>>> behavior. I can't find a list of all of the supported "macros" >>>>> but this >>>>> <https://blogs.oracle.com/dipol/dynamic-libraries,-rpath,-and-mac-os> >>>>> gives an example of what is going on. >>>>> >>>>> Loosely, executables have the paths to the dylibs they depend on >>>>> baked into them at compile time. Usually this results in explicit >>>>> paths being baked in, even if you specified a symbolic link at >>>>> link time. The final path of the real dylib gets baked into the >>>>> executable. Osx supports some run time indirection in a few ways, >>>>> one of which is to allow for macros in the paths to be expanded. >>>>> Barring an authoritative source for the true meanings, I supposed >>>>> that @executable_path just causes the dynamic linker to expand >>>>> that into the path the binary was run from, after which the full >>>>> pathname to the true location is resolved and the library loaded. >>>>> Errors here though usually result in "dylib not found errors", but >>>>> occasionally if this isn't understood, the wrong version of a >>>>> library could be loaded at runtime, confusing the issue. >>>>> >>>>> >>>>> On 9/26/17 11:15 AM, John Mercouris wrote: >>>>>> Hi Paul, >>>>>> >>>>>> I’ve commented out the line: EQL::ini(argv); >>>>>> >>>>>> But I still haven’t had any luck with the standalone binary. I >>>>>> can get compilation to work if I don’t move my dylibs into my >>>>>> application bundle. The problem is that it’ll run just fine on my >>>>>> computer, but I can’t easily distribute it because other users >>>>>> would have to still install ECL and EQL. >>>>>> >>>>>> I’m not sure how it happens, but somehow in the process of >>>>>> copying the dylibs into my application bundle, this causes the >>>>>> program to break and produce this very strange error. >>>>>> >>>>>> Using the macdeployqt tool to copy the dependencies automatically >>>>>> seems to work with external libraries, at least it works with >>>>>> EQL, what I can’t figure out is why for ECL otool reports: >>>>>> >>>>>> > otool -L next.app/Contents/MacOS/next >>>>>> @libdir@/libecl.16.1.dylib (compatibility version 16.1.3, current >>>>>> version 0.0.0) >>>>>> >>>>>> I’m not sure what @libdir@ is, probably some make directive, if I >>>>>> run a more verbose form of macdeployqt, I get some interesting >>>>>> output: >>>>>> >>>>>> > macdeployqt ./next.app/ -libpath=/usr/local/lib -verbose=3 >>>>>> Log: Framework name "libecl.16.1.dylib" >>>>>> Framework directory "/@libdir@/" >>>>>> Framework path "/@libdir@/libecl.16.1.dylib" >>>>>> Binary directory "/@libdir@/" >>>>>> Binary name "libecl.16.1.dylib" >>>>>> Binary path "/@libdir@/libecl.16.1.dylib" >>>>>> Version "" >>>>>> Install name "" >>>>>> Deployed install name >>>>>> "@executable_path/../Frameworks/libecl.16.1.dylib" >>>>>> Source file Path "/@libdir@/libecl.16.1.dylib" >>>>>> Framework Destination Directory (relative to bundle) >>>>>> "Contents/Frameworks/" >>>>>> Binary Destination Directory (relative to bundle) >>>>>> "Contents/Frameworks/“ >>>>>> >>>>>> The real question I have is, why is ECL reporting such strange >>>>>> directories? Obviously with a directory like: /@libdir@/, >>>>>> macdeployqt doesn’t resolve the proper location to get the >>>>>> dylibs, copy and re-link them. >>>>>> >>>>>> For EQL it appears to be working perfectly fine: >>>>>> >>>>>> *Log: inspecting "/usr/local/lib/libeql5.1.dylib"* >>>>>> Log: Adding framework: >>>>>> Log: Framework name "libeql5.1.dylib" >>>>>> Framework directory "/usr/local/lib/" >>>>>> Framework path "/usr/local/lib/libeql5.1.dylib" >>>>>> Binary directory "/usr/local/lib/" >>>>>> Binary name "libeql5.1.dylib" >>>>>> Binary path "/usr/local/lib/libeql5.1.dylib" >>>>>> Version "" >>>>>> Install name "libeql5.1.dylib" >>>>>> Deployed install name >>>>>> "@executable_path/../Frameworks/libeql5.1.dylib" >>>>>> Source file Path "/usr/local/lib/libeql5.1.dylib" >>>>>> Framework Destination Directory (relative to bundle) >>>>>> "Contents/Frameworks/" >>>>>> Binary Destination Directory (relative to bundle) >>>>>> "Contents/Frameworks/" >>>>>> >>>>>> I have a suspicion that if I can fix this, I can make the binary >>>>>> work. There is absolutely no reason that copying the dylib files >>>>>> should break the binary. One thing that makes me suspicious is >>>>>> that libecl.16.1.dylib is a symlink whereas libeql5.1.dylib is >>>>>> not a symlink. I wanted to make the program use >>>>>> libel.16.1.3.dylib, but I wasn’t sure how to force it to do that, >>>>>> >>>>>> Anyways, thank you to everyone who has offered your help and support! >>>>>> >>>>>> -John >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> Reference: >>>>>> ------------------------------------------------------------------------ >>>>>> *Contents of /usr/local/lib:* >>>>>> drwxr-xr-x 55 root wheel 1870 Apr 16 03:55 ecl-16.1.3 >>>>>> -rwxr-xr-x 1 root wheel 3424316 Apr 16 03:55 >>>>>> libecl.16.1.3.dylib >>>>>> lrwxr-xr-x 1 jmercouris staff 19 Apr 16 03:55 >>>>>> libecl.16.1.dylib -> libecl.16.1.3.dylib >>>>>> lrwxr-xr-x 1 jmercouris staff 19 Apr 16 03:55 libecl.16.dylib >>>>>> -> libecl.16.1.3.dylib >>>>>> lrwxr-xr-x 1 jmercouris staff 19 Apr 16 03:55 libecl.dylib -> >>>>>> libecl.16.1.3.dylib >>>>>> -rwxr-xr-x 1 root wheel 11653432 Sep 25 19:58 >>>>>> libeql5.1.0.0.dylib >>>>>> lrwxr-xr-x 1 root wheel 19 Sep 25 19:58 >>>>>> libeql5.1.0.dylib -> libeql5.1.0.0.dylib >>>>>> lrwxr-xr-x 1 root wheel 19 Sep 25 19:58 libeql5.1.dylib >>>>>> -> libeql5.1.0.0.dylib >>>>>> lrwxr-xr-x 1 root wheel 19 Sep 25 19:58 libeql5.dylib >>>>>> -> libeql5.1.0.0.dylib >>>>>> -rwxr-xr-x 1 root wheel 288264 May 1 16:28 >>>>>> libeql5_webkit.1.0.0.dylib >>>>>> lrwxr-xr-x 1 root wheel 26 May 1 16:28 >>>>>> libeql5_webkit.1.0.dylib -> libeql5_webkit.1.0.0.dylib >>>>>> lrwxr-xr-x 1 root wheel 26 May 1 16:28 >>>>>> libeql5_webkit.1.dylib -> libeql5_webkit.1.0.0.dylib >>>>>> lrwxr-xr-x 1 root wheel 26 May 1 16:28 >>>>>> libeql5_webkit.dylib -> libeql5_webkit.1.0.0.dylib >>>>>> >>>>>> *Contents of next.pro* >>>>>> QT += widgets printsupport uitools >>>>>> TEMPLATE = app >>>>>> ICON = ../assets/next.icns >>>>>> CONFIG += no_keywords release >>>>>> INCLUDEPATH += /usr/local/include >>>>>> INCLUDEPATH += /usr/local/include/eql >>>>>> LIBS += -L/usr/local/lib -lecl >>>>>> LIBS += -L/usr/local/lib -leql5 >>>>>> LIBS += -L. -lnext >>>>>> TARGET = next >>>>>> DESTDIR = ./ >>>>>> OBJECTS_DIR = ./tmp/ >>>>>> MOC_DIR = ./tmp/ >>>>>> >>>>>> SOURCES += main.cpp >>>>>> >>>>>> >>>>>> >>>>>>> On Sep 26, 2017, at 00:26, PR <polos.ruetz(a)gmail.com >>>>>>> <mailto:polos.ruetz@gmail.com>> wrote: >>>>>>> >>>>>>> 2017-09-25 19:19 GMT+02:00, John Mercouris <jmercouris(a)gmail.com >>>>>>> <mailto:jmercouris@gmail.com>>: >>>>>>>> Any ideas on how to proceed would be very useful, thank you, >>>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>> the only thing that currently comes to mind is trying to comment >>>>>>> out the line >>>>>>> >>>>>>> EQL::ini(argv); >>>>>>> >>>>>>> in your main.cpp (this function simply calls cl_boot(); I remember >>>>>>> that I needed to place it there in the past, just to be safe on all >>>>>>> platforms. >>>>>>> >>>>>>> But cl_boot() will also be called later in the EQL constructor (only >>>>>>> if it has not been called earlier). >>>>>>> >>>>>>> So, maybe in your situation it's better when it's called after the >>>>>>> QApplication constructor has been called. >>>>>>> >>>>>>> But this is just a guess. >>>>>>> >>>>>>> BTW, I tried to compile it on Linux (from the sources given by you), >>>>>>> and it worked without problems! >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> -John >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> >

1 0

"Got signal before environment was installed on our thread"
by Dima Pasechnik 26 Sep '17

26 Sep '17

Dear all, I'm struggling to understand strange segfaults coming from ECL(+Maxima) on FreeBSD embedded into Python; they typically look as follows: Got signal before environment was installed on our thread [2: No such file or directory] ;;; ECL C Backtrace ;;; 0 ecl_internal_error (0x87d790765) ;;; 1 init_unixint (0x87d7b6bd0) ;;; 2 init_unixint (0x87d7b6972) ;;; 3 pthread_sigmask (0x80103779d) ;;; 4 pthread_getspecific (0x801036d6f) ;;; 5 unknown (0x7ffffffff193) ;;; 6 GC_push_all_stacks (0x87db1ea2c) ;;; 7 GC_mark_some (0x87db12eec) ;;; 8 GC_stopped_mark (0x87db09baa) ;;; 9 GC_try_to_collect_inner (0x87db09a75) ;;; 10 GC_init (0x87db16f4f) ;;; 11 init_alloc (0x87d7caa59) ;;; 12 cl_boot (0x87d694a5b) ;;; 13 initecl (0x87d218340) ;;; 14 initecl (0x87d20a43f) ;;; 15 initecl (0x87d207e28) ;;; 16 _PyImport_LoadDynamicModule (0x800b3ed1c) ;;; 17 PyImport_AppendInittab (0x800b3d71f) ;;; 18 PyImport_AppendInittab (0x800b3d1a8) ;;; 19 PyImport_ImportModuleLevel (0x800b3c2ce) ;;; 20 _PyBuiltin_Init (0x800b162d7) ;;; 21 PyObject_Call (0x800a7d3e3) ;;; 22 PyEval_EvalFrameEx (0x800b2121c) ;;; 23 PyEval_EvalCodeEx (0x800b1b5d4) ;;; 24 PyEval_EvalCode (0x800b1ad96) ;;; 25 PyImport_ExecCodeModuleEx (0x800b3ad11) ;;; 26 PyImport_AppendInittab (0x800b3ddb8) ;;; 27 PyImport_AppendInittab (0x800b3d71f) ;;; 28 PyImport_AppendInittab (0x800b3d1a8) ;;; 29 PyImport_ImportModuleLevel (0x800b3c2ce) ;;; 30 _PyBuiltin_Init (0x800b162d7) ;;; 31 PyEval_EvalFrameEx (0x800b22dd1) Segmentation fault (core dumped) It looks as if ECL (version 16.1.2) is being called before an initialisation is complete, but it it possible to say more without a debugger? More details: is is on FreeBSD 11.0, clang 3.8.0, GC version 7.6.0 with libatomic_ops version 7.4.6. And only reproducible on FreeBSD. ECL is built with --disable-threads; GC is built with or without threads---result is still the same. (so it's unclear to me where pthread_* calls in the trace come from). Thanks, Dima PS. the segfault is at the bottom of https://trac.sagemath.org/ticket/22679#comment:87

3 12

Fwd: ECL + EQL Standalone Binary
by John Mercouris 26 Sep '17

26 Sep '17

Hey everyone, I’m John (the developer of nEXT (https://github.com/neXT-Browser/nEXT/ <https://github.com/neXT-Browser/nEXT/>), I’m trying to produce a standalone binary. I managed to create a “.app” bundle of my application, and then I linked the libraries ecl and eql following this approach (https://stackoverflow.com/questions/2809930/macdeployqt-and-third-party-lib… <https://stackoverflow.com/questions/2809930/macdeployqt-and-third-party-lib…>): > install_name_tool -change libeql5.1.dylib @executable_path/../Frameworks/libeql5.1.dylib next.app/Contents/MacOS/next > install_name_tool -change @libdir@/libecl.16.1.dylib @executable_path/../Frameworks/libecl.16.1.dylib next.app/Contents/MacOS/next otool then reveals that everything was successful: > otool -L next.app/Contents/MacOS/next next.app/Contents/MacOS/next: @executable_path/../Frameworks/libecl.16.1.dylib (compatibility version 16.1.3, current version 0.0.0) @executable_path/../Frameworks/libeql5.1.dylib (compatibility version 1.0.0, current version 1.0.0) Anyways, long story short, I got the following terminal output when I try to launch my new app binary: In order to minimize the possibility of mistakes in my program, misusage of QT etc, I’ve created a branch where I’ve included only 2 lisp files, a package file, and a “base” file: https://github.com/nEXT-Browser/nEXT/tree/compile/next <https://github.com/nEXT-Browser/nEXT/tree/compile/next> Any ideas on how to proceed would be very useful, thank you, -John

4 10

Re: ECL + EQL Standalone Binary
by Pascal Bourguignon 26 Sep '17

26 Sep '17

> On 26 Sep 2017, at 00:41, John Mercouris <jmercouris(a)gmail.com> wrote: > > Hi Pascal, I’ve done exactly as you said and have the following output: > > <output.pdf> (format nil "~x"(+ 1025 #xe70)) —> "1271" Since it looks like the functions around this address are unrelated to file accesses, then we may suppose that we have an error due to the modifications made by install_name_tool to the binary. Try without using this tool. If my hypothesis is correct, you will have to load the libraries explicitely at run-time as we’ve always done with cffi… > Honestly, I’m not sure what to make of it, it looks very similar to your output as well, > > -John >> On Sep 25, 2017, at 16:58, Pascal Bourguignon <pjb(a)informatimago.com <mailto:pjb@informatimago.com>> wrote: >> >> >> >> >>> On 25 Sep 2017, at 22:47, John Mercouris <jmercouris(a)gmail.com <mailto:jmercouris@gmail.com>> wrote: >>> >>> Hi Pascal, >>> >>> Thank you for your email, >>> >>> 1. You’re correct, I had to manually copy the libraries in to the app bundle, I just did something like: >>> >>> > cp /usr/local/lib/libeql5.1.dylib ./next.app/Contents/Frameworks/ >>> >>> 2. I saw the message is within ECL, I found the exact file with the error message, it is located in ecl/src/c/unixint.d >>> >>> I figured my problem was unrelated to the libraries, but I wasn’t 100% sure, just wanted to include all information, >>> >>> 3. I have no idea how to read assembly, I mean I can pick through it, but I won’t be able to really understand what’s going on, nor would I know how to even attach a debugger to the process, are there any other ways that I can examine what’s going on? A source file I can look at? Should I be looking for issues within ECL or EQL? >> >> You don’t need to understand the assembly code; you can just watch the name of the functions around the indicated location. >> >> In the case of my version of libecl, I would find: >> >> [pjb@despina :0.0 documentation]$ otool -t -v -V /opt/local/lib/libecl.dylib|grep -A300 -e '^_cl_boot:' >> _cl_boot: >> 0000000000001d34 movl 0x22ddce(%rip), %eax >> 0000000000001d3a testl %eax, %eax >> >> #x1d34 + 1025 = #x2135 >> >> 00000000000020e2 callq 0x151748 ## symbol stub for: _si_getcwd >> 00000000000020e7 movq %rax, 0x708(%r13) >> 00000000000020ee movl $0x1003, %esi >> 00000000000020f3 movl $0x1, %edx >> 00000000000020f8 movl $0x1, %ecx >> 00000000000020fd movl $0x1, %r8d >> 0000000000002103 movl $0x1, %r9d >> 0000000000002109 movq %r14, %rdi >> 000000000000210c callq 0x151814 ## symbol stub for: _si_make_vector >> 0000000000002111 movq %rax, 0x250(%r15) >> 0000000000002118 movl $0x4, %esi >> 000000000000211d movl $0x3, %edx >> 0000000000002122 movl $0x1, %ecx >> 0000000000002127 movq %rax, %rdi >> 000000000000212a callq 0x15163a ## symbol stub for: _si_fill_array_with_elt >> 000000000000212f movq 0x250(%r15), %rax >> 0000000000002136 movq 0x10(%rax), %rcx >> 000000000000213a movq %rcx, 0x240(%r15) >> 0000000000002141 movq 0x20(%rax), %rax >> 0000000000002145 movq %rax, 0x248(%r15) >> 000000000000214c movq 0x320(%r15), %rax >> 0000000000002153 movq %rax, 0x134b0(%r13) >> 000000000000215a movq 0x22dbef(%rip), %rdx >> 0000000000002161 movq 0x22dbf0(%rip), %rcx >> 0000000000002168 leaq 0x4980(%r13), %rdi >> 000000000000216f movl $0x203, %esi >> 0000000000002174 callq 0x150026 ## symbol stub for: _cl__make_hash_table >> 0000000000002179 movq %rax, %r15 >> 000000000000217c movq %r15, 0x22daad(%rip) >> 0000000000002183 leaq _char_names(%rip), %rbx >> >> we can see that calls to SI:GETCWD, SI:MAKE-VECTOR and SI-FILL-ARRAY-WITH-ELT are made just before that address, and a call to CL:MAKE-HASH-TABLE will be called just after. >> >> So if I had the error at the same cl_boot+1025 offset, I would infer there’s some problem with the allocation of a vector. >> (But this is not consistent with your file not found error, so check your own copy of the library, you may find other functions around the cl_boot+1025 address). >> >> >> -- >> __Pascal J. Bourguignon__ >

3 2

How to build ECL from sources to be able to debug itself?
by PR 07 Sep '17

07 Sep '17

Hi, I need to debug a possible socket bug on android; I've set up everything to be able to use a gdbserver on it, but it doesn't show anything useful (only a disassembly, which is cryptic to me). Is there a simple way to build all of prebuilt ECL (including sockets etc.) in debug mode? I already tried the configure options which mention debug, but this didn't change anything. Thanks, Paul

1 0

Building a real static binary
by Florian Margaine 29 Aug '17

29 Aug '17

Hi, I've been trying to build a real static binary for easy deployment. So far, everything I've tried still links to libecl as a shared library; is it possible to have a static library of it, so that my static binary can bundle it? I guess I kind of want to shy away from building ECL myself, it's kind of a pain to require that for other developers working on this project. Regards, -- Florian Margaine

2 2

Tail self-call optimization in generated C code?
by Eric Brunel 22 Aug '17

22 Aug '17

Hello all, I'm trying to get ECL to optimize tail self-calls in the C code generated from the Lisp files and it looks like I'm missing something, because I can't find a way to do that. Here is the behavior I'm getting for this simple Lisp function: (defun enumerate (l &optional (index 0) (result nil)) (cond ((null l) (reverse result)) (t (enumerate (cdr l) (+ index 1) (cons (list index (car l)) result))) ) ) As far as I can see, this function is properly tail-recursive, so I expected the generated C code to take the into account and generate a goto instead of a recursive call. But what I'm getting is this: static cl_object L1enumerate(cl_narg narg, cl_object v1l, ...) { cl_object T0, T1, T2, T3, T4; cl_object env0; const cl_env_ptr cl_env_copy = ecl_process_env(); cl_object value0; ecl_cs_check(cl_env_copy,value0); if (ecl_unlikely(narg<1)) FEwrong_num_arguments_anonym(); if (ecl_unlikely(narg>3)) FEwrong_num_arguments_anonym(); { cl_object v2index; cl_object v3result; va_list args; va_start(args,v1l); { int i = 1; if (i >= narg) { v2index = ecl_make_fixnum(0); } else { i++; v2index = va_arg(args,cl_object); } if (i >= narg) { v3result = ECL_NIL; } else { i++; v3result = va_arg(args,cl_object); } } va_end(args); if (!(v1l==ECL_NIL)) { goto L3; } value0 = cl_reverse(v3result); return value0; L3:; T0 = ecl_cdr(v1l); T1 = ecl_plus(v2index,ecl_make_fixnum(1)); T2 = ecl_car(v1l); T3 = cl_list(2, v2index, T2); T4 = CONS(T3,v3result); value0 = L1enumerate(3, T0, T1, T4); return value0; } } The recursive call is generated as a recursive call in C too... I'm almost sure I've seen C code generated from ECL that generated self tail calls as goto's, and I know it works when using the bytecode, where you just have to compile the function. But my search for a way to trigger this behavior for the generated C code has been unsuccessful so far. I'm using ECL 16.1.3. I used "ecl -c ... --compile ..." to get the C code, but my main build uses asdf:make-build with an ASD file.

3 5

EQL5-Android (port of EQL5 to the Android platform): a first example
by PR 04 Jul '17

04 Jul '17

For those interested in tablet / mobile development: I finally got a first example of EQL5 to work on Android, see 'tic-tac-toe' example, of course using both QML and Lisp! https://gitlab.com/eql/EQL5-Android Paul

2 2

Re: Android question: does cross-compiling require a 32 bit host ECL?
by Daniel Kochmański 04 Jul '17

04 Jul '17

Ah, there is one more problem with CC. If ECL versions differ (for instance 16.1.2 and 16.1.3), the resulting code will compile, but it won't work. The reason for that lies in fact, that symbols are indexed by positions in the table, and they may differ between versions. That said, if the index is different for the same version but with different features compiled in (i.e unicode and unicode) - all should work fine. If it doesn't, it is a bug. On 04.07.2017 07:31, Daniel Kochmański wrote: > > On 03.07.2017 21:17, Andy Hefner wrote: >> Interesting. Sometime in the past I recall reading that this was by >> design, and the compiler was intended to produce portable C. I'm >> curious to what extent this used to be true, or if the departure from >> this philosophy was deliberate. >> > Well, it depends on what you consider portable C. ECL compiler tries > to get the most from the used C compiler - before build it uses > autotools to detect features it can use. > > Lately we have made C99-compliant C compiler a requirement, so types > like uint64_t should be guaranteed to exist. That said ECL still work > with compilers older than that. The problem is, that if ECL detect > long double and its companianions (sinl, cosl), it produces code using > them, so we long-float type in CL is more accurate. If we > cross-compile with compiler not having sinl/cosl (not c99 conformant, > like in Android), we are busted. Workaround for that is to build host > ECL without long double. Correct solution is to have *target-features* > and long-float feature verified at runtime (not runtime) - something tbd. > > Requirement to set ABI=32 deliberely is for some obscure reason in > GMP. It is a bug to be fixed if possible. > > Interesting fact is that ECL has internal notion of the target > machine, but there is not mechanism currently to select one. When I > understand the compiler well enough I plan to make it configurable at > runtime - right now though cross compilation is rather a mundane task. > > NB: some other types may be used with ECL (namely - sse packs). > > To sum up: ECL produces portable C code, but: > 1) there may be some backward compatibility constraints (long double), > 2) there are some bugs wrt ABI compatibility if cross-compiled against > different libecl.so (caused by gmp), > 3) cross compilation needs more love (easily switching compiler and > flags etc), > 4) most of the architecture for 3) is implemented, it's a matter of > groking it and fixing some issues. > > I hope that answers your questions. > > Best regards, > Daniel

1 0

← Newer
1
...
11
12
13
14
15
16
17
...
24
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

ecl-devel