Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crashes on opening #2

Closed
jasmith79 opened this issue Oct 12, 2018 · 8 comments
Closed

Crashes on opening #2

jasmith79 opened this issue Oct 12, 2018 · 8 comments

Comments

@jasmith79
Copy link

Crashes on opening, whether trying to open view or split into pane.

Atom 1.31.2 64 bit (current)
Mac OS X High Sierra

@PerBothner
Copy link
Owner

Thanks for trying DomTerm. Would you mind testing stand-alone domterm, without using atom? I.e. I assume you've already downloaded and built Domterm using these instructions. Can you run the domterm command, using one of the --electron, --qt, --chrome-app, or --browser front-end options? How does that work? Can you create sub-windows (using the menu or the domterm --below new command) and/or create new top-level windows (use the menu or the domterm new command)? Any problems?

I don't have access to a Mac OS machine, so I can't test it directly. I've tested both plain domterm and atom-domterm on Fedora/Linux in the last few days, and less recently I have tested plain (non-atom) domterm under Windows 10 with WSL.

@jasmith79
Copy link
Author

Nevermind, I'm an idiot, since I was introduced to your project via your comment here I just installed the atom package without reading the readme, I didn't have domterm installed.

Can't get it to compile: apparently my gcc isn't using c99. Editing the c.o rule in the makefile to use --std=c99 did not fix it. It just keeps complaining about various for loop declarations.

@PerBothner
Copy link
Owner

I do need to make atom-domterm deal with not finding domterm in a clean way. I'll try to find time for that in the next few days.

If for loops in declaration is a problem, then I can fix that. But where did you get a version of gcc that old? If might make sense to update gcc if it's not too difficult.

@jasmith79
Copy link
Author

@PerBothner almost certainly the one installed by xcode cli tools, and indeed it is ancient (4.8.1). I installed 8.2 from homebrew, changed my $PATH and now get this

server.c: In function 'subst_run_command':
server.c:121:9: warning: 'daemon' is deprecated [-Wdeprecated-declarations]
         daemon(1, 0);
         ^~~~~~
In file included from server.h:10,
                 from server.c:1:
/usr/include/stdlib.h:298:6: note: declared here
 int  daemon(int, int) __DARWIN_1050(daemon) __OSX_AVAILABLE_BUT_DEPRECATED_MSG(__MAC_10_0, __MAC_10_5, __IPHONE_2_0, __IPHONE_2_0, "Use posix_spawn APIs instead.") __WATCHOS_PROHIBITED __TVOS_PROHIBITED;
      ^~~~~~
server.c: In function 'main':
server.c:1206:9: warning: 'daemon' is deprecated [-Wdeprecated-declarations]
         if (daemon(1, 0) != 0)
         ^~
In file included from server.h:10,
                 from server.c:1:
/usr/include/stdlib.h:298:6: note: declared here
 int  daemon(int, int) __DARWIN_1050(daemon) __OSX_AVAILABLE_BUT_DEPRECATED_MSG(__MAC_10_0, __MAC_10_5, __IPHONE_2_0, __IPHONE_2_0, "Use posix_spawn APIs instead.") __WATCHOS_PROHIBITED __TVOS_PROHIBITED;
      ^~~~~~
gcc  -I/usr/local/Cellar/json-c/0.13.1/include/json-c -I/usr/local/include -I./lws-term -I/usr/local/Cellar/libwebsockets/2.4.2_2/include  -DCOMPILED_IN_RESOURCES  -I/usr/local/opt/openssl/include/ -I/usr/local/include -I/usr/local/opt/expat/include  -L/usr/local/opt/openssl/lib -L/usr/local/lib -L/usr/local/opt/expat/lib -o ldomterm ldomterm-server.o ldomterm-utils.o ldomterm-protocol.o ldomterm-http.o ldomterm-whereami.o ldomterm-commands.o ldomterm-help.o ldomterm-junzip.o ldomterm-settings.o ldomterm-git-describe.o ldomterm-resources.o -L/usr/local/Cellar/libwebsockets/2.4.2_2/lib -lwebsockets  -L/usr/local/Cellar/json-c/0.13.1/lib -ljson-c  -lpthread -lutil -lz
ld: warning: directory not found for option '-L/usr/local/opt/expat/lib'
Undefined symbols for architecture x86_64:
  "_lws_add_http_common_headers", referenced from:
      _callback_http in ldomterm-http.o
  "_lws_finalize_write_http_header", referenced from:
      _callback_http in ldomterm-http.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[2]: *** [ldomterm] Error 1
make[1]: *** [bin/domterm] Error 2
make: *** [all-recursive] Error 1

@PerBothner
Copy link
Owner

Looks like you ran configure with the --enable-compiled-in-resources flag. Trying removing that option. (The option requires a more recent version of libwebsockets. It used to work for older libwebsockets versions, but change in libwebsockets make it easier to use these new functions. I will update the build instructions.)

@jasmith79
Copy link
Author

Builds but doesn't work:

Trying to run domterm from bin opened firefox? (not my default browser).
Trying to run atom-domterm after putting the executable on my path resulted in an empty tab (although the editor no longer crashes).

@PerBothner
Copy link
Owner

By "opened firefox" I assume you mean it create a Firefox window, but nothing appeared in the window?

If you open a debugger window (Ctrl-Shift-I on Window or Linux; I'm guessing Cmd-Shift-I on Mac) do you see any messages in the Console view?

If you have electron downloaded, you can try domterm --electron. You may have to override command.electron in the settings.ini file. See also the Window specifier option section. You can try --chome or --chrome-app.

(I'd like to concentrate on making sure plain domterm is working before worrying about atom-domterm.)

@jasmith79
Copy link
Author

Got it working in firefox, not sure why it didn't before. After placing it on my PATH, atom-domterm works as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@jasmith79 @PerBothner and others