MacOS build instructions wrong #116

albertz · 2023-01-13T11:47:38Z

I tried to follow these: http://domterm.org/Downloading-and-building.html#macos-build-simple

But it fails with:

$ CXX="g++ -std=c++11" ./configure
...
checking for magic_open in -lmagic... no
checking for qmake... /opt/homebrew/bin/qmake
checking for moc... no
checking for moc-qt5... no
checking for moc-qt4... no
checking for moc-qt3... no
configure: error: Cannot find moc (Meta Object Compiler).  Try --with-qt=PATH.

I have MacOS 12.5.1.

moc can be find in /opt/homebrew/opt/qt6/share/qt/libexec/moc but not directly in the bin dir.

I then tried CXX="g++ -std=c++11" ./configure --with-qt=/opt/homebrew/opt/qt6 but that gives the same error.

The text was updated successfully, but these errors were encountered:

PerBothner · 2023-01-13T19:18:11Z

I've only tested using what I believe is the default brew installation directory.

It looks like you would need to do: --with-qt=/opt/homebrew/opt/qt6/share/qt/libexec. Could you try that?

albertz · 2023-01-13T21:39:42Z

But this is all with the default Homebrew installation. When did you try? On what hardware? The packages in Homebrew are updated very frequently. Maybe some of the dirs changed. Maybe you even had Qt 5 and not Qt 6, and they changed this?

It looks like you would need to do: --with-qt=/opt/homebrew/opt/qt6/share/qt/libexec. Could you try that?

With that, the configure seems to work.

make works for a few files, but then fails:

$ make
Making all in .
cd dt-wry && cargo build --release
    Updating crates.io index
error: failed to get `regex` as a dependency of package `dt-wry v3.1.0 (/Users/az/Programmierung/DomTerm/dt-wry)`

Caused by:
  failed to load source for dependency `regex`

Caused by:
  Unable to update registry `crates-io`

Caused by:
  failed to fetch `https://github.com/rust-lang/crates.io-index`

Caused by:
  error: unknown SSH host key
  The SSH host key for `github.com` is not known and cannot be validated.

  To resolve this issue, add the host key to the `net.ssh.known-hosts` array in your Cargo configuration (such as /Users/az/.cargo/config.toml) or in your OpenSSH known_hosts file at /Users/az/.ssh/known_hosts

  The key to add is:

  github.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEmKSENjQEezOmxkZMy7opKgwFB9nkt5YRrYMjNuG5N87uRgg6CLrbo5wAdT/y6v0mKV0U2w0WZ2YB/++Tpockg=

  The ECDSA key fingerprint is: SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM
  This fingerprint should be validated with the server administrator that it is correct.

  See https://doc.rust-lang.org/stable/cargo/appendix/git-authentication.html#ssh-known-hosts for more information.
make[1]: *** [dt-wry/target/release/dt-wry] Error 101
make: *** [all-recursive] Error 1

Edit After updating ~/.ssh/known_hosts, it fails with:

$ make
Making all in .
cd dt-wry && cargo build --release
    Updating crates.io index
error: failed to get `regex` as a dependency of package `dt-wry v3.1.0 (/Users/az/Programmierung/DomTerm/dt-wry)`

Caused by:
  failed to load source for dependency `regex`

Caused by:
  Unable to update registry `crates-io`

Caused by:
  failed to fetch `https://github.com/rust-lang/crates.io-index`

Caused by:
  failed to authenticate when downloading repository: [email protected]:rust-lang/crates.io-index

  * attempted ssh-agent authentication, but no usernames succeeded: `git`

  if the git CLI succeeds then `net.git-fetch-with-cli` may help here
  https://doc.rust-lang.org/cargo/reference/config.html#netgit-fetch-with-cli

Caused by:
  no authentication available
make[1]: *** [dt-wry/target/release/dt-wry] Error 101
make: *** [all-recursive] Error 1

albertz · 2023-01-13T21:47:13Z

Ok, that actually seems to be a Rust Cargo issue, esp it seems to be this: rust-lang/cargo#3381

This is because in my ~/.gitconfig, I have this:

[url "[email protected]:"]
        insteadOf = https://github.com/

It works with the suggested workaround, to add the following to ~/.cargo/config:

[net]
git-fetch-with-cli = true

Now it runs a bit further.

albertz · 2023-01-13T21:49:45Z

Now it fails with:

