bug#45817: 28.0.50; Native fails

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#45817: 28.0.50; Native fails

Emacs - Bugs mailing list
Good day,

I've just upgraded emacs to last version of devel snapshot from emacs
ports with native support with local git root
8ad983c4acef60a80e8d6b6ba891b1ef957f2d7c and discovered that it can't
start nor my local config, nor emacs-doom. I haven't yet tried spacemacs
but expected that it will be the same issue.

For example with doom-emacs local git root
fc184852d0236769c971e94ec5ec220d8cd24fd1 I have error:

x There was an unexpected error
  Message: Native compiler error
  Data: (native-compiler-error lambda (arg5 &rest arg6) (let ((f #'message)) (apply f arg5 arg6)))
  Backtrace:
    (signal native-compiler-error ((lambda (arg5 &rest arg6) (let ((f #'messag
    (comp--native-compile (lambda (arg5 &rest arg6) (let ((f #'message)) (appl
    (comp-trampoline-compile message)
    (comp-subr-trampoline-install message)
    (fset message (closure ((message . #<subr message>) (log-buffer . #<buffer
    (progn (fset #'message vnew) (ignore message) (unwind-protect (catch 'exit
    (unwind-protect (progn (fset #'message vnew) (ignore message) (unwind-prot
    (let* ((vnew #'(lambda (msg &rest args) (save-current-buffer (set-buffer l
    (let ((message (symbol-function #'message))) (let* ((vnew #'(lambda (msg &
    (let* ((log-buffer (generate-new-buffer " *doom log*")) (standard-output #


you can easy achive it by run bin/doom sync



In GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin20.1.0, NS appkit-2022.10 Version 11.0.1 (Build 20B29))
of 2021-01-06 built on bigsurx.internal.macports.net
Repository revision: 80e26472206cc44837521ba594cd50e724d9af5c
Repository branch: HEAD
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.1

Configured using:
'configure --prefix=/opt/local --disable-silent-rules --without-dbus
--without-gconf --without-libotf --without-m17n-flt --with-gmp
--with-gnutls --with-json --with-xml2 --with-modules --infodir
/opt/local/share/info/emacs --with-ns --with-lcms2 --without-harfbuzz
--without-imagemagick --without-xaw3d --with-rsvg 'CFLAGS=-pipe -Os
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk -arch
x86_64' 'CPPFLAGS=-I/opt/local/include
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk'
'LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-no_pie
-Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk
-arch x86_64''

Configured features:
JPEG TIFF GIF PNG RSVG GLIB NOTIFY KQUEUE ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS XIM NS MODULES THREADS JSON PDUMPER LCMS2

Important settings:
  value of $LANG: en_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml easymenu mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core eieio-loaddefs
password-cache json map text-property-search time-date mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
warnings core core-lib pcase cl-macs cl-loaddefs cl-lib subr-x chemacs
seq byte-opt gv bytecomp byte-compile cconv 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 timer select scroll-bar mouse jit-lock font-lock
syntax facemenu 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 kqueue
cocoa ns lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 56202 65901)
(symbols 48 6980 30)
(strings 32 18794 8672)
(string-bytes 1 631184)
(vectors 16 11754)
(vector-slots 8 172409 91859)
(floats 8 28 310)
(intervals 56 235 64)
(buffers 984 12))


-- 
wbr, Kirill


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#45817: Acknowledgement (28.0.50; Native fails)

Emacs - Bugs mailing list
I found a bit more logs:

ld: library not found for -lSystem
collect2: error: ld returned 1 exit status
libgccjit.so: error: error invoking gcc driver



For example an issue that looks very similar with this one at Haskell: https://gitlab.haskell.org/ghc/ghc/-/issues/18446


-- 
wbr, Kirill

On 12. Jan 2021, at 16:20, GNU bug Tracking System <[hidden email]> wrote:

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
[hidden email]

If you wish to submit further information on this problem, please
send it to [hidden email].

Please do not send mail to [hidden email] unless you wish
to report a problem with the Bug-tracking system.

--
45817: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=45817
GNU Bug Tracking System
Contact [hidden email] with problems


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#45817: Acknowledgement (28.0.50; Native fails)

Emacs - Bugs mailing list
"Kirill A. Korinsky" via "Bug reports for GNU Emacs, the Swiss army
knife of text editors" <[hidden email]> writes:

> I found a bit more logs:
>
> ld: library not found for -lSystem
> collect2: error: ld returned 1 exit status
> libgccjit.so: error: error invoking gcc driver
>
> Looks like the right fix is something like this:
> https://opensource.apple.com/source/dyld/dyld-97.1/include/mach-o/dyld-interposing.h.auto.html
>
> For example an issue that looks very similar with this one at Haskell: https://gitlab.haskell.org/ghc/ghc/-/issues/18446

Hi Kirill,

this looks like a system miss configuration.

By the way I don't recall anything changed in this respect so if it
worked in the past I guess something changed on your sys configuration.

Perhaps you've upgraded your OS?

Do you knwon where (and if) this library is on your system?

  Andrea



Reply | Threaded
Open this post in threaded view
|

bug#45817: Acknowledgement (28.0.50; Native fails)

Emacs - Bugs mailing list
Hey,

The right path is /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib

How can I add -L option to spcify path? :)

-- 
wbr, Kirill

On 12. Jan 2021, at 19:44, Andrea Corallo <[hidden email]> wrote:

"Kirill A. Korinsky" via "Bug reports for GNU Emacs, the Swiss army
knife of text editors" <[hidden email]> writes:

I found a bit more logs:

ld: library not found for -lSystem
collect2: error: ld returned 1 exit status
libgccjit.so: error: error invoking gcc driver

Looks like the right fix is something like this:
https://opensource.apple.com/source/dyld/dyld-97.1/include/mach-o/dyld-interposing.h.auto.html

For example an issue that looks very similar with this one at Haskell: https://gitlab.haskell.org/ghc/ghc/-/issues/18446

Hi Kirill,

this looks like a system miss configuration.

By the way I don't recall anything changed in this respect so if it
worked in the past I guess something changed on your sys configuration.

Perhaps you've upgraded your OS?

Do you knwon where (and if) this library is on your system?

 Andrea


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#45817: 28.0.50; Native fails

Emacs - Bugs mailing list
In reply to this post by Emacs - Bugs mailing list
Here it is:

~ % emacs -batch -eval "(comp-subr-trampoline-install #'message)"
Debugger entered--Lisp error: (native-compiler-error (lambda (arg0 &rest arg1) (let ((f #'message)) (apply f arg0 arg1))) "Compiling /Users/catap/.emacs.d/eln-cache/28.0.50-...")
  signal(native-compiler-error ((lambda (arg0 &rest arg1) (let ((f #'message)) (apply f arg0 arg1))) "Compiling /Users/catap/.emacs.d/eln-cache/28.0.50-..."))
  comp--native-compile((lambda (arg0 &rest arg1) (let ((f #'message)) (apply f arg0 arg1))) nil "/Users/catap/.emacs.d/eln-cache/28.0.50-x86_64-app...")
  comp-trampoline-compile(message)
  comp-subr-trampoline-install(message)
  command-line-1(("-eval" "(comp-subr-trampoline-install #'message)"))
  command-line()
  normal-top-level()

? ~

The last ? means that exit code wasn't zero

-- 
wbr, Kirill

On 12. Jan 2021, at 20:38, Andrea Corallo <[hidden email]> wrote:

"Kirill A. Korinsky" via "Bug reports for GNU Emacs, the Swiss army
knife of text editors" <[hidden email]> writes:

Good day,

I've just upgraded emacs to last version of devel snapshot from emacs
ports with native support with local git root
8ad983c4acef60a80e8d6b6ba891b1ef957f2d7c and discovered that it can't
start nor my local config, nor emacs-doom. I haven't yet tried spacemacs
but expected that it will be the same issue.

Hi Kirill,

the latest feature/native-comp is 42ff68ec2f.

Anyway I think to understand what's going on we need some minimal
reproducer.  Could you try running the followig and report the output
(if any)?

emacs -batch -eval "(comp-subr-trampoline-install #'message)"

Thanks!

 Andrea


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#45817: Acknowledgement (28.0.50; Native fails)

Emacs - Bugs mailing list
In reply to this post by Emacs - Bugs mailing list
"Kirill A. Korinsky" <[hidden email]> writes:

> Hey,
>
> The right path is /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
>
> How can I add -L option to spcify path? :)

I think the easiest should be setting your LIBRARY_PATH

<https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html#Environment-Variables>

Alternatively we have also  `comp-native-driver-options' from inside
Emacs, but I think the first is the better fix.

  Andrea



Reply | Threaded
Open this post in threaded view
|

bug#45817: 28.0.50; Native fails

Emacs - Bugs mailing list
In reply to this post by Emacs - Bugs mailing list
Both LD_LIBRARY_PATH and DYLD_LIBRARY_PATH doesn't help.

But if I put into early-init.el:

(setq comp-native-driver-options '(
      (concat
       "-L"
       (substring (shell-command-to-string "xcode-select -p") 0 -1)
       "/SDKs/MacOSX.sdk/usr/lib")))

The error has changed to:

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p "Abort trap: 6")
  comp-final(nil)
  #f(compiled-function (pass) #<bytecode 0xb1e0d621e6fccdf>)(comp-final)
  mapc(#f(compiled-function (pass) #<bytecode 0xb1e0d621e6fccdf>) (comp-spill-lap comp-limplify comp-fwprop comp-call-optim comp-ipa-pure comp-add-cstrs comp-fwprop comp-dead-code comp-tco comp-fwprop comp-remove-type-hints comp-final))
  comp--native-compile((lambda (arg0 &optional) (let ((f #'yes-or-no-p)) (funcall f arg0))) nil "/Users/catap/src/doom-emacs/.local/cache/eln/28.0.50-x86_64-apple-darwin20.2.0-fd47d85b89f8ef6ced8660b41eff701c/subr--trampoline-7965732d6f722d6e6f2d70_yes_or_no_p_0.eln")
  comp-trampoline-compile(yes-or-no-p)
  comp-subr-trampoline-install(yes-or-no-p)


-- 
wbr, Kirill

On 12. Jan 2021, at 21:25, Andrea Corallo <[hidden email]> wrote:

"Kirill A. Korinsky" <[hidden email]> writes:

Here it is:

√ ~ % emacs -batch -eval "(comp-subr-trampoline-install #'message)"
Debugger entered--Lisp error: (native-compiler-error (lambda (arg0 &rest arg1) (let ((f #'message)) (apply f arg0 arg1)))
"Compiling /Users/catap/.emacs.d/eln-cache/28.0.50-...")
 signal(native-compiler-error ((lambda (arg0 &rest arg1) (let ((f #'message)) (apply f arg0 arg1))) "Compiling
/Users/catap/.emacs.d/eln-cache/28.0.50-..."))
 comp--native-compile((lambda (arg0 &rest arg1) (let ((f #'message)) (apply f arg0 arg1))) nil
"/Users/catap/.emacs.d/eln-cache/28.0.50-x86_64-app...")
 comp-trampoline-compile(message)
 comp-subr-trampoline-install(message)
 command-line-1(("-eval" "(comp-subr-trampoline-install #'message)"))
 command-line()
 normal-top-level()

? ~ % 

The last ? means that exit code wasn't zero

Yeah sorry, I've lost track of all messages I'm replying and thought
were two separate bugs, I think the right counter measure to this issue
is in my last message on this thread (LIBRARY_PATH).

 Andrea


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#45817: 28.0.50; Native fails

Emacs - Bugs mailing list
I'd like to confirm that it isn't a emacs bug.

After reinstall from sources gcc10 an issue disappeared.

Link to mackport related issue: https://trac.macports.org/ticket/61896

-- 
wbr, Kiril


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#45817: 28.0.50; Native fails

Eli Zaretskii
> Date: Thu, 14 Jan 2021 03:19:15 +0100
> Cc: [hidden email]
> From: "Kirill A. Korinsky" via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <[hidden email]>
>
> I'd like to confirm that it isn't a emacs bug.
>
> After reinstall from sources gcc10 an issue disappeared.
>
> Link to mackport related issue: https://trac.macports.org/ticket/61896

Is this specific to macOS?

In any case, if it's known that specific versions of GCC cause
problems on specific platforms, we should reject those versions (for
the libgccjit usage purposes) in configure, I think.



Reply | Threaded
Open this post in threaded view
|

bug#45817: 28.0.50; Native fails

Emacs - Bugs mailing list
Eli Zaretskii <[hidden email]> writes:

>> Date: Thu, 14 Jan 2021 03:19:15 +0100
>> Cc: [hidden email]
>> From: "Kirill A. Korinsky" via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <[hidden email]>
>>
>> I'd like to confirm that it isn't a emacs bug.
>>
>> After reinstall from sources gcc10 an issue disappeared.
>>
>> Link to mackport related issue: https://trac.macports.org/ticket/61896
>
> Is this specific to macOS?
>
> In any case, if it's known that specific versions of GCC cause
> problems on specific platforms, we should reject those versions (for
> the libgccjit usage purposes) in configure, I think.

We do, not based on the version but (even better I think) we run a
functional test at configure time.  The test use libgccjit to produce a
shared, then this is loaded and used to ensure all the complete
mechanism is functional.

I think in this specific case somenthing happend (maybe OS upgrade?) as
when Emacs was compiled libgccjit clearly was working.

  Andrea



Reply | Threaded
Open this post in threaded view
|

bug#45817: 28.0.50; Native fails

Emacs - Bugs mailing list
In reply to this post by Emacs - Bugs mailing list
"Kirill A. Korinsky" <[hidden email]> writes:

> I'd like to confirm that it isn't a emacs bug.

Nice, thanks for the update, closing this.

  Andrea




Reply | Threaded
Open this post in threaded view
|

bug#45817: 28.0.50; Native fails

Emacs - Bugs mailing list
In reply to this post by Eli Zaretskii
Yes, it is specified to macOS.

I belive that it is specified to update of xcode that was somewhere at the end of December.

-- 
wbr, Kirill

On 14. Jan 2021, at 04:32, Eli Zaretskii <[hidden email]> wrote:

Date: Thu, 14 Jan 2021 03:19:15 +0100
Cc: [hidden email]
From: "Kirill A. Korinsky" via "Bug reports for GNU Emacs,
the Swiss army knife of text editors" <[hidden email]>

I'd like to confirm that it isn't a emacs bug.

After reinstall from sources gcc10 an issue disappeared.

Link to mackport related issue: https://trac.macports.org/ticket/61896

Is this specific to macOS?

In any case, if it's known that specific versions of GCC cause
problems on specific platforms, we should reject those versions (for
the libgccjit usage purposes) in configure, I think.


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#45817: 28.0.50; Native fails

Eli Zaretskii
In reply to this post by Emacs - Bugs mailing list
> From: Andrea Corallo <[hidden email]>
> Cc: "Kirill A. Korinsky" <[hidden email]>, [hidden email]
> Date: Thu, 14 Jan 2021 09:33:48 +0000
>
> > Is this specific to macOS?
> >
> > In any case, if it's known that specific versions of GCC cause
> > problems on specific platforms, we should reject those versions (for
> > the libgccjit usage purposes) in configure, I think.
>
> We do, not based on the version but (even better I think) we run a
> functional test at configure time.  The test use libgccjit to produce a
> shared, then this is loaded and used to ensure all the complete
> mechanism is functional.

Yes, but such tests can only verify that the basics work, whereas the
OP seemed to indicate that it generally works, but fails in some
subtle situation.  If libgccjit you are testing at configure time only
"mostly" works, you will be unable to detect that with simple tests.
For such subtly broken versions of libgccjit, we have no practical
means but looking at their version.

> I think in this specific case somenthing happend (maybe OS upgrade?) as
> when Emacs was compiled libgccjit clearly was working.

If that is the case, then there's no problem we need to solve here.



Reply | Threaded
Open this post in threaded view
|

bug#45817: 28.0.50; Native fails

Emacs - Bugs mailing list
Eli Zaretskii <[hidden email]> writes:

>> From: Andrea Corallo <[hidden email]>
>> Cc: "Kirill A. Korinsky" <[hidden email]>, [hidden email]
>> Date: Thu, 14 Jan 2021 09:33:48 +0000
>>
>> > Is this specific to macOS?
>> >
>> > In any case, if it's known that specific versions of GCC cause
>> > problems on specific platforms, we should reject those versions (for
>> > the libgccjit usage purposes) in configure, I think.
>>
>> We do, not based on the version but (even better I think) we run a
>> functional test at configure time.  The test use libgccjit to produce a
>> shared, then this is loaded and used to ensure all the complete
>> mechanism is functional.
>
> Yes, but such tests can only verify that the basics work, whereas the
> OP seemed to indicate that it generally works, but fails in some
> subtle situation.  If libgccjit you are testing at configure time only
> "mostly" works, you will be unable to detect that with simple tests.
> For such subtly broken versions of libgccjit, we have no practical
> means but looking at their version.

I agree, but so far I've no information of a broken libgccjit version
that we don't manage to work around.  I'm talking about if compiled and
installed from source code.  Some distros showed to have issues with
certain packaged versions, but those fails immediately with the
configure test we have.

If we find a libgccjit version we know we can't work with I agree we
should reject the version.

For this specific purpose I've introduced (in GCC10) an entry point in
libgccjit that is returning the version.

This is exposed to Lisp as `comp-libgccjit-version' so for GCC>=10 we
can control this also dynamically and not only at configure time.

  Andrea