- ecl-devel - mailman3.common-lisp.net

Broken link in _Lisp (ECL) and QML (Qt5) on Android?_
by pdoherty 25 Nov '17

25 Nov '17

Hi all, I'm new here, so apologies if this is not the proper forum for the following report. I was just reading the post, [Lisp (ECL) and QML (Qt5) on Android?](https://common-lisp.net/project/ecl/posts/Lisp-ECL-and-QML-Qt5-on…, and noticed that the link to README-PREPARE.txt is broken. The link should (probably) point to: https://gitlab.com/eql/EQL5-Android/blob/master/README-PREPARE.md (It would appear that the file's extension was changed at some point.) Best, PRD

2 2

ASDF 3.1.1 is released
by Robert Goldman 15 Nov '17

15 Nov '17

Here is the announcement. Because this fixes a backwards-compatibility bug, we strongly encourage you to replace 3.3.0 with 3.3.1 in your implementations. Best regards, Robert Today we release ASDF 3.3.1, the first bugfix release for the 3.3.0 release series. Of primary interest in this release are 1. a fix for an incompatibility in the UIOP stamp-comparison functions. The handling of infinity as a bound in these functions changed between 3.2 and 3.3, potentially causing problems in backward compatibility. In order to maintain compatibility, the old behavior was restored to the stamp-comparison functions, and new functions -- TIMEstamp comparison functions -- were added to carry the new behaviors. 2. a fix for upgrade from version 3.2.1 3. fixes for bugs that can occur when the default readtable is manipulated inside a dependency loaded by DEFSYSTEM-DEPENDS-ON. We urge implementations that are currently bundling previous versions of ASDF -- and especially those bundling 3.3.0 -- to upgrade to 3.3.1 at their earliest convenience. Here is the changelog entry for 3.3.1: cl-asdf (2:3.3.167-1) unstable; urgency=low New milestone: * UIOP compatibility fix: Introduced new replacement "timestamp" comparison functions, because of inadvertent change in the API. Functions that are compatible with the old semantics are retained as "stamp" comparison functions, but will eventually be deprecated. * Upgrade fix: Upgrade from 3.2.1 needed repair. * Syntax manipulation: Fix for bugs that could be introduced when the default readtable was manipulated during the loading of a defsystem-depends-on system. * Tests: tests for new capabilities and bugs * Documentation: a number of improvements and clarifications.

2 1

16.1.3 mingw-w64-x86_64 build error
by Dave Richards 02 Nov '17

02 Nov '17

I ran configure and only provided the --prefix argument. The 32-bit build worked fine, but the 64-bit build failed, see below. Dave cd build; make make[1]: Entering directory '/c/Dave/ecl-16.1.3/build' Building libeclmin.a... Building ecl_min.exe... ;*** Lisp core booted **** ECL (Embeddable Common Lisp) ;;; ;;; Welcome to bare.lsp. Let's bring this instance up! ;;; ;;; ;;; About to load lsp/load.lsp ;;; ;;; Loading src:lsp;export.lsp ;;; Unhandled lisp initialization error ;;; Message: FILE-ERROR ;;; Arguments: (:PATHNAME #P"SRC:LSP;EXPORT.LSP.NEWEST") Internal or unrecoverable error in: Lisp initialization error. This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. make[1]: *** [Makefile:241: bin/ecl.exe] Error 3 make[1]: Leaving directory '/c/Dave/ecl-16.1.3/build' make: *** [Makefile:72: all] Error 2

2 2

ECL and musl
by Lucas Ramage 20 Oct '17

20 Oct '17

Hello, I am attempting to package ecl for alpine linux and I am having troubles compiling against musl. Building ecl_min... .//libeclgc.a(mach_dep.o): In function `GC_with_callee_saves_pushed': /root/ecl-16.1.3/src/bdwgc/mach_dep.c:245: undefined reference to `getcontext' collect2: error: ld returned 1 exit status make[1]: *** [Makefile:224: ecl_min] Error 1 make[1]: Leaving directory '/root/ecl-16.1.3/build' make: *** [Makefile:72: all] Error 2 I tried `make CFLAGS='-DNO_GETCONTEXT'` but that did not work either. Has anyone successfully built ecl using musl? -- Regards, [image: Visit online journal] <https://lramage94.github.io/> *Lucas Ramage* / Software Engineer ramage.lucas(a)openmailbox.org / (941) 404-6794 *PGP Fingerprint* / Learn More <https://emailselfdefense.fsf.org/en/> EAE7 45DF 818D 4948 DDA7 0F44 F52A 5A96 7B9B 6FB7 <https://pgp.mit.edu/pks/lookup?op=get&search=0xF52A5A967B9B6FB7> *Visit online journal* http://lramage94.github.io <https://lramage94.github.io/> [image: Github] <https://github.com/lramage94>[image: Linkedin] <https://www.linkedin.com/in/lramage94>

