GNU bug report logs - #45817
28.0.50; Native fails

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 45817 in the body.
You can then email your comments to 45817 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Kirill A. Korinsky" <kirill <at> korins.ky>
To: "Kirill A. Korinsky via Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Subject: 28.0.50; Native fails
Date: Tue, 12 Jan 2021 16:04:29 +0100

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

[signature.asc (application/pgp-signature, attachment)]

Message #8 received at 45817 <at> debbugs.gnu.org (full text, mbox):

From: "Kirill A. Korinsky" <kirill <at> korins.ky>
To: 45817 <at> debbugs.gnu.org
Subject: Re: bug#45817: Acknowledgement (28.0.50; Native fails)
Date: Tue, 12 Jan 2021 19:10:41 +0100

[Message part 1 (text/plain, inline)]

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 <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 <https://gitlab.haskell.org/ghc/ghc/-/issues/18446>


--
wbr, Kirill

> On 12. Jan 2021, at 16:20, GNU bug Tracking System <help-debbugs <at> gnu.org> 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):
> bug-gnu-emacs <at> gnu.org
> 
> If you wish to submit further information on this problem, please
> send it to 45817 <at> debbugs.gnu.org.
> 
> Please do not send mail to help-debbugs <at> gnu.org 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 help-debbugs <at> gnu.org with problems

[Message part 2 (text/html, inline)]

[signature.asc (application/pgp-signature, attachment)]

Message #11 received at 45817 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: "Kirill A. Korinsky" via "Bug reports for GNU Emacs, the Swiss army
 knife of text editors" <bug-gnu-emacs <at> gnu.org>
Cc: 45817 <at> debbugs.gnu.org, "Kirill A. Korinsky" <kirill <at> korins.ky>
Subject: Re: bug#45817: Acknowledgement (28.0.50; Native fails)
Date: Tue, 12 Jan 2021 18:44:45 +0000

"Kirill A. Korinsky" via "Bug reports for GNU Emacs, the Swiss army
knife of text editors" <bug-gnu-emacs <at> gnu.org> 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

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: "Kirill A. Korinsky" via "Bug reports for GNU Emacs, the Swiss army
 knife of text editors" <bug-gnu-emacs <at> gnu.org>
Cc: 45817 <at> debbugs.gnu.org, "Kirill A. Korinsky" <kirill <at> korins.ky>
Subject: Re: bug#45817: 28.0.50; Native fails
Date: Tue, 12 Jan 2021 19:38:38 +0000

"Kirill A. Korinsky" via "Bug reports for GNU Emacs, the Swiss army
knife of text editors" <bug-gnu-emacs <at> gnu.org> 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

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: "Kirill A. Korinsky" <kirill <at> korins.ky>
Cc: 45817 <at> debbugs.gnu.org, "Kirill A. Korinsky via Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
Subject: Re: bug#45817: Acknowledgement (28.0.50; Native fails)
Date: Tue, 12 Jan 2021 20:09:07 +0000

"Kirill A. Korinsky" <kirill <at> korins.ky> 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

Message #29 received at 45817 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: "Kirill A. Korinsky" <kirill <at> korins.ky>
Cc: 45817 <at> debbugs.gnu.org, "Kirill A. Korinsky via Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
Subject: Re: bug#45817: 28.0.50; Native fails
Date: Tue, 12 Jan 2021 20:25:39 +0000

"Kirill A. Korinsky" <kirill <at> korins.ky> 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

Message #35 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Kirill A. Korinsky" <kirill <at> korins.ky>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: 45817 <at> debbugs.gnu.org, "Kirill A. Korinsky via Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
Subject: Re: bug#45817: Acknowledgement (28.0.50; Native fails)
Date: Tue, 12 Jan 2021 20:35:51 +0100

[Message part 1 (text/plain, inline)]

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 <akrl <at> sdf.org> wrote:
> 
> "Kirill A. Korinsky" via "Bug reports for GNU Emacs, the Swiss army
> knife of text editors" <bug-gnu-emacs <at> gnu.org> 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

[Message part 2 (text/html, inline)]

[signature.asc (application/pgp-signature, attachment)]

Message #38 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Kirill A. Korinsky" <kirill <at> korins.ky>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: 45817 <at> debbugs.gnu.org, "Kirill A. Korinsky via Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
Subject: Re: bug#45817: 28.0.50; Native fails
Date: Tue, 12 Jan 2021 21:05:10 +0100