...
   Compiling objc_id v0.1.1
   Compiling regex-syntax v0.6.28
   Compiling once_cell v1.17.0
   Compiling thiserror-impl v1.0.38
   Compiling regex v1.7.1
   Compiling dt-wry v3.1.0 (/Users/az/Programmierung/DomTerm/dt-wry)
error[E0308]: mismatched types
 --> src/versions.rs:2:25
  |
2 | pub fn wry_version() -> &'static str {  }
  |        -----------      ^^^^^^^^^^^^ expected `&str`, found `()`
  |        |
  |        implicitly returns `()` as its body has no tail or `return` expression

For more information about this error, try `rustc --explain E0308`.
error: could not compile `dt-wry` due to previous error
make[1]: *** [dt-wry/target/release/dt-wry] Error 101
make: *** [all-recursive] Error 1

For reference, this is with Rust 1.66.1.

albertz · 2023-01-13T22:10:30Z

Ok, now I tried to disable wry, via CXX="g++ -std=c++11" ./configure --with-qt=/opt/homebrew/opt/qt6/share/qt/libexec --with-wry=no, and then I get:

$ make
Making all in .
touch resources.stamp
Making all in tests
make[1]: Nothing to be done for `all'.
Making all in lws-term
g++ -std=c++11 -DPACKAGE_NAME=\"DomTerm\" -DPACKAGE_TARNAME=\"domterm\" -DPACKAGE_VERSION=\"3.1.0\" -DPACKAGE_STRING=\"DomTerm\ 3.1.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"domterm\" -DVERSION=\"3.1.0\" -DHAVE_QT=1 -I.     -I./lws-term -I/opt/homebrew/Cellar/libwebsockets/4.3.2/include -I/opt/homebrew/include -DCOMPILED_IN_RESOURCES    -g -O2 -c -o ldomterm-server.o `test -f 'server.cc' || echo './'`server.cc
In file included from server.cc:1:
In file included from ./server.h:40:
/opt/homebrew/Cellar/libwebsockets/4.3.2/include/libwebsockets.h:308:10: fatal error: 'openssl/ssl.h' file not found
#include <openssl/ssl.h>
         ^~~~~~~~~~~~~~~
1 error generated.
make[1]: *** [ldomterm-server.o] Error 1
make: *** [all-recursive] Error 1

Related: #112

Edit Note the hint from the openssl Homebrew package:

openssl@3 is keg-only, which means it was not symlinked into /opt/homebrew,
because macOS provides LibreSSL.

If you need to have openssl@3 first in your PATH, run:
  fish_add_path /opt/homebrew/opt/openssl@3/bin

For compilers to find openssl@3 you may need to set:
  set -gx LDFLAGS "-L/opt/homebrew/opt/openssl@3/lib"
  set -gx CPPFLAGS "-I/opt/homebrew/opt/openssl@3/include"

For pkg-config to find openssl@3 you may need to set:
  set -gx PKG_CONFIG_PATH "/opt/homebrew/opt/openssl@3/lib/pkgconfig"

So it means you explicitly need to set the openssl path somewhere.

Edit I added it to PKG_CONFIG_PATH now, then did configure again, and then make seems to work again a bit further.

albertz · 2023-01-13T22:17:54Z

Now make fails with:

Making all in .
make[1]: Nothing to be done for `all-am'.
Making all in tests
make[1]: Nothing to be done for `all'.
Making all in lws-term
g++ -std=c++11 -I/opt/homebrew/Cellar/openssl@3/3.0.7/include -I./lws-term -I/opt/homebrew/Cellar/libwebsockets/4.3.2/include -I/opt/homebrew/include -DCOMPILED_IN_RESOURCES    -g -O2   -o ldomterm ldomterm-server.o ldomterm-utils.o ldomterm-protocol.o ldomterm-http.o ldomterm-whereami.o ldomterm-commands.o ldomterm-command-connect.o ldomterm-help.o ldomterm-junzip.o ldomterm-settings.o ldomterm-git-describe.o ldomterm-resources.o -L/opt/homebrew/Cellar/libwebsockets/4.3.2/lib -lwebsockets -L/opt/homebrew/Cellar/openssl@3/3.0.7/lib -lssl -lcrypto  -lpthread -lutil -lz  
ld: warning: ignoring file ldomterm-whereami.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64
ld: warning: ignoring file ldomterm-junzip.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64
ld: warning: ignoring file ldomterm-git-describe.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64
Undefined symbols for architecture arm64:
  "_git_describe", referenced from:
      print_version(__sFILE*) in ldomterm-server.o
      process_options(int, char const* const*, options*) in ldomterm-server.o
      _main in ldomterm-server.o
  "_wai_getExecutablePath", referenced from:
      get_executable_path() in ldomterm-utils.o
      get_executable_directory_length() in ldomterm-utils.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [ldomterm] Error 1
make: *** [all-recursive] Error 1

Edit Ok, that was probably just an artifact from an earlier partial build. After I did make clean, this error went away.

albertz · 2023-01-13T22:19:47Z

Now I again get another error:

$ make
Making all in .
make[1]: *** No rule to make target `electron/main.js', needed by `share/domterm/electron/main.js'.  Stop.
make: *** [all-recursive] Error 1

