On 8 Jun 2015, at 02:21, Stephen Leake <[email protected]> wrote:
> Simon Wright <[email protected]> writes: > I've reproduced my problem on Windows; I was waiting to also do it on > Linux before I posted. > > On Windows with zcx, I get a crash on any exception, at the point the > exception is raised. Crossing an Ada/C boundary is not required. With > sjlj, there is no exception. So apparently zcx requires some > initialization that either adainit doesn't do, or sjlj undoes, or > something. > >> How can I provoke an exception to check out whether there’s a problem >> on Mac? > > Just put in a syntax error. Got it. I added “ WTF!” to the end of the exception handler in ada_grammar_module.adb so I could be sure I was getting the message from the dynlib. >> I couldn’t easily use the makefile, > > Which one? ada-mode.stephe-3/Makefile, or > ada-mode.stephe-3/build/wisi/Makefile. They are the same as far as > building the ada_grammar dynlib; build/wisi also runs all the tests. The second. > What was the problem? I'm guessing the same sjlj issue I ran into on > Linux. There are quite a few traces of your struggles with sjlj; and a lot of Debian dependencies (gnatlib locations etc). I thought I’d try a gprbuild-based approach first. >> so edited the generated GPR and C source, see attached mac_* files. >> With these, gprbuild worked fine and produced an SAL .dylib without >> fuss (I’d set up environment variables in the shell pro tem): I changed the source order in …_parse.gpr, because if I’ve edited source in build/wisi that’s replicated in toplevel I want the compiler to pick the local version! Also, running in a Debian wheezy VM with a mere 2 GB RAM. GNAT GPL 2014 wouldn’t compile ada_grammar_module.adb even with -fno-var-tracking -fno-var-tracking-assignments (mysterious uninformative “internal error” message); I built FSF GCC 4.9.1 which worked OK even without the switches. > What is an "SAL”? I now realise that those initials might make you blink. For the same sort of reason I was startled to find that SJW can mean “social justice warrior”. The main thing about a stand-alone library is that it "contains the necessary code to elaborate the Ada units that are included in the library”, so you don’t need to mess with (or even call) adainit(). Which won’t even be called adainit, but <something-related-to-library-name>init. I find I can use for Interfaces use ("mac_ada_grammar_wisi_module_parse_wrapper.c"); instead of Library_Interface with some random Ada unit, which makes things clearer. http://docs.adacore.com/gprbuild-docs/html/share/gnat_project_manager.html#stand-alone-library-projects > Apparently Library_Interface works on Mac (I haven't tried it on Linux > yet). When I try that on Windows, I get "can't load the specified > module" (I really hate that message; why doesn't it have the module file > name in it!?!). It also leaves libgnat dynamically linked, so we'd have > to distribute that if we do a binary release. > > That leaves us with a naming convention difference between Windows and > Mac, but I can put the "lib" back on Windows if we stay with this > approach. I made this change to ada-wisi.el:
ada-wisi.el.diff
Description: Binary data
Some minor points: The default value of ada-wisi-module-parse-dll isn’t the name of the built dynlib. Installing Emacs in /usr/local/emacs, * on Linux, exec-path contains /usr/local/emacs/bin as well as the libexec path; * on Mac, exec-path only contains the libexec path, /usr/local/emacs/libexec/emacs/25.0.50/i386-apple-darwin13.4.0 —S
_______________________________________________ Emacs-ada-mode mailing list [email protected] http://host114.hostmonster.com/mailman/listinfo/emacs-ada-mode_stephe-leake.org
