GNU bug report logs -
#47558
28.0.50; dlopen 'image not found' gccemacs native-lisp macos
Previous Next
Reported by: Bryan O'Brien <bryan.m.obrien <at> gmail.com>
Date: Fri, 2 Apr 2021 03:08:01 UTC
Severity: normal
Found in version 28.0.50
Done: Andrea Corallo <akrl <at> sdf.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47558 in the body.
You can then email your comments to 47558 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Fri, 02 Apr 2021 03:08:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Bryan O'Brien <bryan.m.obrien <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Fri, 02 Apr 2021 03:08:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Compiling gccemacs from latest git branch.
Emacs compiles with warnings but no errors.
Starting Emacs with fails with:
gccemacs/nextstep/Emacs.app/Contents/MacOS/Emacs -Q --debug-init
emacs:
dlopen(/Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/MacOS/../native-lisp/28.0.50-2865d7b3/window-0d1b8b93-513ac8ca.eln, 1): image not found
Workaround is as follows:
cd ~/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents
ln -s ~/src/gnu-emacs/28/gccemacs/native-lisp .
In GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin20.4.0, NS appkit-2022.44 Version 11.3 (Build 20E5224a))
of 2021-04-01 built on Cuchulainn.local
Repository revision: 978afd788fd0496540f715b83f18ed390ca8d5a4
Repository branch: feature/native-comp
Windowing system distributor 'Apple', version 10.3.2022
System Description: macOS 11.3
Configured using:
'configure --with-native-compilation --with-x-widgets
CFLAGS=-I/usr/local/opt/libgccjit/include
LDFLAGS=-L/usr/local/opt/libgccjit/lib/gcc/10'
Configured features:
ACL DBUS GLIB GNUTLS JSON LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY
KQUEUE NS PDUMPER PNG RSVG THREADS TOOLKIT_SCROLL_BARS XIM ZLIB
Important settings:
value of $LC_ALL: en_US.UTF-8
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: mu4e:main
Minor modes in effect:
helm-descbinds-mode: t
helm-mode: t
helm-flx-mode: t
helm--remap-mouse-mode: t
async-bytecomp-package-mode: t
global-evil-surround-mode: t
global-git-gutter+-mode: t
flycheck-pos-tip-mode: t
global-flycheck-mode: t
show-smartparens-global-mode: t
yas-global-mode: t
evil-escape-mode: t
global-display-line-numbers-mode: t
recentf-mode: t
global-git-commit-mode: t
winner-mode: t
projectile-mode: t
winum-mode: t
pupo-mode: t
global-vi-tilde-fringe-mode: t
global-undo-tree-mode: t
undo-tree-mode: t
spaceline-info-mode: t
spaceline-helm-mode: t
save-place-mode: t
savehist-mode: t
persp-mode: t
global-hl-todo-mode: t
purpose-mode: t
eyebrowse-mode: t
global-anzu-mode: t
anzu-mode: t
editorconfig-mode: t
clean-aindent-mode: t
which-key-mode: t
override-global-mode: t
shell-dirtrack-mode: t
evil-mode: t
evil-local-mode: t
spacemacs-leader-override-mode: t
global-spacemacs-leader-override-mode: t
global-hl-line-mode: t
xterm-mouse-mode: t
global-auto-revert-mode: t
ido-vertical-mode: t
global-page-break-lines-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
overwrite-mode: overwrite-mode-binary
Load-path shadows:
/Users/bobrien/.emacs.d/elpa/28.0/develop/modus-vivendi-theme-0.13.2/modus-vivendi-theme hides /Users/bobrien/.emacs.d/elpa/28.0/develop/modus-themes-20210327.2018/modus-vivendi-theme
/Users/bobrien/.emacs.d/elpa/28.0/develop/modus-operandi-theme-0.13.2/modus-operandi-theme hides /Users/bobrien/.emacs.d/elpa/28.0/develop/modus-themes-20210327.2018/modus-operandi-theme
/Users/bobrien/.emacs.d/elpa/28.0/develop/magit-section-20210224.1417/magit-section hides /Users/bobrien/.emacs.d/elpa/28.0/develop/magit-20210327.1617/magit-section
/Users/bobrien/.emacs.d/elpa/28.0/develop/spinner-1.7.3/spinner hides /Users/bobrien/.emacs.d/core/libs/spinner
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-stan hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-stan
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-exp hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-exp
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-J hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-J
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-emacs-lisp hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-emacs-lisp
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-css hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-css
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-lob hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-lob
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ol-irc hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ol-irc
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-forth hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-forth
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-macs hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-macs
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-version hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-version
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-scheme hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-scheme
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ox hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ox
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-abc hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-abc
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-C hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-C
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-capture hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-capture
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-ref hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-ref
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-clojure hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-clojure
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-mouse hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-mouse
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-ledger hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-ledger
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-ctags hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-ctags
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-entities hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-entities
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-archive hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-archive
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-screen hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-screen
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ol-bibtex hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ol-bibtex
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-haskell hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-haskell
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-asymptote hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-asymptote
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-table hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-table
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ol-eww hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ol-eww
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ox-org hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ox-org
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-num hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-num
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-plot hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-plot
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ol-rmail hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ol-rmail
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-awk hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-awk
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-groovy hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-groovy
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-octave hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-octave
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-faces hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-faces
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-colview hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-colview
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-R hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-R
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-refile hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-refile
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-timer hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-timer
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-ebnf hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-ebnf
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-mobile hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-mobile
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-fortran hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-fortran
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-shell hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-shell
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-perl hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-perl
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-sqlite hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-sqlite
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-sed hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-sed
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-list hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-list
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-ruby hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-ruby
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-eval hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-eval
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-habit hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-habit
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-clock hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-clock
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-goto hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-goto
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ox-html hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ox-html
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-src hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-src
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-lisp hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-lisp
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ol-eshell hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ol-eshell
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-ditaa hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-ditaa
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-pcomplete hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-pcomplete
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-lint hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-lint
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ox-latex hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ox-latex
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-sass hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-sass
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-io hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-io
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-tangle hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-tangle
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-calc hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-calc
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-java hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-java
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ox-icalendar hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ox-icalendar
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ol-mhe hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ol-mhe
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-attach-git hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-attach-git
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ox-md hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ox-md
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ox-beamer hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ox-beamer
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-element hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-element
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-protocol hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-protocol
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-mscgen hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-mscgen
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-gnuplot hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-gnuplot
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-tempo hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-tempo
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-latex hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-latex
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ol-w3m hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ol-w3m
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-id hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-id
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-vala hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-vala
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ox-man hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ox-man
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-feed hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-feed
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-lua hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-lua
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-table hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-table
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-ocaml hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-ocaml
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-coq hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-coq
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ol-gnus hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ol-gnus
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-picolisp hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-picolisp
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-indent hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-indent
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-lilypond hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-lilypond
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-matlab hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-matlab
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-datetree hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-datetree
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ol-docview hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ol-docview
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-python hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-python
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-makefile hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-makefile
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-duration hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-duration
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-agenda hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-agenda
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-dot hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-dot
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-js hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-js
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ox-publish hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ox-publish
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-inlinetask hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-inlinetask
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-org hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-org
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-keys hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-keys
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-core hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-core
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-compat hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-compat
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ol hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ol
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ox-odt hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ox-odt
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ol-info hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ol-info
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-plantuml hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-plantuml
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-eshell hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-eshell
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ox-ascii hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ox-ascii
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-loaddefs hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-loaddefs
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-hledger hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-hledger
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-maxima hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-maxima
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ol-bbdb hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ol-bbdb
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-macro hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-macro
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-sql hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-sql
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-attach hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-attach
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-processing hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-processing
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ox-texinfo hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ox-texinfo
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-crypt hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-crypt
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-footnote hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-footnote
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/org-install hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/org-install
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-comint hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-comint
/Users/bobrien/.emacs.d/elpa/28.0/develop/org-plus-contrib-20210322/ob-shen hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ob-shen
/Users/bobrien/.emacs.d/elpa/28.0/develop/hierarchy-20190425.842/hierarchy hides /Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/Resources/lisp/emacs-lisp/hierarchy
Features:
(shadow face-remap emacsbug flx tramp-archive tramp-gvfs dbus xml
helm-command helm-elisp helm-eval edebug backtrace helm-info
helm-descbinds helm-mode helm-files helm-buffers helm-occur helm-tags
helm-locate helm-grep helm-regexp helm-utils helm-help helm-types
helm-flx helm async-bytecomp helm-global-bindings helm-source
helm-multi-match helm-lib evil-surround git-gutter-fringe+ fringe-helper
git-gutter+ tramp tramp-loaddefs trampver tramp-integration files-x
tramp-compat ls-lisp goto-addr vc-mtn vc-hg vc-git vc-bzr vc-src vc-sccs
vc-svn vc-cvs vc-rcs vc vc-dispatcher auto-highlight-symbol
evil-lisp-state flycheck-pos-tip pos-tip flycheck highlight-numbers
parent-mode highlight-parentheses hideshow rainbow-delimiters
smartparens-config smartparens-org smartparens-markdown smartparens-text
smartparens yasnippet-snippets yasnippet sh-script smie executable
editorconfig-core editorconfig-core-handle editorconfig-fnmatch
evil-escape display-line-numbers recentf tree-widget epa-file
auth-source-pass org-mu4e ox-gfm ox-md ox-odt rng-loc rng-uri rng-parse
rng-match rng-dt rng-util rng-pttrn nxml-parse nxml-ns nxml-enc xmltok
nxml-util ox-latex ox-icalendar ox-html table ox-ascii ox-publish ox
org-element avl-tree generator mu4e-org orgit git-rebase forge-list
forge-commands forge-semi forge-bitbucket buck forge-gogs gogs
forge-gitea gtea forge-gitlab glab forge-github ghub-graphql treepy
gsexp ghub gnutls forge-notify forge-revnote forge-pullreq forge-issue
forge-topic parse-time iso8601 bug-reference forge-post markdown-mode
forge-repo forge forge-core forge-db closql emacsql-sqlite emacsql
emacsql-compiler url-http url-auth url-gw nsm evil-collection-magit
magit-submodule magit-obsolete magit-popup magit-blame magit-stash
magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone
magit-remote magit-commit magit-sequence magit-notes magit-worktree
magit-tag magit-merge magit-branch magit-reset magit-files magit-refs
magit-status magit magit-repos magit-apply magit-wip magit-log
which-func magit-diff smerge-mode diff-mode git-commit log-edit
pcvs-util add-log magit-core magit-autorevert magit-margin
magit-transient magit-process with-editor magit-mode transient magit-git
magit-section magit-utils crm org ob ob-tangle ob-ref ob-lob ob-table
ob-exp org-macro org-footnote org-src ob-comint org-pcomplete org-list
org-faces org-entities org-version ob-emacs-lisp ob-core ob-eval
org-table ol org-keys org-compat org-macs org-loaddefs find-func
gnus-dired mu4e desktop frameset mu4e-main mu4e-view cal-menu calendar
cal-loaddefs mu4e-headers mu4e-compose mu4e-context mu4e-draft
mu4e-actions rfc2368 smtpmail sendmail mu4e-mark mu4e-message flow-fill
mu4e-proc mu4e-utils doc-view jka-compr image-mode exif mu4e-lists
mu4e-vars message rmc puny rfc822 mml mml-sec epa gnus-util rmail
rmail-loaddefs time-date mailabbrev mail-utils gmm-utils mailheader
mu4e-meta winner server async projectile grep compile
text-property-search diminish xterm-color ws-butler winum
spacemacs-purpose-popwin window-purpose-x ibuf-macs imenu-list imenu
ibuf-ext ibuffer ibuffer-loaddefs evil-collection-dired dired
dired-loaddefs vi-tilde-fringe undo-tree diff symbol-overlay
string-inflection string-edit spaceline-all-the-icons
spaceline-all-the-icons-separators spaceline-all-the-icons-segments
all-the-icons all-the-icons-faces data-material data-weathericons
data-octicons data-fileicons data-faicons data-alltheicons memoize
spaceline-config spaceline-segments spaceline powerline
powerline-separators color powerline-themes saveplace savehist posframe
popwin persp-mode osx-trash org-rich-yank multi-line multi-line-find
multi-line-enter multi-line-decorator multi-line-respace
multi-line-shared shut-up multi-line-cycle multi-line-candidate hl-todo
window-purpose window-purpose-fixes window-purpose-prefix-overload
window-purpose-switch let-alist window-purpose-layout
window-purpose-core window-purpose-configuration window-purpose-utils
eyebrowse evil-unimpaired f evil-textobj-line evil-mc
evil-mc-command-execute evil-mc-command-record evil-mc-cursor-make
evil-mc-region evil-mc-cursor-state evil-mc-undo evil-mc-vars
evil-mc-known-commands evil-mc-common evil-easymotion
evil-collection-buff-menu evil-collection annalist evil-anzu anzu emr
popup s dash editorconfig noutline outline drag-stuff clean-aindent-mode
helm-easymenu cl hybrid-mode evil-evilified-state which-key use-package
use-package-ensure use-package-delight use-package-diminish
use-package-bind-key bind-key use-package-core hydra lv evil
evil-integration evil-maps evil-commands reveal flyspell ispell
evil-jumps evil-command-window evil-types evil-search evil-ex shell
pcomplete comint ansi-color evil-macros evil-repeat evil-states
evil-core evil-common windmove thingatpt rect evil-digraphs evil-vars
ring bind-map quelpa mm-decode mm-bodies mm-encode mail-parse rfc2231
rfc2047 rfc2045 mm-util ietf-drums mail-prsvr lisp-mnt help-fns
radix-tree hl-line xt-mouse autorevert filenotify comp comp-cstr
cl-extra disp-table afternoon-theme format-spec info finder-inf
ido-vertical-mode ido core-spacemacs core-spacebind core-use-package-ext
core-transient-state core-micro-state core-toggle core-keybindings
core-fonts-support core-themes-support core-display-init core-jump
core-release-management core-custom-settings core-configuration-layer
eieio-compat core-progress-bar core-spacemacs-buffer core-funcs
spacemacs-ht inline help-mode warnings package browse-url url url-proxy
url-privacy url-expand url-methods url-history url-cookie url-domsuf
url-util mailcap url-handlers url-parse auth-source cl-seq
password-cache json map url-vars eieio eieio-core eieio-loaddefs epg
epg-config core-command-line pcase core-debug edmacro kmacro derived
profiler core-hooks page-break-lines easy-mmode core-env load-env-vars
rx core-dotspacemacs advice core-customization validate cus-edit pp
cus-start cus-load wid-edit seq byte-opt bytecomp byte-compile cconv
core-emacs-backports core-compilation core-dumper subr-x spinner cl-macs
gv cl-loaddefs cl-lib iso-transl tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/ns-win ns-win
ucs-normalize mule-util term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
kqueue cocoa ns lcms2 multi-tty make-network-process nativecomp emacs)
Memory information:
((conses 16 1092259 903877)
(symbols 48 66381 9)
(strings 32 249629 170669)
(string-bytes 1 9258978)
(vectors 16 103579)
(vector-slots 8 1950135 778485)
(floats 8 1396 5940)
(intervals 56 4131 1596)
(buffers 992 17))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Fri, 02 Apr 2021 05:47:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 47558 <at> debbugs.gnu.org (full text, mbox):
> From: Bryan O'Brien <bryan.m.obrien <at> gmail.com>
> Date: Thu, 01 Apr 2021 20:36:43 -0500
>
>
> Compiling gccemacs from latest git branch.
> Emacs compiles with warnings but no errors.
> Starting Emacs with fails with:
>
> gccemacs/nextstep/Emacs.app/Contents/MacOS/Emacs -Q --debug-init
> emacs:
> dlopen(/Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/MacOS/../native-lisp/28.0.50-2865d7b3/window-0d1b8b93-513ac8ca.eln, 1): image not found
>
> Workaround is as follows:
>
> cd ~/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents
> ln -s ~/src/gnu-emacs/28/gccemacs/native-lisp .
Do you understand the need for this workaround on macOS? If so, can
you explain what's going on here?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Fri, 02 Apr 2021 16:30:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 47558 <at> debbugs.gnu.org (full text, mbox):
On Fri, Apr 02, 2021 at 08:46:35AM +0300, Eli Zaretskii wrote:
> > From: Bryan O'Brien <bryan.m.obrien <at> gmail.com>
> > Date: Thu, 01 Apr 2021 20:36:43 -0500
> >
> >
> > Compiling gccemacs from latest git branch.
> > Emacs compiles with warnings but no errors.
> > Starting Emacs with fails with:
> >
> > gccemacs/nextstep/Emacs.app/Contents/MacOS/Emacs -Q --debug-init
> > emacs:
> > dlopen(/Users/bobrien/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents/MacOS/../native-lisp/28.0.50-2865d7b3/window-0d1b8b93-513ac8ca.eln, 1): image not found
> >
> > Workaround is as follows:
> >
> > cd ~/src/gnu-emacs/28/gccemacs/nextstep/Emacs.app/Contents
> > ln -s ~/src/gnu-emacs/28/gccemacs/native-lisp .
>
> Do you understand the need for this workaround on macOS? If so, can
> you explain what's going on here?
It looks to me like the "-D" flag for the install command isn't
available on macOS. I think the equivalent is "-d", which appears to
do something different again on GNU/Linux.
Line 752 of Makefile.in:
### Install native compiled Lisp files.
install-eln:
ifeq ($(HAVE_NATIVE_COMP),yes)
find native-lisp -type f -exec ${INSTALL_DATA} -D "{}" "$(ELN_DESTDIR){}" \;
endif
^^
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Fri, 02 Apr 2021 18:40:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 47558 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 2 Apr 2021 17:29:22 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: Bryan O'Brien <bryan.m.obrien <at> gmail.com>, 47558 <at> debbugs.gnu.org
>
> It looks to me like the "-D" flag for the install command isn't
> available on macOS. I think the equivalent is "-d", which appears to
> do something different again on GNU/Linux.
>
> Line 752 of Makefile.in:
>
> ### Install native compiled Lisp files.
> install-eln:
> ifeq ($(HAVE_NATIVE_COMP),yes)
> find native-lisp -type f -exec ${INSTALL_DATA} -D "{}" "$(ELN_DESTDIR){}" \;
> endif
We should use mkdir explicitly, I think.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Fri, 02 Apr 2021 21:53:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 47558 <at> debbugs.gnu.org (full text, mbox):
On Fri, Apr 02, 2021 at 09:39:32PM +0300, Eli Zaretskii wrote:
> > Date: Fri, 2 Apr 2021 17:29:22 +0100
> > From: Alan Third <alan <at> idiocy.org>
> > Cc: Bryan O'Brien <bryan.m.obrien <at> gmail.com>, 47558 <at> debbugs.gnu.org
> >
> > It looks to me like the "-D" flag for the install command isn't
> > available on macOS. I think the equivalent is "-d", which appears to
> > do something different again on GNU/Linux.
> >
> > Line 752 of Makefile.in:
> >
> > ### Install native compiled Lisp files.
> > install-eln:
> > ifeq ($(HAVE_NATIVE_COMP),yes)
> > find native-lisp -type f -exec ${INSTALL_DATA} -D "{}" "$(ELN_DESTDIR){}" \;
> > endif
>
> We should use mkdir explicitly, I think.
I think I've figured that out, but there's actually another wrinkle.
'make install' is installing the eln files in
nextstep/Emacs.app/Contents/MacOS/lib/emacs/28.0.50/native-lisp/28.0.50-24e3df15
but the emacs executable is looking for them in
nextstep/Emacs.app/Contents/MacOS/../native-lisp/28.0.50-24e3df15/
And just to add the confusion I feel they should *actually* be
installed in
nextstep/Emacs.app/Contents/Resources/native-lisp
or similar.
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Sat, 03 Apr 2021 06:33:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 47558 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 2 Apr 2021 22:51:56 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: bryan.m.obrien <at> gmail.com, 47558 <at> debbugs.gnu.org
>
> I think I've figured that out, but there's actually another wrinkle.
> 'make install' is installing the eln files in
>
> nextstep/Emacs.app/Contents/MacOS/lib/emacs/28.0.50/native-lisp/28.0.50-24e3df15
>
> but the emacs executable is looking for them in
>
> nextstep/Emacs.app/Contents/MacOS/../native-lisp/28.0.50-24e3df15/
The above happens on all platforms, so it isn't macOS specific, right?
Or are you saying there's something macOS specific in ${libdir}? in
the latter case, what's the story there?
> And just to add the confusion I feel they should *actually* be
> installed in
>
> nextstep/Emacs.app/Contents/Resources/native-lisp
>
> or similar.
Why is that?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Sat, 03 Apr 2021 14:02:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 47558 <at> debbugs.gnu.org (full text, mbox):
On Sat, Apr 03, 2021 at 09:32:20AM +0300, Eli Zaretskii wrote:
> > Date: Fri, 2 Apr 2021 22:51:56 +0100
> > From: Alan Third <alan <at> idiocy.org>
> > Cc: bryan.m.obrien <at> gmail.com, 47558 <at> debbugs.gnu.org
> >
> > I think I've figured that out, but there's actually another wrinkle.
> > 'make install' is installing the eln files in
> >
> > nextstep/Emacs.app/Contents/MacOS/lib/emacs/28.0.50/native-lisp/28.0.50-24e3df15
> >
> > but the emacs executable is looking for them in
> >
> > nextstep/Emacs.app/Contents/MacOS/../native-lisp/28.0.50-24e3df15/
>
> The above happens on all platforms, so it isn't macOS specific, right?
> Or are you saying there's something macOS specific in ${libdir}? in
> the latter case, what's the story there?
I think that is what happens on other platforms, but the issue here is
that the emacs executable is placed in an unusual position relative to
the other files because of the NS app bundle format. I'll try to
explain it below, but my knowledge is not deep.
> > And just to add the confusion I feel they should *actually* be
> > installed in
> >
> > nextstep/Emacs.app/Contents/Resources/native-lisp
> >
> > or similar.
>
> Why is that?
NS uses a special directory structure that appears to the system as an
application. It looks something like this:
Emacs.app
+ Contents
+ MacOS
| + Emacs <-- The executable
+ Resources
| + icons
| + etc
| + include
| + info
| + lisp
| + ...
+ Info.plist
+ ...
The layout is ever so slightly different under GNUstep.
As far as I can tell the only thing that should be in the
Contents/MacOS directory are executables, practically everything else
lives under Resources.
nsterm.m has three functions for finding the correct path for etc,
exec and the lisp load path. I imagine what we want to do is install
the eln files under Resources, then add a new function that returns the
location of them and use it to set the correct path at the point where
Emacs loads the files.
It's not entirely clear to me where the load path is set, is it
fixup_eln_load_path (Lisp_Object directory)
in comp.c?
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Sat, 03 Apr 2021 14:19:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 47558 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 3 Apr 2021 15:01:20 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: bryan.m.obrien <at> gmail.com, 47558 <at> debbugs.gnu.org
>
> It's not entirely clear to me where the load path is set, is it
>
> fixup_eln_load_path (Lisp_Object directory)
>
> in comp.c?
I hope Andrea (CC'ed) will be able to answer that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Sun, 04 Apr 2021 07:11:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 47558 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Sat, 3 Apr 2021 15:01:20 +0100
>> From: Alan Third <alan <at> idiocy.org>
>> Cc: bryan.m.obrien <at> gmail.com, 47558 <at> debbugs.gnu.org
>>
>> It's not entirely clear to me where the load path is set, is it
>>
>> fixup_eln_load_path (Lisp_Object directory)
>>
>> in comp.c?
>
> I hope Andrea (CC'ed) will be able to answer that.
Okay, as window is loaded and dumped during the build
`comp-eln-load-path' here doesn't come into play.
While resurrecting from dump we locate preloaded eln files by filename
(relative to the emacs executable position). Indeed the complication is
that we have to support both uninstalled but also installed builds.
To do that before dumping we inform Emacs of where will have to search
the eln files if installed. We do that using ELN_DESTDIR defined
Makefile.in:326.
If the directory structure on MacOS is different I guess we have to add
the correct information there.
Regards
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Mon, 05 Apr 2021 10:35:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 47558 <at> debbugs.gnu.org (full text, mbox):
On Sun, Apr 04, 2021 at 07:10:50AM +0000, Andrea Corallo wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> Date: Sat, 3 Apr 2021 15:01:20 +0100
> >> From: Alan Third <alan <at> idiocy.org>
> >> Cc: bryan.m.obrien <at> gmail.com, 47558 <at> debbugs.gnu.org
> >>
> >> It's not entirely clear to me where the load path is set, is it
> >>
> >> fixup_eln_load_path (Lisp_Object directory)
> >>
> >> in comp.c?
> >
> > I hope Andrea (CC'ed) will be able to answer that.
>
> Okay, as window is loaded and dumped during the build
> `comp-eln-load-path' here doesn't come into play.
>
> While resurrecting from dump we locate preloaded eln files by filename
> (relative to the emacs executable position). Indeed the complication is
> that we have to support both uninstalled but also installed builds.
>
> To do that before dumping we inform Emacs of where will have to search
> the eln files if installed. We do that using ELN_DESTDIR defined
> Makefile.in:326.
>
> If the directory structure on MacOS is different I guess we have to add
> the correct information there.
No matter what I set ELN_DESTDIR to, emacs still looks in
/Users/alan/src/emacs/native/nextstep/Emacs.app/Contents/MacOS/../native-lisp/28.0.50-24e3df15
so something isn't being updated, I guess?
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Mon, 05 Apr 2021 20:22:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 47558 <at> debbugs.gnu.org (full text, mbox):
Alan Third <alan <at> idiocy.org> writes:
> On Sun, Apr 04, 2021 at 07:10:50AM +0000, Andrea Corallo wrote:
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> Date: Sat, 3 Apr 2021 15:01:20 +0100
>> >> From: Alan Third <alan <at> idiocy.org>
>> >> Cc: bryan.m.obrien <at> gmail.com, 47558 <at> debbugs.gnu.org
>> >>
>> >> It's not entirely clear to me where the load path is set, is it
>> >>
>> >> fixup_eln_load_path (Lisp_Object directory)
>> >>
>> >> in comp.c?
>> >
>> > I hope Andrea (CC'ed) will be able to answer that.
>>
>> Okay, as window is loaded and dumped during the build
>> `comp-eln-load-path' here doesn't come into play.
>>
>> While resurrecting from dump we locate preloaded eln files by filename
>> (relative to the emacs executable position). Indeed the complication is
>> that we have to support both uninstalled but also installed builds.
>>
>> To do that before dumping we inform Emacs of where will have to search
>> the eln files if installed. We do that using ELN_DESTDIR defined
>> Makefile.in:326.
>>
>> If the directory structure on MacOS is different I guess we have to add
>> the correct information there.
>
> No matter what I set ELN_DESTDIR to, emacs still looks in
>
> /Users/alan/src/emacs/native/nextstep/Emacs.app/Contents/MacOS/../native-lisp/28.0.50-24e3df15
>
> so something isn't being updated, I guess?
That's possible, could you specify the full procedure you've used to
reach this point?
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Mon, 05 Apr 2021 21:15:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 47558 <at> debbugs.gnu.org (full text, mbox):
On Mon, Apr 05, 2021 at 08:21:25PM +0000, Andrea Corallo wrote:
> Alan Third <alan <at> idiocy.org> writes:
>
> > On Sun, Apr 04, 2021 at 07:10:50AM +0000, Andrea Corallo wrote:
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >>
> >> >> Date: Sat, 3 Apr 2021 15:01:20 +0100
> >> >> From: Alan Third <alan <at> idiocy.org>
> >> >> Cc: bryan.m.obrien <at> gmail.com, 47558 <at> debbugs.gnu.org
> >> >>
> >> >> It's not entirely clear to me where the load path is set, is it
> >> >>
> >> >> fixup_eln_load_path (Lisp_Object directory)
> >> >>
> >> >> in comp.c?
> >> >
> >> > I hope Andrea (CC'ed) will be able to answer that.
> >>
> >> Okay, as window is loaded and dumped during the build
> >> `comp-eln-load-path' here doesn't come into play.
> >>
> >> While resurrecting from dump we locate preloaded eln files by filename
> >> (relative to the emacs executable position). Indeed the complication is
> >> that we have to support both uninstalled but also installed builds.
> >>
> >> To do that before dumping we inform Emacs of where will have to search
> >> the eln files if installed. We do that using ELN_DESTDIR defined
> >> Makefile.in:326.
> >>
> >> If the directory structure on MacOS is different I guess we have to add
> >> the correct information there.
> >
> > No matter what I set ELN_DESTDIR to, emacs still looks in
> >
> > /Users/alan/src/emacs/native/nextstep/Emacs.app/Contents/MacOS/../native-lisp/28.0.50-24e3df15
> >
> > so something isn't being updated, I guess?
>
> That's possible, could you specify the full procedure you've used to
> reach this point?
./autogen.sh
./configure --with-ns --with-native-compilation
make
make install
Note: make install fails, I've had to apply this patch
@@ -749,7 +753,8 @@ install-etc:
### Install native compiled Lisp files.
install-eln:
ifeq ($(HAVE_NATIVE_COMP),yes)
- find native-lisp -type f -exec ${INSTALL_DATA} -D "{}" "$(ELN_DESTDIR){}" \;
+ find native-lisp -type d -exec $(MKDIR_P) "$(ELN_DESTDIR){}" \; ; \
+ find native-lisp -type f -exec ${INSTALL_DATA} "{}" "$(ELN_DESTDIR){}" \;
endif
but if you were to try this with GNUstep I suspect that wouldn't be
needed.
And I've tried modifying ELN_DESTDIR with this
@@ -323,7 +323,11 @@ CONFIG_STATUS_FILES_IN =
COPYDIR = ${srcdir}/etc ${srcdir}/lisp
COPYDESTS = "$(DESTDIR)${etcdir}" "$(DESTDIR)${lispdir}"
-ELN_DESTDIR = $(DESTDIR)${libdir}/emacs/${version}/
+ifeq (${ns_self_contained},no)
+ ELN_DESTDIR = $(DESTDIR)${libdir}/emacs/${version}/
+else
+ ELN_DESTDIR = ${ns_appresdir}/
+endif
all: ${SUBDIR} info
which results in the .eln files being installed where I want, but
running the installed Emacs (nextstep/Emacs.app/MacOS/Emacs) still
gives the error
emacs:
dlopen(/Users/alan/src/emacs/native/nextstep/Emacs.app/Contents/MacOS/../native-lisp/28.0.50-24e3df15/window-0d1b8b93-513ac8ca.eln,
1): image not found
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Tue, 06 Apr 2021 07:57:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 47558 <at> debbugs.gnu.org (full text, mbox):
Alan Third <alan <at> idiocy.org> writes:
> On Mon, Apr 05, 2021 at 08:21:25PM +0000, Andrea Corallo wrote:
>> Alan Third <alan <at> idiocy.org> writes:
>>
>> > On Sun, Apr 04, 2021 at 07:10:50AM +0000, Andrea Corallo wrote:
>> >> Eli Zaretskii <eliz <at> gnu.org> writes:
>> >>
>> >> >> Date: Sat, 3 Apr 2021 15:01:20 +0100
>> >> >> From: Alan Third <alan <at> idiocy.org>
>> >> >> Cc: bryan.m.obrien <at> gmail.com, 47558 <at> debbugs.gnu.org
>> >> >>
>> >> >> It's not entirely clear to me where the load path is set, is it
>> >> >>
>> >> >> fixup_eln_load_path (Lisp_Object directory)
>> >> >>
>> >> >> in comp.c?
>> >> >
>> >> > I hope Andrea (CC'ed) will be able to answer that.
>> >>
>> >> Okay, as window is loaded and dumped during the build
>> >> `comp-eln-load-path' here doesn't come into play.
>> >>
>> >> While resurrecting from dump we locate preloaded eln files by filename
>> >> (relative to the emacs executable position). Indeed the complication is
>> >> that we have to support both uninstalled but also installed builds.
>> >>
>> >> To do that before dumping we inform Emacs of where will have to search
>> >> the eln files if installed. We do that using ELN_DESTDIR defined
>> >> Makefile.in:326.
>> >>
>> >> If the directory structure on MacOS is different I guess we have to add
>> >> the correct information there.
>> >
>> > No matter what I set ELN_DESTDIR to, emacs still looks in
>> >
>> > /Users/alan/src/emacs/native/nextstep/Emacs.app/Contents/MacOS/../native-lisp/28.0.50-24e3df15
>> >
>> > so something isn't being updated, I guess?
>>
>> That's possible, could you specify the full procedure you've used to
>> reach this point?
>
> ./autogen.sh
> ./configure --with-ns --with-native-compilation
> make
> make install
>
> Note: make install fails, I've had to apply this patch
>
>
> @@ -749,7 +753,8 @@ install-etc:
> ### Install native compiled Lisp files.
> install-eln:
> ifeq ($(HAVE_NATIVE_COMP),yes)
> - find native-lisp -type f -exec ${INSTALL_DATA} -D "{}" "$(ELN_DESTDIR){}" \;
> + find native-lisp -type d -exec $(MKDIR_P) "$(ELN_DESTDIR){}" \; ; \
> + find native-lisp -type f -exec ${INSTALL_DATA} "{}" "$(ELN_DESTDIR){}" \;
> endif
>
>
> but if you were to try this with GNUstep I suspect that wouldn't be
> needed.
>
> And I've tried modifying ELN_DESTDIR with this
>
>
> @@ -323,7 +323,11 @@ CONFIG_STATUS_FILES_IN =
> COPYDIR = ${srcdir}/etc ${srcdir}/lisp
> COPYDESTS = "$(DESTDIR)${etcdir}" "$(DESTDIR)${lispdir}"
>
> -ELN_DESTDIR = $(DESTDIR)${libdir}/emacs/${version}/
> +ifeq (${ns_self_contained},no)
> + ELN_DESTDIR = $(DESTDIR)${libdir}/emacs/${version}/
> +else
> + ELN_DESTDIR = ${ns_appresdir}/
> +endif
>
> all: ${SUBDIR} info
>
>
> which results in the .eln files being installed where I want, but
> running the installed Emacs (nextstep/Emacs.app/MacOS/Emacs) still
> gives the error
>
> emacs:
> dlopen(/Users/alan/src/emacs/native/nextstep/Emacs.app/Contents/MacOS/../native-lisp/28.0.50-24e3df15/window-0d1b8b93-513ac8ca.eln,
> 1): image not found
Hi Alan,
Okay the value of ELN_DESTDIR is used during dump to inform Emacs where
the eln will be located (src/Makefile.in:570) so redumping is necessary.
Have you tried redumping or rebuilding from scratch?
Thanks!
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Tue, 06 Apr 2021 10:01:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 47558 <at> debbugs.gnu.org (full text, mbox):
On Tue, Apr 06, 2021 at 07:56:46AM +0000, Andrea Corallo wrote:
> Alan Third <alan <at> idiocy.org> writes:
> > emacs:
> > dlopen(/Users/alan/src/emacs/native/nextstep/Emacs.app/Contents/MacOS/../native-lisp/28.0.50-24e3df15/window-0d1b8b93-513ac8ca.eln,
> > 1): image not found
>
> Hi Alan,
>
> Okay the value of ELN_DESTDIR is used during dump to inform Emacs where
> the eln will be located (src/Makefile.in:570) so redumping is necessary.
> Have you tried redumping or rebuilding from scratch?
Yes, I've tried 'make bootstrap' to no avail.
FWIW, as I mentioned earlier in this thread, which you may not have
seen, NS provides a method for detecting which paths to use if running
in the self contained bundle, which Emacs already uses for finding the
lisp path, exec path, etc. Would it be worth extending this to work
with the eln files?
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Tue, 06 Apr 2021 14:52:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 47558 <at> debbugs.gnu.org (full text, mbox):
Alan Third <alan <at> idiocy.org> writes:
> On Tue, Apr 06, 2021 at 07:56:46AM +0000, Andrea Corallo wrote:
>> Alan Third <alan <at> idiocy.org> writes:
>> > emacs:
>> > dlopen(/Users/alan/src/emacs/native/nextstep/Emacs.app/Contents/MacOS/../native-lisp/28.0.50-24e3df15/window-0d1b8b93-513ac8ca.eln,
>> > 1): image not found
>>
>> Hi Alan,
>>
>> Okay the value of ELN_DESTDIR is used during dump to inform Emacs where
>> the eln will be located (src/Makefile.in:570) so redumping is necessary.
>> Have you tried redumping or rebuilding from scratch?
>
> Yes, I've tried 'make bootstrap' to no avail.
could you share the output of like "make bootstrap V=1"? (go parallel if
you like)
> FWIW, as I mentioned earlier in this thread, which you may not have
> seen, NS provides a method for detecting which paths to use if running
> in the self contained bundle, which Emacs already uses for finding the
> lisp path, exec path, etc. Would it be worth extending this to work
> with the eln files?
I think talking about preloaded files we'll want to to stick to the
relative path to the binary as it should work on every system, but this
might information be useful in the future for the filename hashing.
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Tue, 06 Apr 2021 17:37:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 47558 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Apr 06, 2021 at 02:51:46PM +0000, Andrea Corallo wrote:
> Alan Third <alan <at> idiocy.org> writes:
>
> > On Tue, Apr 06, 2021 at 07:56:46AM +0000, Andrea Corallo wrote:
> >> Alan Third <alan <at> idiocy.org> writes:
> >> > emacs:
> >> > dlopen(/Users/alan/src/emacs/native/nextstep/Emacs.app/Contents/MacOS/../native-lisp/28.0.50-24e3df15/window-0d1b8b93-513ac8ca.eln,
> >> > 1): image not found
> >>
> >> Hi Alan,
> >>
> >> Okay the value of ELN_DESTDIR is used during dump to inform Emacs where
> >> the eln will be located (src/Makefile.in:570) so redumping is necessary.
> >> Have you tried redumping or rebuilding from scratch?
> >
> > Yes, I've tried 'make bootstrap' to no avail.
>
> could you share the output of like "make bootstrap V=1"? (go parallel if
> you like)
Attached.
--
Alan Third
[bootstrap.log.gz (application/x-gunzip, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Tue, 06 Apr 2021 19:27:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 47558 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Alan Third <alan <at> idiocy.org> writes:
> On Tue, Apr 06, 2021 at 02:51:46PM +0000, Andrea Corallo wrote:
>> Alan Third <alan <at> idiocy.org> writes:
>>
>> > On Tue, Apr 06, 2021 at 07:56:46AM +0000, Andrea Corallo wrote:
>> >> Alan Third <alan <at> idiocy.org> writes:
>> >> > emacs:
>> >> > dlopen(/Users/alan/src/emacs/native/nextstep/Emacs.app/Contents/MacOS/../native-lisp/28.0.50-24e3df15/window-0d1b8b93-513ac8ca.eln,
>> >> > 1): image not found
>> >>
>> >> Hi Alan,
>> >>
>> >> Okay the value of ELN_DESTDIR is used during dump to inform Emacs where
>> >> the eln will be located (src/Makefile.in:570) so redumping is necessary.
>> >> Have you tried redumping or rebuilding from scratch?
>> >
>> > Yes, I've tried 'make bootstrap' to no avail.
>>
>> could you share the output of like "make bootstrap V=1"? (go parallel if
>> you like)
>
> Attached.
Okay the log looks good AFAICT.
We are suggesting the eln to go in:
/Users/alan/src/emacs/native/nextstep/Emacs.app/Contents/MacOS/bin/
and the eln in:
/Users/alan/src/emacs/native/nextstep/Emacs.app/Contents/Resources/
For each compilation unit being dumped we modify the filename in a pair
in the form of (rel-filename-from-install-bin
. rel-filename-from-local-bin) in loadup.el:467 so we'll be able to
locate those compilation units when resurecting.
So either we compute wrongly the 'rel-filename-from-install-bin' there
or something goes wrong in pdumper.c:5277 (where we use it to to
identify if Emacs was installed or not).
On this subject I just realized that there we used concat in place of
`expand-file-name' and fixed that with 6568198213.
If this does not help I suggest we apply the attached and re-bootstrap
to see if the 'rel-filename-from-install-bin' we are constructing is
correct.
Thanks!
Andrea
[loadup.patch (text/x-diff, inline)]
diff --git a/lisp/loadup.el b/lisp/loadup.el
index 650288f9f8..3331445ff8 100644
--- a/lisp/loadup.el
+++ b/lisp/loadup.el
@@ -475,15 +475,17 @@
eln-dest-dir)))
(native-comp-unit-set-file
cu
- (cons
- ;; Relative filename from the installed binary.
- (file-relative-name (expand-file-name
- (file-name-nondirectory
- file)
- eln-dest-dir-eff)
- bin-dest-dir)
- ;; Relative filename from the built uninstalled binary.
- (file-relative-name file invocation-directory)))))
+ (let ((tmp (cons
+ ;; Relative filename from the installed binary.
+ (file-relative-name (expand-file-name
+ (file-name-nondirectory
+ file)
+ eln-dest-dir-eff)
+ bin-dest-dir)
+ ;; Relative filename from the built uninstalled binary.
+ (file-relative-name file invocation-directory))))
+ (print tmp)
+ tmp))))
h))))
(when (hash-table-p purify-flag)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Tue, 06 Apr 2021 21:13:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 47558 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Apr 06, 2021 at 07:26:16PM +0000, Andrea Corallo wrote:
>
> Okay the log looks good AFAICT.
>
> We are suggesting the eln to go in:
> /Users/alan/src/emacs/native/nextstep/Emacs.app/Contents/MacOS/bin/
>
> and the eln in:
> /Users/alan/src/emacs/native/nextstep/Emacs.app/Contents/Resources/
OK, I think I see what's going on. The binary is installed in
Emacs.app/Contents/MacOS, but the bindir is
Emacs.app/Contents/MacOS/bin, so we're going one level too far up when
generating the eln path.
"../../Resources/native-lisp/28.0.50-0f05d3d3/preloaded/misc-lang-7cb33d20-db3eb4ae.eln"
> If this does not help I suggest we apply the attached and re-bootstrap
> to see if the 'rel-filename-from-install-bin' we are constructing is
> correct.
I've attached the new bootstrap log in case I'm wrong and you can see
something else.
--
Alan Third
[bootstrap.log.gz (application/x-gunzip, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Tue, 06 Apr 2021 21:24:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 47558 <at> debbugs.gnu.org (full text, mbox):
Alan Third <alan <at> idiocy.org> writes:
> On Tue, Apr 06, 2021 at 07:26:16PM +0000, Andrea Corallo wrote:
>>
>> Okay the log looks good AFAICT.
>>
>> We are suggesting the eln to go in:
>> /Users/alan/src/emacs/native/nextstep/Emacs.app/Contents/MacOS/bin/
>>
>> and the eln in:
>> /Users/alan/src/emacs/native/nextstep/Emacs.app/Contents/Resources/
>
> OK, I think I see what's going on. The binary is installed in
> Emacs.app/Contents/MacOS, but the bindir is
> Emacs.app/Contents/MacOS/bin, so we're going one level too far up when
> generating the eln path.
>
> "../../Resources/native-lisp/28.0.50-0f05d3d3/preloaded/misc-lang-7cb33d20-db3eb4ae.eln"
>
>> If this does not help I suggest we apply the attached and re-bootstrap
>> to see if the 'rel-filename-from-install-bin' we are constructing is
>> correct.
>
> I've attached the new bootstrap log in case I'm wrong and you can see
> something else.
I think your analysis is correct.
ATM we form BIN_DESTDIR as '$(DESTDIR)${bindir}/' (Makefile.in:419),
maybe we should use 'ns_appbindir' to form it?
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Tue, 06 Apr 2021 21:34:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 47558 <at> debbugs.gnu.org (full text, mbox):
On Tue, Apr 06, 2021 at 09:22:57PM +0000, Andrea Corallo wrote:
> Alan Third <alan <at> idiocy.org> writes:
>
> > On Tue, Apr 06, 2021 at 07:26:16PM +0000, Andrea Corallo wrote:
> >>
> >> Okay the log looks good AFAICT.
> >>
> >> We are suggesting the eln to go in:
> >> /Users/alan/src/emacs/native/nextstep/Emacs.app/Contents/MacOS/bin/
> >>
> >> and the eln in:
> >> /Users/alan/src/emacs/native/nextstep/Emacs.app/Contents/Resources/
> >
> > OK, I think I see what's going on. The binary is installed in
> > Emacs.app/Contents/MacOS, but the bindir is
> > Emacs.app/Contents/MacOS/bin, so we're going one level too far up when
> > generating the eln path.
> >
> > "../../Resources/native-lisp/28.0.50-0f05d3d3/preloaded/misc-lang-7cb33d20-db3eb4ae.eln"
> >
> >> If this does not help I suggest we apply the attached and re-bootstrap
> >> to see if the 'rel-filename-from-install-bin' we are constructing is
> >> correct.
> >
> > I've attached the new bootstrap log in case I'm wrong and you can see
> > something else.
>
> I think your analysis is correct.
>
> ATM we form BIN_DESTDIR as '$(DESTDIR)${bindir}/' (Makefile.in:419),
> maybe we should use 'ns_appbindir' to form it?
Yup, that seems to have solved it. I'm doing this:
modified Makefile.in
@@ -420,8 +420,13 @@ lib lib-src lisp nt:
dirstate = .git/logs/HEAD
VCSWITNESS = $(if $(wildcard $(srcdir)/$(dirstate)),$$(srcdir)/../$(dirstate))
src: Makefile
+ifeq (${ns_self_contained},no)
$(MAKE) -C $@ VCSWITNESS='$(VCSWITNESS)' BIN_DESTDIR='$(DESTDIR)${bindir}/' \
ELN_DESTDIR='$(ELN_DESTDIR)' all
+else
+ $(MAKE) -C $@ VCSWITNESS='$(VCSWITNESS)' BIN_DESTDIR='${ns_appbindir}/' \
+ ELN_DESTDIR='$(ELN_DESTDIR)' all
+endif
blessmail: Makefile src
$(MAKE) -C lib-src maybe-blessmail
which works, but I don't know much about makefiles so there may be a
neater way to do it.
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Wed, 07 Apr 2021 02:18:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 47558 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I’m not familiar with the protocols here, so I apologize if this is just noise.
Modifying my Makefile.in (as Alan provided) bypasses the dlopen error originally reported.
Thank you all.
> On Apr 6, 2021, at 16:33, Alan Third <alan <at> idiocy.org> wrote:
>
> On Tue, Apr 06, 2021 at 09:22:57PM +0000, Andrea Corallo wrote:
>> Alan Third <alan <at> idiocy.org> writes:
>>
>>> On Tue, Apr 06, 2021 at 07:26:16PM +0000, Andrea Corallo wrote:
>>>>
>>>> Okay the log looks good AFAICT.
>>>>
>>>> We are suggesting the eln to go in:
>>>> /Users/alan/src/emacs/native/nextstep/Emacs.app/Contents/MacOS/bin/
>>>>
>>>> and the eln in:
>>>> /Users/alan/src/emacs/native/nextstep/Emacs.app/Contents/Resources/
>>>
>>> OK, I think I see what's going on. The binary is installed in
>>> Emacs.app/Contents/MacOS, but the bindir is
>>> Emacs.app/Contents/MacOS/bin, so we're going one level too far up when
>>> generating the eln path.
>>>
>>> "../../Resources/native-lisp/28.0.50-0f05d3d3/preloaded/misc-lang-7cb33d20-db3eb4ae.eln"
>>>
>>>> If this does not help I suggest we apply the attached and re-bootstrap
>>>> to see if the 'rel-filename-from-install-bin' we are constructing is
>>>> correct.
>>>
>>> I've attached the new bootstrap log in case I'm wrong and you can see
>>> something else.
>>
>> I think your analysis is correct.
>>
>> ATM we form BIN_DESTDIR as '$(DESTDIR)${bindir}/' (Makefile.in:419),
>> maybe we should use 'ns_appbindir' to form it?
>
> Yup, that seems to have solved it. I'm doing this:
>
> modified Makefile.in
> @@ -420,8 +420,13 @@ lib lib-src lisp nt:
> dirstate = .git/logs/HEAD
> VCSWITNESS = $(if $(wildcard $(srcdir)/$(dirstate)),$$(srcdir)/../$(dirstate))
> src: Makefile
> +ifeq (${ns_self_contained},no)
> $(MAKE) -C $@ VCSWITNESS='$(VCSWITNESS)' BIN_DESTDIR='$(DESTDIR)${bindir}/' \
> ELN_DESTDIR='$(ELN_DESTDIR)' all
> +else
> + $(MAKE) -C $@ VCSWITNESS='$(VCSWITNESS)' BIN_DESTDIR='${ns_appbindir}/' \
> + ELN_DESTDIR='$(ELN_DESTDIR)' all
> +endif
>
> blessmail: Makefile src
> $(MAKE) -C lib-src maybe-blessmail
>
>
> which works, but I don't know much about makefiles so there may be a
> neater way to do it.
>
> --
> Alan Third
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Wed, 07 Apr 2021 07:54:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 47558 <at> debbugs.gnu.org (full text, mbox):
Alan Third <alan <at> idiocy.org> writes:
> On Tue, Apr 06, 2021 at 09:22:57PM +0000, Andrea Corallo wrote:
>> Alan Third <alan <at> idiocy.org> writes:
>>
>> > On Tue, Apr 06, 2021 at 07:26:16PM +0000, Andrea Corallo wrote:
>> >>
>> >> Okay the log looks good AFAICT.
>> >>
>> >> We are suggesting the eln to go in:
>> >> /Users/alan/src/emacs/native/nextstep/Emacs.app/Contents/MacOS/bin/
>> >>
>> >> and the eln in:
>> >> /Users/alan/src/emacs/native/nextstep/Emacs.app/Contents/Resources/
>> >
>> > OK, I think I see what's going on. The binary is installed in
>> > Emacs.app/Contents/MacOS, but the bindir is
>> > Emacs.app/Contents/MacOS/bin, so we're going one level too far up when
>> > generating the eln path.
>> >
>> > "../../Resources/native-lisp/28.0.50-0f05d3d3/preloaded/misc-lang-7cb33d20-db3eb4ae.eln"
>> >
>> >> If this does not help I suggest we apply the attached and re-bootstrap
>> >> to see if the 'rel-filename-from-install-bin' we are constructing is
>> >> correct.
>> >
>> > I've attached the new bootstrap log in case I'm wrong and you can see
>> > something else.
>>
>> I think your analysis is correct.
>>
>> ATM we form BIN_DESTDIR as '$(DESTDIR)${bindir}/' (Makefile.in:419),
>> maybe we should use 'ns_appbindir' to form it?
>
> Yup, that seems to have solved it. I'm doing this:
Cool!
> modified Makefile.in
> @@ -420,8 +420,13 @@ lib lib-src lisp nt:
> dirstate = .git/logs/HEAD
> VCSWITNESS = $(if $(wildcard $(srcdir)/$(dirstate)),$$(srcdir)/../$(dirstate))
> src: Makefile
> +ifeq (${ns_self_contained},no)
> $(MAKE) -C $@ VCSWITNESS='$(VCSWITNESS)' BIN_DESTDIR='$(DESTDIR)${bindir}/' \
> ELN_DESTDIR='$(ELN_DESTDIR)' all
> +else
> + $(MAKE) -C $@ VCSWITNESS='$(VCSWITNESS)' BIN_DESTDIR='${ns_appbindir}/' \
> + ELN_DESTDIR='$(ELN_DESTDIR)' all
> +endif
>
> blessmail: Makefile src
> $(MAKE) -C lib-src maybe-blessmail
>
>
> which works, but I don't know much about makefiles so there may be a
> neater way to do it.
I think we could prepare BIN_DESTDIR near ELN_DESTDIR so we don't have
to duplicate the sub-make invocation in this target. I pushed
ce15b23846 that does that.
Please feel free to install a patch with all the other necessary changes
to have it working on MacOS.
Thanks!
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Wed, 07 Apr 2021 08:20:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 47558 <at> debbugs.gnu.org (full text, mbox):
On Wed, Apr 07, 2021 at 07:53:50AM +0000, Andrea Corallo wrote:
>
> I think we could prepare BIN_DESTDIR near ELN_DESTDIR so we don't have
> to duplicate the sub-make invocation in this target. I pushed
> ce15b23846 that does that.
Thanks!
> Please feel free to install a patch with all the other necessary changes
> to have it working on MacOS.
Done.
Bryan, can you give it a go again, please?
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Wed, 07 Apr 2021 09:09:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 47558 <at> debbugs.gnu.org (full text, mbox):
Alan Third <alan <at> idiocy.org> writes:
> On Wed, Apr 07, 2021 at 07:53:50AM +0000, Andrea Corallo wrote:
>>
>> I think we could prepare BIN_DESTDIR near ELN_DESTDIR so we don't have
>> to duplicate the sub-make invocation in this target. I pushed
>> ce15b23846 that does that.
>
> Thanks!
>
>> Please feel free to install a patch with all the other necessary changes
>> to have it working on MacOS.
>
> Done.
Wonderful thanks.
A curiosity looking at c35a515a2f:
+ LDFLAGS="$LDFLAGS -L${BREW_LIBGCCJIT_PREFIX}/lib/gcc/10 -I${BREW_LIBGCCJIT_PREFIX}/include"
^^^
Does this mean will have to touch configure.ac when brew will provide gcc11?
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Wed, 07 Apr 2021 09:59:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 47558 <at> debbugs.gnu.org (full text, mbox):
On Wed, Apr 07, 2021 at 09:08:36AM +0000, Andrea Corallo wrote:
> A curiosity looking at c35a515a2f:
>
> + LDFLAGS="$LDFLAGS -L${BREW_LIBGCCJIT_PREFIX}/lib/gcc/10 -I${BREW_LIBGCCJIT_PREFIX}/include"
> ^^^
>
> Does this mean will have to touch configure.ac when brew will provide gcc11?
I think so. I can't see any way to get this path information out of
the brew command. Perhaps we need to do some find magic to get the
actual directory...?
This appears to work, but I don't see anything else like it in
configure.ac, so it's maybe not a good idea:
brew_libdir=`dirname ${BREW_LIBGCCJIT_PREFIX}/lib/gcc/*/libgccjit.so`
LDFLAGS="$LDFLAGS -L${brew_libdir} -I${BREW_LIBGCCJIT_PREFIX}/include"
The alternative is just to leave people to set up these flags
themselves, but I'd rather not if we can avoid it.
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Wed, 07 Apr 2021 10:33:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 47558 <at> debbugs.gnu.org (full text, mbox):
On Apr 07 2021, Alan Third wrote:
> On Wed, Apr 07, 2021 at 09:08:36AM +0000, Andrea Corallo wrote:
>> A curiosity looking at c35a515a2f:
>>
>> + LDFLAGS="$LDFLAGS -L${BREW_LIBGCCJIT_PREFIX}/lib/gcc/10 -I${BREW_LIBGCCJIT_PREFIX}/include"
>> ^^^
>>
>> Does this mean will have to touch configure.ac when brew will provide gcc11?
>
> I think so. I can't see any way to get this path information out of
> the brew command. Perhaps we need to do some find magic to get the
> actual directory...?
gcc -print-file-name=libgccjit.so
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Wed, 07 Apr 2021 10:36:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 47558 <at> debbugs.gnu.org (full text, mbox):
On Apr 07 2021, Alan Third wrote:
> This appears to work, but I don't see anything else like it in
> configure.ac, so it's maybe not a good idea:
>
> brew_libdir=`dirname ${BREW_LIBGCCJIT_PREFIX}/lib/gcc/*/libgccjit.so`
> LDFLAGS="$LDFLAGS -L${brew_libdir} -I${BREW_LIBGCCJIT_PREFIX}/include"
>
> The alternative is just to leave people to set up these flags
> themselves, but I'd rather not if we can avoid it.
Why do you need that in the first place? The compiler should be looking
there by default.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Wed, 07 Apr 2021 10:49:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 47558 <at> debbugs.gnu.org (full text, mbox):
On Wed, Apr 07, 2021 at 12:35:10PM +0200, Andreas Schwab wrote:
> On Apr 07 2021, Alan Third wrote:
>
> > This appears to work, but I don't see anything else like it in
> > configure.ac, so it's maybe not a good idea:
> >
> > brew_libdir=`dirname ${BREW_LIBGCCJIT_PREFIX}/lib/gcc/*/libgccjit.so`
> > LDFLAGS="$LDFLAGS -L${brew_libdir} -I${BREW_LIBGCCJIT_PREFIX}/include"
> >
> > The alternative is just to leave people to set up these flags
> > themselves, but I'd rather not if we can avoid it.
>
> Why do you need that in the first place? The compiler should be looking
> there by default.
It may be because we have to build with clang, or it may be because of
how homebrew installs things. Or both. I'm not sure.
breton:/Users/alan>gcc -print-file-name=libgccjit.so
libgccjit.so
which isn't helpful, but again may be because gcc is actually clang.
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Wed, 07 Apr 2021 11:47:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 47558 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 7 Apr 2021 10:58:09 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, bryan.m.obrien <at> gmail.com,
> 47558 <at> debbugs.gnu.org
>
> This appears to work, but I don't see anything else like it in
> configure.ac, so it's maybe not a good idea:
>
> brew_libdir=`dirname ${BREW_LIBGCCJIT_PREFIX}/lib/gcc/*/libgccjit.so`
> LDFLAGS="$LDFLAGS -L${brew_libdir} -I${BREW_LIBGCCJIT_PREFIX}/include"
This is indeed non-portable, but using 'find' pipes into a suitable
Sed script should be able to do that portably.
It is indeed suboptimal to have the compiler version in these file
names, so I'd prefer to solve it in a cleaner way.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Wed, 07 Apr 2021 11:51:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 47558 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 7 Apr 2021 11:48:23 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: Andrea Corallo <akrl <at> sdf.org>, Eli Zaretskii <eliz <at> gnu.org>,
> bryan.m.obrien <at> gmail.com, 47558 <at> debbugs.gnu.org
>
> > Why do you need that in the first place? The compiler should be looking
> > there by default.
>
> It may be because we have to build with clang, or it may be because of
> how homebrew installs things. Or both. I'm not sure.
That alone is worth a bug report against clang, I think.
> breton:/Users/alan>gcc -print-file-name=libgccjit.so
> libgccjit.so
>
> which isn't helpful, but again may be because gcc is actually clang.
The above means the compiler cannot find the file. Does the file's
name actually end in .so, or is it some .dynlib or some such?
Does clang support the -v switch, whereby it emits details about the
directories it searches and libraries it scans? If so, can you run
the link command with that switch and show the entire output?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Wed, 07 Apr 2021 12:16:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 47558 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 07 Apr 2021 14:50:03 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: bryan.m.obrien <at> gmail.com, akrl <at> sdf.org, schwab <at> linux-m68k.org,
> 47558 <at> debbugs.gnu.org
>
> Does clang support the -v switch, whereby it emits details about the
> directories it searches and libraries it scans? If so, can you run
> the link command with that switch and show the entire output?
You could also try
gcc -print-search-dirs
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Wed, 07 Apr 2021 12:33:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 47558 <at> debbugs.gnu.org (full text, mbox):
On Wed, Apr 07, 2021 at 02:50:03PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 7 Apr 2021 11:48:23 +0100
> > From: Alan Third <alan <at> idiocy.org>
> > Cc: Andrea Corallo <akrl <at> sdf.org>, Eli Zaretskii <eliz <at> gnu.org>,
> > bryan.m.obrien <at> gmail.com, 47558 <at> debbugs.gnu.org
> >
> > > Why do you need that in the first place? The compiler should be looking
> > > there by default.
> >
> > It may be because we have to build with clang, or it may be because of
> > how homebrew installs things. Or both. I'm not sure.
>
> That alone is worth a bug report against clang, I think.
I think it's more likely to be Homebrew that's at fault, and I think
they view this kind of thing as a feature rather than a bug. I believe
the idea is for homebrew to interfere with the system as little as
possible.
Neither clang, nor (homebrew installed) gcc can find the libraries on
their own.
gcc:
breton:/Users/alan>gcc-10 -v -print-file-name=libgccjit.so
Using built-in specs.
COLLECT_GCC=gcc-10
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/10.2.0_4/libexec/gcc/x86_64-apple-darwin18/10.2.0/lto-wrapper
libgccjit.so
clang:
breton:/Users/alan>clang -v -print-file-name=libgccjit.so
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
libgccjit.so
> > breton:/Users/alan>gcc -print-file-name=libgccjit.so
> > libgccjit.so
> >
> > which isn't helpful, but again may be because gcc is actually clang.
>
> The above means the compiler cannot find the file. Does the file's
> name actually end in .so, or is it some .dynlib or some such?
Definitely .so:
breton:/Users/alan>ls `brew --prefix libgccjit`/lib/gcc/10/
libgccjit.so libgccjit.so.0 libgccjit.so.0.0.1
> Does clang support the -v switch, whereby it emits details about the
> directories it searches and libraries it scans? If so, can you run
> the link command with that switch and show the entire output?
Shown above, but there's also
breton:/Users/alan>clang -print-search-dirs
programs: =/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
libraries:
=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0
This is relatively common with Homebrew. If you look in configure.ac
there are a few places where we have to modify PKG_CONFIG_PATH because
homebrew doesn't link in all the libraries it installs.
I'm also unsure how portable we need to be with this code since
homebrew is macOS specific and to my knowledge this problem only
arises with homebrew.
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Wed, 07 Apr 2021 14:21:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 47558 <at> debbugs.gnu.org (full text, mbox):
On Wed, Apr 07, 2021 at 02:45:59PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 7 Apr 2021 10:58:09 +0100
> > From: Alan Third <alan <at> idiocy.org>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, bryan.m.obrien <at> gmail.com,
> > 47558 <at> debbugs.gnu.org
> >
> > This appears to work, but I don't see anything else like it in
> > configure.ac, so it's maybe not a good idea:
> >
> > brew_libdir=`dirname ${BREW_LIBGCCJIT_PREFIX}/lib/gcc/*/libgccjit.so`
> > LDFLAGS="$LDFLAGS -L${brew_libdir} -I${BREW_LIBGCCJIT_PREFIX}/include"
>
> This is indeed non-portable, but using 'find' pipes into a suitable
> Sed script should be able to do that portably.
Is this better?
if test -n "$BREW"; then
BREW_LIBGCCJIT_PREFIX=`$BREW --prefix --installed libgccjit 2>/dev/null`
if test "$BREW_LIBGCCJIT_PREFIX"; then
brew_libdir=`find ${BREW_LIBGCCJIT_PREFIX}/ -name \*.so \
| sed -e '1!d;s|/[[^/]]*\.so$||'`
CFLAGS="$CFLAGS -I${BREW_LIBGCCJIT_PREFIX}/include"
LDFLAGS="$LDFLAGS -L${brew_libdir} -I${BREW_LIBGCCJIT_PREFIX}/include"
fi
fi
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Wed, 07 Apr 2021 14:27:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 47558 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 7 Apr 2021 15:20:25 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: akrl <at> sdf.org, bryan.m.obrien <at> gmail.com, 47558 <at> debbugs.gnu.org
>
> > This is indeed non-portable, but using 'find' pipes into a suitable
> > Sed script should be able to do that portably.
>
> Is this better?
>
> if test -n "$BREW"; then
> BREW_LIBGCCJIT_PREFIX=`$BREW --prefix --installed libgccjit 2>/dev/null`
> if test "$BREW_LIBGCCJIT_PREFIX"; then
> brew_libdir=`find ${BREW_LIBGCCJIT_PREFIX}/ -name \*.so \
> | sed -e '1!d;s|/[[^/]]*\.so$||'`
> CFLAGS="$CFLAGS -I${BREW_LIBGCCJIT_PREFIX}/include"
> LDFLAGS="$LDFLAGS -L${brew_libdir} -I${BREW_LIBGCCJIT_PREFIX}/include"
> fi
> fi
Yes, I think so.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Wed, 07 Apr 2021 16:47:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 47558 <at> debbugs.gnu.org (full text, mbox):
> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, bryan.m.obrien <at> gmail.com,
> 47558 <at> debbugs.gnu.org
> Date: Tue, 06 Apr 2021 19:26:16 +0000
>
> On this subject I just realized that there we used concat in place of
> `expand-file-name' and fixed that with 6568198213.
I needed to revert that part, because we cannot call expand-file-name
so early into startup, at least not on MS-Windows. Was there some
real problem you saw that was caused by using concat2 there?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Wed, 07 Apr 2021 18:31:01 GMT)
Full text and
rfc822 format available.
Message #110 received at 47558 <at> debbugs.gnu.org (full text, mbox):
Error is resolved with latest branch.
This is the build shell I used:
# native-comp optimization
export CFLAGS="-I$(brew --prefix libgccjit)/include"
export LDFLAGS="-L$(brew --prefix libgccjit)/lib/gcc/10"
export CC="clang"
cd gccemacs || exit
git clean -xfd
./autogen.sh
./configure --with-native-compilation --with-x-widgets
make NATIVE_FULL_AOT=1 -j 16
make -j 16 install
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, bryan.m.obrien <at> gmail.com,
>> 47558 <at> debbugs.gnu.org
>> Date: Tue, 06 Apr 2021 19:26:16 +0000
>>
>> On this subject I just realized that there we used concat in place of
>> `expand-file-name' and fixed that with 6568198213.
>
> I needed to revert that part, because we cannot call expand-file-name
> so early into startup, at least not on MS-Windows. Was there some
> real problem you saw that was caused by using concat2 there?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Wed, 07 Apr 2021 18:42:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 47558 <at> debbugs.gnu.org (full text, mbox):
I replied incorrectly, sorry about that.
Latest build on most recent git branch was successful.
Alan Third <alan <at> idiocy.org> writes:
> On Wed, Apr 07, 2021 at 07:53:50AM +0000, Andrea Corallo wrote:
>>
>> I think we could prepare BIN_DESTDIR near ELN_DESTDIR so we don't have
>> to duplicate the sub-make invocation in this target. I pushed
>> ce15b23846 that does that.
>
> Thanks!
>
>> Please feel free to install a patch with all the other necessary changes
>> to have it working on MacOS.
>
> Done.
>
> Bryan, can you give it a go again, please?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#47558; Package
emacs.
(Wed, 07 Apr 2021 18:45:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 47558 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, bryan.m.obrien <at> gmail.com,
>> 47558 <at> debbugs.gnu.org
>> Date: Tue, 06 Apr 2021 19:26:16 +0000
>>
>> On this subject I just realized that there we used concat in place of
>> `expand-file-name' and fixed that with 6568198213.
>
> I needed to revert that part, because we cannot call expand-file-name
> so early into startup, at least not on MS-Windows.
Sorry thanks for that.
> Was there some real problem you saw that was caused by using concat2
> there?
No, I've just spotted the code and once here was working I changed it.
I was going to add a comment but I see it's already done, thanks!
Andrea
Reply sent
to
Andrea Corallo <akrl <at> sdf.org>:
You have taken responsibility.
(Wed, 07 Apr 2021 18:46:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Bryan O'Brien <bryan.m.obrien <at> gmail.com>:
bug acknowledged by developer.
(Wed, 07 Apr 2021 18:46:02 GMT)
Full text and
rfc822 format available.
Message #121 received at 47558-done <at> debbugs.gnu.org (full text, mbox):
"Bryan O'Brien" <bryan.m.obrien <at> gmail.com> writes:
> I replied incorrectly, sorry about that.
>
> Latest build on most recent git branch was successful.
Very nice! I'm closing then.
Thanks all
Andrea
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 06 May 2021 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 64 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.