PerBothner · 2023-01-13T22:20:29Z

But this is all with the default Homebrew installation.

I see here that the default installation is different for Intel and Apple Silicon.

When did you try? On what hardware?

Today - on an old MacBook Air. My primary computer runs Fedora Linux, so I'm not so well-versed on the Mac ecosystem.

The packages in Homebrew are updated very frequently. Maybe some of the dirs changed. Maybe you even had Qt 5 and not Qt 6, and they changed this?

I did an update this moring - and I'm using Qt6.

It seems plausible to modfy setting of QT_TOOL_PATH in qtdomterm/autotroll.m4 to:

 QT_TOOL_PATH=$QT_PATH:$PATH:/usr/local/share/qt/libexec:/opt/homebrew/opt/qt6/share/qt/libexec

Could you try this?

albertz · 2023-01-13T22:25:51Z

The Qt error seems to be gone now already with your earlier suggestion (--with-qt=/opt/homebrew/opt/qt6/share/qt/libexec). However, see my most recent comment for my current problem. Currently I don't really have an idea what to do about that.

PerBothner · 2023-01-13T22:32:54Z

Now it fails with:
...
| pub fn wry_version() -> &'static str { }
| ----------- ^^^^^^^^^^^^ expected &str, found ()

This file is generated by the top-level Makefile - see the rule for dt-wry/src/versions.rs. Do you have jq on your PATH? The instructions say to install it, but it might be on the wrong place.

albertz · 2023-01-13T22:35:55Z

Do you have jq on your PATH?

Yes, I have:

$ jq -V
jq-1.6

But shouldn't the Makefile anyway fail when it cannot properly generate the file versions.rs because jq fails?

PerBothner · 2023-01-13T22:36:33Z

make[1]: *** No rule to make target electron/main.js', needed by share/domterm/electron/main.js'. Stop.

This is strange. electron/main is a source file, in the Git repository. Do you have it?

albertz · 2023-01-13T22:38:59Z

This is strange. electron/main is a source file, in the Git repository. Do you have it?

$ find electron*
electron
electron/package.json
electron-nodepty
electron-nodepty/preload.js
electron-nodepty/renderer.js
electron-nodepty/logging.js
electron-nodepty/README.md
electron-nodepty/main.js
electron-nodepty/package.json
electron-nodepty/settings.js

This is indeed strange.

Now git status reports:

$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	deleted:    electron/main.js
	modified:   electron/package.json
	deleted:    electron/preload.js

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	lws-term/resources.cc
	lws-term/xterm.stamp
	resources.stamp
	util/macOS.plist

But I did none of these changes. I just did autoreconf, configure and make, with various of the options I reported here, nothing else.

albertz · 2023-01-13T22:40:14Z

Ok, I did a git checkout . to reset those changes in the electron dir, and now make finally seems to succeed.

albertz · 2023-01-13T22:42:55Z

However, the binary does not seem to work. At least for the Electron frontend (./bin/domterm -Belectron), I get the error:

Uncaught Exception:
Error: Cannot require "screen" module before app is ready
at binding (internal/bootstrap/loaders.js:82:36)
at process.atomBinding (/Users/az/Programmierung/electron-quick-start/node_modules/electron/dist/Electron.app/Contents/Resources/electron.asar/common/atom-binding-setup.js:7:16)
at Object.<anonymous> (/Users/az/Programmierung/electron-quick-start/node_modules/electron/dist/Electron.app/Contents/Resources/electron.asar/browser/api/screen.js:2:34)
at Object.<anonymous> (/Users/az/Programmierung/electron-quick-start/node_modules/electron/dist/Electron.app/Contents/Resources/electron.asar/browser/api/screen.js:10:3)
at Module._compile (internal/modules/cjs/loader.js:711:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:722:10)
at Module.load (internal/modules/cjs/loader.js:620:32)
at tryModuleLoad (internal/modules/cjs/loader.js:559:12)
at Function.Module._load (internal/modules/cjs/loader.js:551:3)
at Module.require (internal/modules/cjs/loader.js:658:17)