[Message part 1 (text/plain, inline)]

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 <akrl <at> sdf.org> wrote:
> 
> "Kirill A. Korinsky" via "Bug reports for GNU Emacs, the Swiss army
> knife of text editors" <bug-gnu-emacs <at> gnu.org> 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

[Message part 2 (text/html, inline)]

[signature.asc (application/pgp-signature, attachment)]

Message #41 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Kirill A. Korinsky" <kirill <at> korins.ky>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: 45817 <at> debbugs.gnu.org, "Kirill A. Korinsky via Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
Subject: Re: bug#45817: 28.0.50; Native fails
Date: Tue, 12 Jan 2021 21:44:18 +0100

[Message part 1 (text/plain, inline)]

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 <akrl <at> sdf.org> wrote:
> 
> "Kirill A. Korinsky" <kirill <at> korins.ky <mailto:kirill <at> korins.ky>> 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

[Message part 2 (text/html, inline)]

[signature.asc (application/pgp-signature, attachment)]

Message #53 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Kirill A. Korinsky" <kirill <at> korins.ky>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: 45817 <at> debbugs.gnu.org, "Kirill A. Korinsky via Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
Subject: Re: bug#45817: 28.0.50; Native fails
Date: Thu, 14 Jan 2021 03:19:15 +0100

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

[signature.asc (application/pgp-signature, attachment)]

Message #59 received at 45817 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Kirill A. Korinsky" <kirill <at> korins.ky>
Cc: 45817 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#45817: 28.0.50; Native fails
Date: Thu, 14 Jan 2021 05:32:02 +0200

> Date: Thu, 14 Jan 2021 03:19:15 +0100
> Cc: 45817 <at> debbugs.gnu.org
> From: "Kirill A. Korinsky" via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> 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.

Message #62 received at 45817 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 45817 <at> debbugs.gnu.org, "Kirill A. Korinsky" <kirill <at> korins.ky>
Subject: Re: bug#45817: 28.0.50; Native fails
Date: Thu, 14 Jan 2021 09:33:48 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Thu, 14 Jan 2021 03:19:15 +0100
>> Cc: 45817 <at> debbugs.gnu.org
>> From: "Kirill A. Korinsky" via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> 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

Message #65 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: "Kirill A. Korinsky" <kirill <at> korins.ky>
Cc: 45817-done <at> debbugs.gnu.org,
 "Kirill A. Korinsky via Bug reports for GNU Emacs, the Swiss army knife
 of text editors" <bug-gnu-emacs <at> gnu.org>
Subject: Re: bug#45817: 28.0.50; Native fails
Date: Thu, 14 Jan 2021 09:34:32 +0000

"Kirill A. Korinsky" <kirill <at> korins.ky> writes:

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

Nice, thanks for the update, closing this.

  Andrea

Message #73 received at 45817 <at> debbugs.gnu.org (full text, mbox):

From: "Kirill A. Korinsky" <kirill <at> korins.ky>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 45817 <at> debbugs.gnu.org, Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#45817: 28.0.50; Native fails
Date: Thu, 14 Jan 2021 11:51:58 +0100

[Message part 1 (text/plain, inline)]

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 <eliz <at> gnu.org> wrote:
> 
>> Date: Thu, 14 Jan 2021 03:19:15 +0100
>> Cc: 45817 <at> debbugs.gnu.org
>> From: "Kirill A. Korinsky" via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> 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.

[Message part 2 (text/html, inline)]

[signature.asc (application/pgp-signature, attachment)]

Message #76 received at 45817 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: 45817 <at> debbugs.gnu.org, kirill <at> korins.ky
Subject: Re: bug#45817: 28.0.50; Native fails
Date: Thu, 14 Jan 2021 16:04:54 +0200

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: "Kirill A. Korinsky" <kirill <at> korins.ky>, 45817 <at> debbugs.gnu.org
> 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.

Message #79 received at 45817 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 45817 <at> debbugs.gnu.org, kirill <at> korins.ky
Subject: Re: bug#45817: 28.0.50; Native fails
Date: Thu, 14 Jan 2021 14:31:30 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: "Kirill A. Korinsky" <kirill <at> korins.ky>, 45817 <at> debbugs.gnu.org
>> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.