3 3

ASDF 3.3 is released
by Robert Goldman 07 Oct '17

07 Oct '17

Today we release ASDF 3.3. The most substantial change is to the build planning process, which has been reformed by François-René Rideau so that DEFSYSTEM-DEPENDS-ON now behaves correctly. There are a number of other improvements, and we are indebted to Daniel Kochmanski, Rommel Martinez, and Chun Tian for contributions. Thanks again to Anton Vodonosov and Dave Cooper for support in testing, and new thanks to Martti Halminen, Jens K. Loewe, and Jason Miller. I would like to dedicate this ASDF release to the late Elias Pipping. On a technical level, Elias made great improvements in some of the most challenging ASDF internals, notably the RUN-PROGRAM component of UIOP, a place where implementations are not constrained by the language specification, diverge radically from each other, and are poorly documented. On a personal level, Elias was very supportive to me as ASDF maintainer, and while I was going through an illness. He did all these things despite being gravely ill with the cancer that eventually killed him. He will be greatly missed, Z'chrono L'vracha. We urge implementations that are currently bundling previous versions of ASDF to adopt 3.3.0 at their earliest convenience. The improvements offered in this release will substantially improved the reliability and predictability of ASDF use. Details on bugfixes can be found at https://launchpad.net/asdf and in the discussions in merged branches of https://gitlab.common-lisp.net/asdf/asdf Here is the changelog entry for 3.3: cl-asdf (2:3.3.0-1) unstable; urgency=low New milestone: * Build-plan: Extensively revised the build plan process so that :DEFSYSTEM-DEPENDS-ON would work correctly, even when depended on systems change (which didn't work before). See our ELS demonstration about it: "Delivering Common Lisp Applications with ASDF 3.3" < https://github.com/fare/asdf2017 > * Internals: to support the above, many ASDF internals have changed. ASDF now has the notion of multiple build phases to a common build session (which generalizes the previous build cache). ASDF considers loading a .asd file as an operation DEFINE-OP, and tracks as dependencies files mentioned during in :LOAD-FILE-FORM statements, etc. Some code has moved to new files or among old files, and between packages. Actions are now uniformly represented as a CONS of an OPERATION and a COMPONENT, where in some cases previously only the class of the operation was preserved. Forcing is constrained to be uniform across all phases of a top level ASDF operation invocation. Fixed the protocol for resetting systems being (re)defined, allowing subclasses to define default slot values. Remove *LOAD-SYSTEM-OPERATION*, as the current maintainer of ECL, for which it was originally designed, decided that it could never be made to work properly, after all. * ASDF&UIOP: Tweak dependencies between ASDF and UIOP. To avoid DEFINE-OP circularity, asdf.asd with no longer causes uiop.asd to be loaded. A standalone UIOP won't be loaded at all unless it's strictly more recent than ASDF. * Tests: tests for new capabilities and bugs. Test backtraces can be disabled. * Documentation: a number of improvements and clarifications. * Feature: a new feature :asdf3.3 * ECL: restored the deprecated function MAKE-BUILD, removed in 3.2.0, in a way that works on top of supported APIs (we still recommend you migrate to these supported APIs). Also stop using the deprecated COMPUTE-INIT-NAME. * Deprecation: starting to emit STYLE-WARNINGs for deprecated functions. Will gradually escalate to true WARNINGs and then ERRORs. -- Robert P. Goldman <rpgoldman(a)sift.net> Sun, 20 August 2017 21:00:00 -0500 Robert P. Goldman Research Fellow Smart Information Flow Technologies (d/b/a SIFT, LLC) 319 N. First Ave., Suite 400 Minneapolis, MN 55401 Voice: (612) 326-3934 Email: rpgoldman(a)SIFT.net

1 0

Help.doc loading in Binary
by John Mercouris 06 Oct '17

06 Oct '17

Hello everyone, I’m running ECL + EQL 16.1.3, Mac OS High Sierra I can produce a binary with ECL, but I have an issue, when I try to run it on anybody’s computer: I get the following: ------------------------------------------------------ Condition of type: FILE-ERROR Filesystem error with pathname “SYS:help.doc”. Either 1) the file does not exist, or 2) we are not allowed to access the file, or 3) the pathname points to a broken symbolic link. No restarts available. Top level in: #<process TOP-LEVEL>. > ------------------------------------------------------ I’ve determined that the cause of this error is a file missing at: /usr/local/lib/ecl-16.1.3/help.doc I’ve been able to get binary files to work on other people’s machines by copying the help.doc file to the appropriate dir. Unfortunately this is not a practical solution for distribution. Is there any way to tell ECL to not attempt to load this file? Any patch I can apply to the source? Thanks, -John

2 2

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