albertz · 2023-01-13T22:50:01Z

Some of the other frontends seem to work partially, with various other bugs. E.g. -Bqt works somewhat, -B (without args) also works and opens a new tab in Chrome (is thy intended?) pointing to the local URL, -Bchrome-app also works and starts it as a standalone Chrome app.

PerBothner · 2023-01-13T22:53:43Z

When I try the Electron front-end - it works - but using a really old Electron 8 in /usr/local/lib/node_modules/electron/cli.js.

I installed the latest Electron using brew install --cask electron. However, that is not instaled in the PATH - and it can't be opened "because the developer cannot be verified". May have to create a real Electron app, as opposed to the using the distributed electron binary like I do on Linux. Sigh.

PerBothner · 2023-01-13T22:54:58Z

I have no idea where the "Cannot require "screen" module before app is ready" message is coming from.

PerBothner · 2023-01-13T22:59:42Z

The -B flag is (I believe) the same as -Bbrowser, which should open Domterm in your default browser.

What bugs are you seeing with -Bqt? I know there are some issues - but what is bad enough to qualify it as working "somewhat"?

albertz · 2023-01-13T23:15:03Z

What bugs are you seeing with -Bqt? I know there are some issues - but what is bad enough to qualify it as working "somewhat"?

The window decorations very much look non-native. It's smaller than any other apps, the colors are totally wrong, there is a strange icon left-aligned, there is no centered title text.

Moving the window around does not really work. I need to click the window title bar at least 5 times or so until drag & drop of the window works.

Moving the window around creates a bit of flickering.

Resizing the window is very slow, takes at least 0.5-1 sec to refresh the window, which is very unexpected. All other windows can be resized without any such effect.

Sometimes key events are ignored. I need to click the window again that it gets the inputs again.

Zoom out does not work? It does nothing. Zoom out (pane) seems to work though.

When I type exit in the shell, or when I manually close the main window, the main window closes. But then I can't open a new window? At least I don't have the full menu anymore, I just have those entries "About ..." and "Quit ...".

Quitting the app does not work. I click it in the menu, or I press Cmd + Q, but nothing happens.

When I quit it via the Dock, that works. However, at the next start, with ./bin/domterm -Bqt, it then crashes immediately, with the stack trace:

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   libwebsockets.19.dylib        	       0x104793f94 lws_callback_on_writable + 12
1   domterm                       	       0x10439b590 do_run_browser(options*, tty_client*, char const*, int) + 4328 (server.cc:1017)
2   domterm                       	       0x10439b590 do_run_browser(options*, tty_client*, char const*, int) + 4328 (server.cc:1017)
3   domterm                       	       0x1043a871c display_session(options*, pty_client*, char const*, window_kind) + 4272 (protocol.cc:2704)
4   domterm                       	       0x1043ad1e4 new_action(int, char const* const*, lws*, options*) + 248 (protocol.cc:2729)
5   domterm                       	       0x1043ad7b0 handle_command(int, char const* const*, lws*, options*) + 568 (protocol.cc:3057)
6   domterm                       	       0x1043c4c38 callback_cmd(lws*, lws_callback_reasons, void*, void*, unsigned long) + 2392 (command-connect.cc:425)
7   libwebsockets.19.dylib        	       0x1047959ac user_callback_handle_rxflow + 60
8   libwebsockets.19.dylib        	       0x1047ac71c rops_handle_POLLIN_raw_file + 68
9   libwebsockets.19.dylib        	       0x104794bb8 lws_service_fd_tsi + 392
10  libwebsockets.19.dylib        	       0x10477d6dc _lws_plat_service_forced_tsi + 108
11  libwebsockets.19.dylib        	       0x10477d998 _lws_plat_service_tsi + 572
12  libwebsockets.19.dylib        	       0x104794c64 lws_service + 80
13  domterm                       	       0x10439d28c main + 2344 (server.cc:1693)
14  dyld                          	       0x1046c908c start + 520

And error:

Unexpected disconnect from domterm server.

PerBothner · 2023-01-13T23:15:39Z

I checked in a change to Makefile.am to make the rule for dt-wry/src/versions.rs more robust.

Could you update, autoreconf -i, re-run configure, and make dt-wry/src/versions.rs and see what happens?

albertz · 2023-01-13T23:19:41Z

I checked in a change to Makefile.am to make the rule for dt-wry/src/versions.rs more robust.

Could you update, autoreconf -i, re-run configure, and make dt-wry/src/versions.rs and see what happens?

It seems to work now.

Also domterm -Bwry seems to work. It has some similar bugs as Qt, e.g. the window decorations are non-native. Even more so, i.e. the menu bar is incorrectly in the window and not in the OSX menu bar. Also, the menu behaves strangely (e.g. it does not close when I move away the mouse, I need to click somewhere first). Also selecting Quit in the menu does not work, it just blanks the screen and I can't do anything anymore.

PerBothner · 2023-01-13T23:19:47Z

Could you try:

bin/domterm -Bqt titlebar=system

Is that more pleasant?

albertz · 2023-01-13T23:20:56Z

Could you try:
bin/domterm -Bqt titlebar=system
Is that more pleasant?

Ah, that fixes the non-native window decorations. And now moving around the window also works properly.

PerBothner · 2023-01-14T00:11:23Z

I fixed the Zoom In/Out menu items (and keyboard shortcuts) for the Qt front-end.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MacOS build instructions wrong #116

MacOS build instructions wrong #116

albertz commented Jan 13, 2023

PerBothner commented Jan 13, 2023

albertz commented Jan 13, 2023 •

edited

Loading

albertz commented Jan 13, 2023 •

edited

Loading

albertz commented Jan 13, 2023 •

edited

Loading

albertz commented Jan 13, 2023 •

edited

Loading

albertz commented Jan 13, 2023 •

edited

Loading

albertz commented Jan 13, 2023

PerBothner commented Jan 13, 2023

albertz commented Jan 13, 2023

PerBothner commented Jan 13, 2023

albertz commented Jan 13, 2023

PerBothner commented Jan 13, 2023

albertz commented Jan 13, 2023

albertz commented Jan 13, 2023

albertz commented Jan 13, 2023 •

edited

Loading

albertz commented Jan 13, 2023

PerBothner commented Jan 13, 2023

PerBothner commented Jan 13, 2023

PerBothner commented Jan 13, 2023

albertz commented Jan 13, 2023 •

edited

Loading

PerBothner commented Jan 13, 2023

albertz commented Jan 13, 2023

PerBothner commented Jan 13, 2023

albertz commented Jan 13, 2023

PerBothner commented Jan 14, 2023

MacOS build instructions wrong #116

MacOS build instructions wrong #116

Comments

albertz commented Jan 13, 2023

PerBothner commented Jan 13, 2023

albertz commented Jan 13, 2023 • edited Loading

albertz commented Jan 13, 2023 • edited Loading

albertz commented Jan 13, 2023 • edited Loading

albertz commented Jan 13, 2023 • edited Loading

albertz commented Jan 13, 2023 • edited Loading

albertz commented Jan 13, 2023

PerBothner commented Jan 13, 2023

albertz commented Jan 13, 2023

PerBothner commented Jan 13, 2023

albertz commented Jan 13, 2023

PerBothner commented Jan 13, 2023

albertz commented Jan 13, 2023

albertz commented Jan 13, 2023

albertz commented Jan 13, 2023 • edited Loading

albertz commented Jan 13, 2023

PerBothner commented Jan 13, 2023

PerBothner commented Jan 13, 2023

PerBothner commented Jan 13, 2023

albertz commented Jan 13, 2023 • edited Loading

PerBothner commented Jan 13, 2023

albertz commented Jan 13, 2023

PerBothner commented Jan 13, 2023

albertz commented Jan 13, 2023

PerBothner commented Jan 14, 2023

albertz commented Jan 13, 2023 •

edited

Loading

albertz commented Jan 13, 2023 •

edited

Loading

albertz commented Jan 13, 2023 •

edited

Loading

albertz commented Jan 13, 2023 •

edited

Loading

albertz commented Jan 13, 2023 •

edited

Loading

albertz commented Jan 13, 2023 •

edited

Loading

albertz commented Jan 13, 2023 •

edited

Loading