GNU bug report logs - #30106
Loading file /sources/emacs/lisp/emacs-lisp/ert.elc failed to provide feature `mod-test'

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 30106 in the body.
You can then email your comments to 30106 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: Jean Louis <bugs <at> gnu.support>
To: bug-gnu-emacs <at> gnu.org
Subject: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc failed to
 provide feature `mod-test'
Date: Sun, 14 Jan 2018 09:36:03 +0300

Hello,

I cannot compile the development version so that
dynamic modules work.

When making: make test, I can see this error:

  GEN      src/editfns-tests.log
  ELC      src/emacs-module-tests.elc

In toplevel form:
src/emacs-module-tests.el:32:1:Error: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc failed to provide feature `mod-test'
make[3]: *** [Makefile:146: src/emacs-module-tests.elc] Error 1
make[3]: Target 'src/emacs-module-tests.log' not
remade because of errors.

And if try to load module pq (new one from
Github), I get errors like:

Debugger entered--Lisp error: (error "Loading file /package/text/emacs-27.0.50/share/emacs/27.0.50/lisp/vc/vc-git.elc failed to provide feature ‘pq’")
  require(pq)
  eval((require 'pq) nil)
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  call-interactively(eval-last-sexp nil nil)
  command-execute(eval-last-sexp)

If anybody can help me to make loading dynamic
modules with development version, let me know.

Jean

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Sun, 14 Jan 2018 18:08:48 +0200

> Date: Sun, 14 Jan 2018 09:36:03 +0300
> From: Jean Louis <bugs <at> gnu.support>
> 
> I cannot compile the development version so that
> dynamic modules work.
> 
> When making: make test, I can see this error:
> 
>   GEN      src/editfns-tests.log
>   ELC      src/emacs-module-tests.elc
> 
> In toplevel form:
> src/emacs-module-tests.el:32:1:Error: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc failed to provide feature `mod-test'
> make[3]: *** [Makefile:146: src/emacs-module-tests.elc] Error 1
> make[3]: Target 'src/emacs-module-tests.log' not
> remade because of errors.

How did you configure and build Emacs?  What were the commands you
used for that?

(FWIW, the emacs-module-tests test works for me with today's master
branch.)

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

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Sun, 14 Jan 2018 20:47:48 +0300

Dear Eli,

I appreciate your efforts.


On Sun, Jan 14, 2018 at 06:08:48PM +0200, Eli Zaretskii wrote:
> > Date: Sun, 14 Jan 2018 09:36:03 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > 
> > I cannot compile the development version so that
> > dynamic modules work.
> > 
> > When making: make test, I can see this error:
> > 
> >   GEN      src/editfns-tests.log
> >   ELC      src/emacs-module-tests.elc
> > 
> > In toplevel form:
> > src/emacs-module-tests.el:32:1:Error: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc failed to provide feature `mod-test'
> > make[3]: *** [Makefile:146: src/emacs-module-tests.elc] Error 1
> > make[3]: Target 'src/emacs-module-tests.log' not
> > remade because of errors.
> 
> How did you configure and build Emacs?  What were the commands you
> used for that?
> 
> (FWIW, the emacs-module-tests test works for me with today's master
> branch.)

Here is how I did it:

./configure --prefix=/package/text/emacs-27.0.50/ --with-mailutils --without-imagemagick --without-pop --with-x-toolkit=lucid --with-modules

I really hope to find out what is wrong.


Jean
I 

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Sun, 14 Jan 2018 21:44:40 +0200

> Date: Sun, 14 Jan 2018 20:47:48 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: 30106 <at> debbugs.gnu.org
> 
> ./configure --prefix=/package/text/emacs-27.0.50/ --with-mailutils --without-imagemagick --without-pop --with-x-toolkit=lucid --with-modules

Does src/config.h have this line:

  #define HAVE_MODULES 1

And does src/Makefile have this line:

  MODULES_OBJ = dynlib.o emacs-module.o

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

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30106 <at> debbugs.gnu.org, Jean Louis <bugs <at> gnu.support>
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Mon, 15 Jan 2018 01:12:28 +0300

On Sun, Jan 14, 2018 at 09:44:40PM +0200, Eli Zaretskii wrote:
> > Date: Sun, 14 Jan 2018 20:47:48 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: 30106 <at> debbugs.gnu.org
> > 
> > ./configure --prefix=/package/text/emacs-27.0.50/ --with-mailutils --without-imagemagick --without-pop --with-x-toolkit=lucid --with-modules
> 
> Does src/config.h have this line:
> 
>   #define HAVE_MODULES 1

Output of grep MODULES src/config.h:

#define EMACS_CONFIG_FEATURES "XAW3D XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11 MODULES LCMS2"
#define HAVE_MODULES 1
#define MODULES_SUFFIX ".so"

> And does src/Makefile have this line:
> 
>   MODULES_OBJ = dynlib.o emacs-module.o

Output of grep MODULES Makefile:

LIBMODULES = -ldl
MODULES_OBJ = dynlib.o emacs-module.o
	eval.o floatfns.o fns.o font.o print.o lread.o $(MODULES_OBJ) \
   $(NOTIFY_LIBS) $(LIB_MATH) $(LIBZ) $(LIBMODULES) $(LIBSYSTEMD_LIBS) \



Jean

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Mon, 15 Jan 2018 15:14:57 +0200

> Date: Mon, 15 Jan 2018 01:12:28 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: Jean Louis <bugs <at> gnu.support>, 30106 <at> debbugs.gnu.org
> 
> Output of grep MODULES src/config.h:
> 
> #define EMACS_CONFIG_FEATURES "XAW3D XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11 MODULES LCMS2"
> #define HAVE_MODULES 1
> #define MODULES_SUFFIX ".so"
> 
> > And does src/Makefile have this line:
> > 
> >   MODULES_OBJ = dynlib.o emacs-module.o
> 
> Output of grep MODULES Makefile:
> 
> LIBMODULES = -ldl
> MODULES_OBJ = dynlib.o emacs-module.o
> 	eval.o floatfns.o fns.o font.o print.o lread.o $(MODULES_OBJ) \
>    $(NOTIFY_LIBS) $(LIB_MATH) $(LIBZ) $(LIBMODULES) $(LIBSYSTEMD_LIBS) \

This means your build does have support for modules.

Returning to the original error:

    ELC      src/emacs-module-tests.elc

  In toplevel form:
  src/emacs-module-tests.el:32:1:Error: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc failed to provide feature `mod-test'

line 32 of emacs-module-test.el is this:

  (require 'mod-test mod-test-file)

So one problem could be that mod-test-file is somehow not calculated
correctly:

  (eval-and-compile
    (defconst mod-test-file
      (substitute-in-file-name
       "$EMACS_TEST_DIRECTORY/data/emacs-module/mod-test")
      "File name of the module test file."))

So maybe EMACS_TEST_DIRECTORY is incorrect, you your Emacs tree
doesn't have the test/data/emacs-module/mod-test directory, or there's
no mod-test.so file in that directory?

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

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30106 <at> debbugs.gnu.org, Jean Louis <bugs <at> gnu.support>
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Mon, 15 Jan 2018 12:56:17 -0500

Eli Zaretskii wrote:

>   src/emacs-module-tests.el:32:1:Error: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc failed to provide feature `mod-test'
>
> line 32 of emacs-module-test.el is this:
>
>   (require 'mod-test mod-test-file)
>
> So one problem could be that mod-test-file is somehow not calculated
> correctly:
>
>   (eval-and-compile
>     (defconst mod-test-file
>       (substitute-in-file-name
>        "$EMACS_TEST_DIRECTORY/data/emacs-module/mod-test")
>       "File name of the module test file."))
>
> So maybe EMACS_TEST_DIRECTORY is incorrect, you your Emacs tree
> doesn't have the test/data/emacs-module/mod-test directory, or there's
> no mod-test.so file in that directory?

But that would give a different error message.

It seems that Fmodule_load does not update load-history.
This is causing Frequire to report the wrong file names in its error
message, which is making it hard to diagnose the real problem.

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

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Mon, 15 Jan 2018 21:09:38 +0300

Dear Eli,

See below:

On Mon, Jan 15, 2018 at 03:14:57PM +0200, Eli Zaretskii wrote:
> > Output of grep MODULES src/config.h:
> > 
> > #define EMACS_CONFIG_FEATURES "XAW3D XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11 MODULES LCMS2"
> > #define HAVE_MODULES 1
> > #define MODULES_SUFFIX ".so"
> > 
> > > And does src/Makefile have this line:
> > > 
> > >   MODULES_OBJ = dynlib.o emacs-module.o
> > 
> > Output of grep MODULES Makefile:
> > 
> > LIBMODULES = -ldl
> > MODULES_OBJ = dynlib.o emacs-module.o
> > 	eval.o floatfns.o fns.o font.o print.o lread.o $(MODULES_OBJ) \
> >    $(NOTIFY_LIBS) $(LIB_MATH) $(LIBZ) $(LIBMODULES) $(LIBSYSTEMD_LIBS) \
> 
> This means your build does have support for modules.
> 
> Returning to the original error:
> 
>     ELC      src/emacs-module-tests.elc

On my side that file is located in:

/sources/emacs/test/src

>   In toplevel form:
>   src/emacs-module-tests.el:32:1:Error: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc failed to provide feature `mod-test'
> 
> line 32 of emacs-module-test.el is this:
> 
>   (require 'mod-test mod-test-file)

That is same so here.

> So one problem could be that mod-test-file is somehow not calculated
> correctly:
> 
>   (eval-and-compile
>     (defconst mod-test-file
>       (substitute-in-file-name
>        "$EMACS_TEST_DIRECTORY/data/emacs-module/mod-test")
>       "File name of the module test file."))
> 
> So maybe EMACS_TEST_DIRECTORY is incorrect, you your Emacs tree
> doesn't have the test/data/emacs-module/mod-test directory, or there's
> no mod-test.so file in that directory?

There exist no directory:
test/data/emacs-module/mod-test/

There is directory:
test/data/emacs-module/

inside of which are following files:

total 76
-rw-r--r-- 1 root root  9915 Jan  3 08:19 mod-test.c
-rwxr-xr-x 1 root root 62008 Jan 14 20:56 mod-test.so

Let me know if I can help anything more.

Jean

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

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Mon, 15 Jan 2018 21:55:33 +0300

On Mon, Jan 15, 2018 at 03:14:57PM +0200, Eli Zaretskii wrote:
> > Date: Mon, 15 Jan 2018 01:12:28 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: Jean Louis <bugs <at> gnu.support>, 30106 <at> debbugs.gnu.org
> > 
> > Output of grep MODULES src/config.h:
> > 
> > #define EMACS_CONFIG_FEATURES "XAW3D XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11 MODULES LCMS2"
> > #define HAVE_MODULES 1
> > #define MODULES_SUFFIX ".so"
> > 
> > > And does src/Makefile have this line:
> > > 
> > >   MODULES_OBJ = dynlib.o emacs-module.o
> > 
> > Output of grep MODULES Makefile:
> > 
> > LIBMODULES = -ldl
> > MODULES_OBJ = dynlib.o emacs-module.o
> > 	eval.o floatfns.o fns.o font.o print.o lread.o $(MODULES_OBJ) \
> >    $(NOTIFY_LIBS) $(LIB_MATH) $(LIBZ) $(LIBMODULES) $(LIBSYSTEMD_LIBS) \
> 
> This means your build does have support for modules.
> 
> Returning to the original error:
> 
>     ELC      src/emacs-module-tests.elc
> 
>   In toplevel form:
>   src/emacs-module-tests.el:32:1:Error: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc failed to provide feature `mod-test'
> 
> line 32 of emacs-module-test.el is this:
> 
>   (require 'mod-test mod-test-file)
> 
> So one problem could be that mod-test-file is somehow not calculated
> correctly:
> 
>   (eval-and-compile
>     (defconst mod-test-file
>       (substitute-in-file-name
>        "$EMACS_TEST_DIRECTORY/data/emacs-module/mod-test")
>       "File name of the module test file."))
> 
> So maybe EMACS_TEST_DIRECTORY is incorrect, you your Emacs tree
> doesn't have the test/data/emacs-module/mod-test directory, or there's
> no mod-test.so file in that directory?

I can see that 'make check' fails so:

  ELC      src/emacs-module-tests.elc
Emacs module assertion: Module function called from outside the current Lisp thread
/bin/sh: line 1:  6214 Aborted                 EMACSLOADPATH= LC_ALL=C EMACS_TEST_DIRECTORY=/sources/emacs/test "../src/emacs" --module-assertions -batch --no-site-file --no-site-lisp -L ":." -f batch-byte-compile src/emacs-module-tests.el
make[3]: *** [Makefile:146: src/emacs-module-tests.elc] Error 134
make[3]: Target 'src/emacs-module-tests.log' not remade because of errors.
  GEN      src/eval-tests.log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Mon, 15 Jan 2018 22:15:55 +0200

> Date: Mon, 15 Jan 2018 21:55:33 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: 30106 <at> debbugs.gnu.org
> 
> I can see that 'make check' fails so:
> 
>   ELC      src/emacs-module-tests.elc
> Emacs module assertion: Module function called from outside the current Lisp thread
> /bin/sh: line 1:  6214 Aborted                 EMACSLOADPATH= LC_ALL=C EMACS_TEST_DIRECTORY=/sources/emacs/test "../src/emacs" --module-assertions -batch --no-site-file --no-site-lisp -L ":." -f batch-byte-compile src/emacs-module-tests.el
> make[3]: *** [Makefile:146: src/emacs-module-tests.elc] Error 134
> make[3]: Target 'src/emacs-module-tests.log' not remade because of errors.
>   GEN      src/eval-tests.log

Was your Emacs built with threads?  What OS is that?

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

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Tue, 16 Jan 2018 08:17:27 +0300

Hello,

On Mon, Jan 15, 2018 at 10:15:55PM +0200, Eli Zaretskii wrote:
> > Date: Mon, 15 Jan 2018 21:55:33 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: 30106 <at> debbugs.gnu.org
> > 
> > I can see that 'make check' fails so:
> > 
> >   ELC      src/emacs-module-tests.elc
> > Emacs module assertion: Module function called from outside the current Lisp thread
> > /bin/sh: line 1:  6214 Aborted                 EMACSLOADPATH= LC_ALL=C EMACS_TEST_DIRECTORY=/sources/emacs/test "../src/emacs" --module-assertions -batch --no-site-file --no-site-lisp -L ":." -f batch-byte-compile src/emacs-module-tests.el
> > make[3]: *** [Makefile:146: src/emacs-module-tests.elc] Error 134
> > make[3]: Target 'src/emacs-module-tests.log' not remade because of errors.
> >   GEN      src/eval-tests.log
> 
> Was your Emacs built with threads?  What OS is that?

I tried building with this configuration:

./configure --prefix=/package/text/emacs
--with-modules --without-all --without-pop
--with-mailutils

and OS is just GNU with kernel Linux, I do not use
distributions, I am compiling from source.

I have tried --without-threads and it is not
working as well.

Jean

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

From: Glenn Morris <rgm <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Tue, 16 Jan 2018 13:06:32 -0500

Jean Louis wrote:

>>  ELC      src/emacs-module-tests.elc
>> 
>> In toplevel form:
>> src/emacs-module-tests.el:32:1:Error: Loading file
>> /sources/emacs/lisp/emacs-lisp/ert.elc failed to provide feature
>> `mod-test'
>> make[3]: *** [Makefile:146: src/emacs-module-tests.elc] Error 1
[...]
>> >   ELC      src/emacs-module-tests.elc
>> > Emacs module assertion: Module function called from outside the
>> > current Lisp thread
>> > /bin/sh: line 1: 6214 Aborted EMACSLOADPATH= LC_ALL=C
>> > EMACS_TEST_DIRECTORY=/sources/emacs/test "../src/emacs"
>> > --module-assertions -batch --no-site-file --no-site-lisp -L ":."
>> > -f batch-byte-compile src/emacs-module-tests.el

So what's changed such that you now get a different error to the one
that is the subject of this report?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Tue, 16 Jan 2018 20:10:49 +0200

> Date: Mon, 15 Jan 2018 21:55:33 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: 30106 <at> debbugs.gnu.org
> 
> I can see that 'make check' fails so:
> 
>   ELC      src/emacs-module-tests.elc
> Emacs module assertion: Module function called from outside the current Lisp thread
> /bin/sh: line 1:  6214 Aborted                 EMACSLOADPATH= LC_ALL=C EMACS_TEST_DIRECTORY=/sources/emacs/test "../src/emacs" --module-assertions -batch --no-site-file --no-site-lisp -L ":." -f batch-byte-compile src/emacs-module-tests.el

Ah, that changes almost everything.  The test fails here:

  static void
  module_assert_thread (void)
  {
    if (!module_assertions)
      return;
    if (!in_current_thread ())
      module_abort ("Module function called from outside "  <<<<<<<<<<<<<<<
		    "the current Lisp thread");
    if (gc_in_progress)
      module_abort ("Module function called during garbage collection");
  }

And in_current_thread does this:

  static bool
  in_current_thread (void)
  {
    if (current_thread == NULL)
      return false;
  #ifdef HAVE_PTHREAD
    return pthread_equal (pthread_self (), current_thread->thread_id);
  #elif defined WINDOWSNT
    return GetCurrentThreadId () == current_thread->thread_id;
  #endif
  }

So either current_thread is NULL in your case, or pthread_equal
returns false.  Can you tell which one of these happens?

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

From: Jean Louis <bugs <at> gnu.support>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Tue, 16 Jan 2018 22:17:01 +0300

On Tue, Jan 16, 2018 at 01:06:32PM -0500, Glenn Morris wrote:
> Jean Louis wrote:
> 
> >>  ELC      src/emacs-module-tests.elc
> >> 
> >> In toplevel form:
> >> src/emacs-module-tests.el:32:1:Error: Loading file
> >> /sources/emacs/lisp/emacs-lisp/ert.elc failed to provide feature
> >> `mod-test'
> >> make[3]: *** [Makefile:146: src/emacs-module-tests.elc] Error 1
> [...]
> >> >   ELC      src/emacs-module-tests.elc
> >> > Emacs module assertion: Module function called from outside the
> >> > current Lisp thread
> >> > /bin/sh: line 1: 6214 Aborted EMACSLOADPATH= LC_ALL=C
> >> > EMACS_TEST_DIRECTORY=/sources/emacs/test "../src/emacs"
> >> > --module-assertions -batch --no-site-file --no-site-lisp -L ":."
> >> > -f batch-byte-compile src/emacs-module-tests.el
> 
> So what's changed such that you now get a different error to the one
> that is the subject of this report?

The original report relates to the fact that I
cannot do (require 'pq) for dynamic module in
question.

I have tried to "make check", and the message
above is the result of it.

Jean

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

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Tue, 16 Jan 2018 22:18:55 +0300

On Tue, Jan 16, 2018 at 08:10:49PM +0200, Eli Zaretskii wrote:
> > Date: Mon, 15 Jan 2018 21:55:33 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: 30106 <at> debbugs.gnu.org
> > 
> > I can see that 'make check' fails so:
> > 
> >   ELC      src/emacs-module-tests.elc
> > Emacs module assertion: Module function called from outside the current Lisp thread
> > /bin/sh: line 1:  6214 Aborted                 EMACSLOADPATH= LC_ALL=C EMACS_TEST_DIRECTORY=/sources/emacs/test "../src/emacs" --module-assertions -batch --no-site-file --no-site-lisp -L ":." -f batch-byte-compile src/emacs-module-tests.el
> 
> Ah, that changes almost everything.  The test fails here:
> 
>   static void
>   module_assert_thread (void)
>   {
>     if (!module_assertions)
>       return;
>     if (!in_current_thread ())
>       module_abort ("Module function called from outside "  <<<<<<<<<<<<<<<
> 		    "the current Lisp thread");
>     if (gc_in_progress)
>       module_abort ("Module function called during garbage collection");
>   }
> 
> And in_current_thread does this:
> 
>   static bool
>   in_current_thread (void)
>   {
>     if (current_thread == NULL)
>       return false;
>   #ifdef HAVE_PTHREAD
>     return pthread_equal (pthread_self (), current_thread->thread_id);
>   #elif defined WINDOWSNT
>     return GetCurrentThreadId () == current_thread->thread_id;
>   #endif
>   }
> 
> So either current_thread is NULL in your case, or pthread_equal
> returns false.  Can you tell which one of these happens?

I cannot test it myself on my own. You may tell me
what to do, to test it.

Do I miss some software package?

Jean

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Wed, 17 Jan 2018 17:36:45 +0200

> Date: Tue, 16 Jan 2018 22:18:55 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: 30106 <at> debbugs.gnu.org
> 
> >   in_current_thread (void)
> >   {
> >     if (current_thread == NULL)
> >       return false;
> >   #ifdef HAVE_PTHREAD
> >     return pthread_equal (pthread_self (), current_thread->thread_id);
> >   #elif defined WINDOWSNT
> >     return GetCurrentThreadId () == current_thread->thread_id;
> >   #endif
> >   }
> > 
> > So either current_thread is NULL in your case, or pthread_equal
> > returns false.  Can you tell which one of these happens?
> 
> I cannot test it myself on my own. You may tell me
> what to do, to test it.

Apply the patch below, rebuild Emacs, rerun the test, and see if
there's the telltale "current_thread is NULL" message in the log.

> Do I miss some software package?

Not sure yet.

diff --git a/src/emacs-module.c b/src/emacs-module.c
index 00f0e86..333c583 100644
--- a/src/emacs-module.c
+++ b/src/emacs-module.c
@@ -804,7 +804,10 @@ static bool
 in_current_thread (void)
 {
   if (current_thread == NULL)
+    {
+      fprintf (stderr, "current_thread is NULL\n");
     return false;
+    }
 #ifdef HAVE_PTHREAD
   return pthread_equal (pthread_self (), current_thread->thread_id);
 #elif defined WINDOWSNT

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

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Wed, 17 Jan 2018 20:03:10 +0300

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

On Wed, Jan 17, 2018 at 05:36:45PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 16 Jan 2018 22:18:55 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: 30106 <at> debbugs.gnu.org
> > 
> > >   in_current_thread (void)
> > >   {
> > >     if (current_thread == NULL)
> > >       return false;
> > >   #ifdef HAVE_PTHREAD
> > >     return pthread_equal (pthread_self (), current_thread->thread_id);
> > >   #elif defined WINDOWSNT
> > >     return GetCurrentThreadId () == current_thread->thread_id;
> > >   #endif
> > >   }
> > > 
> > > So either current_thread is NULL in your case, or pthread_equal
> > > returns false.  Can you tell which one of these happens?
> > 
> > I cannot test it myself on my own. You may tell me
> > what to do, to test it.
> 
> Apply the patch below, rebuild Emacs, rerun the test, and see if
> there's the telltale "current_thread is NULL"
> message in the log.

I have done that, I did not see during "make
check" the line "current_thread is NULL", and I am
attaching the output from "make check".

Jean

> 
> > Do I miss some software package?
> 
> Not sure yet.
> 
> diff --git a/src/emacs-module.c b/src/emacs-module.c
> index 00f0e86..333c583 100644
> --- a/src/emacs-module.c
> +++ b/src/emacs-module.c
> @@ -804,7 +804,10 @@ static bool
>  in_current_thread (void)
>  {
>    if (current_thread == NULL)
> +    {
> +      fprintf (stderr, "current_thread is NULL\n");
>      return false;
> +    }
>  #ifdef HAVE_PTHREAD
>    return pthread_equal (pthread_self (), current_thread->thread_id);
>  #elif defined WINDOWSNT

[check.log (text/plain, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Wed, 17 Jan 2018 20:25:51 +0200

> Date: Wed, 17 Jan 2018 20:03:10 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: 30106 <at> debbugs.gnu.org
> 
> > Apply the patch below, rebuild Emacs, rerun the test, and see if
> > there's the telltale "current_thread is NULL"
> > message in the log.
> 
> I have done that, I did not see during "make
> check" the line "current_thread is NULL", and I am
> attaching the output from "make check".

Then I'm not sure what's going on there.  Is HAVE_PTHREAD defined in
src/config.h?

Does anyone else on this list see anything similar?

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

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Wed, 17 Jan 2018 18:32:24 +0000

On Wed 17 Jan 2018, Jean Louis wrote:

> On Wed, Jan 17, 2018 at 05:36:45PM +0200, Eli Zaretskii wrote:
>> > Date: Tue, 16 Jan 2018 22:18:55 +0300
>> > From: Jean Louis <bugs <at> gnu.support>
>> > Cc: 30106 <at> debbugs.gnu.org
>> > 
>> > >   in_current_thread (void)
>> > >   {
>> > >     if (current_thread == NULL)
>> > >       return false;
>> > >   #ifdef HAVE_PTHREAD
>> > >     return pthread_equal (pthread_self (), current_thread->thread_id);
>> > >   #elif defined WINDOWSNT
>> > >     return GetCurrentThreadId () == current_thread->thread_id;
>> > >   #endif
>> > >   }
>> > > 
>> > > So either current_thread is NULL in your case, or pthread_equal
>> > > returns false.  Can you tell which one of these happens?
>> > 
>> > I cannot test it myself on my own. You may tell me
>> > what to do, to test it.
>> 
>> Apply the patch below, rebuild Emacs, rerun the test, and see if
>> there's the telltale "current_thread is NULL"
>> message in the log.
>
> I have done that, I did not see during "make
> check" the line "current_thread is NULL", and I am
> attaching the output from "make check".

Looking at the log you supplied:

  CCLD     data/emacs-module/mod-test.so
  ELC      src/emacs-module-tests.elc
Emacs module assertion: Module function called from outside the current Lisp thread

That would seem to be the cause of your problem.

    AndyM

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

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30106 <at> debbugs.gnu.org, Jean Louis <bugs <at> gnu.support>
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Wed, 17 Jan 2018 13:51:05 -0500

Eli Zaretskii wrote:

> Does anyone else on this list see anything similar?

Same error on rhel 7.4 if configure with --without-threads --with-modules.

  Emacs module assertion: Module function called from outside the current
  Lisp thread

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

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30106 <at> debbugs.gnu.org, Jean Louis <bugs <at> gnu.support>
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Wed, 17 Jan 2018 13:58:17 -0500

Glenn Morris wrote:

> Same error on rhel 7.4 if configure with --without-threads --with-modules.
>
>   Emacs module assertion: Module function called from outside the current
>   Lisp thread

PS --without-all implies --without-threads, ref.

  https://debbugs.gnu.org/30106#37

Note that the OP has switched to using --without-all from the initial
report, and is now having a different problem. Compare

https://debbugs.gnu.org/30106#11
https://debbugs.gnu.org/30106#37

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

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Wed, 17 Jan 2018 22:20:39 +0300

On Wed, Jan 17, 2018 at 08:25:51PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 17 Jan 2018 20:03:10 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: 30106 <at> debbugs.gnu.org
> > 
> > > Apply the patch below, rebuild Emacs, rerun the test, and see if
> > > there's the telltale "current_thread is NULL"
> > > message in the log.
> > 
> > I have done that, I did not see during "make
> > check" the line "current_thread is NULL", and I am
> > attaching the output from "make check".
> 
> Then I'm not sure what's going on there.  Is HAVE_PTHREAD defined in
> src/config.h?
> 
> Does anyone else on this list see anything similar?

src/config.h:

admin-> grep HAVE_PTHREAD src/config.h
#define HAVE_PTHREAD 1
#define HAVE_PTHREAD_H 1
#define HAVE_PTHREAD_SIGMASK 1

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

From: Jean Louis <bugs <at> gnu.support>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Wed, 17 Jan 2018 22:37:35 +0300

On Wed, Jan 17, 2018 at 01:58:17PM -0500, Glenn Morris wrote:
> Glenn Morris wrote:
> 
> > Same error on rhel 7.4 if configure with --without-threads --with-modules.
> >
> >   Emacs module assertion: Module function called from outside the current
> >   Lisp thread
> 
> PS --without-all implies --without-threads, ref.
> 
>   https://debbugs.gnu.org/30106#37
> 
> Note that the OP has switched to using --without-all from the initial
> report, and is now having a different problem. Compare
> 
> https://debbugs.gnu.org/30106#11
> https://debbugs.gnu.org/30106#37

In beginning I did not use without-all, then I
changed, overlooked it.

However, now at this point, but maybe after
patching, I could compile it so that it works. I
can load the dynamic module with (require 'pq)

Earlier, even though I did not use --without-all,
but I did use --with-modules I could not compile
it to work.

Jean

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 30106 <at> debbugs.gnu.org, bugs <at> gnu.support
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Wed, 17 Jan 2018 22:05:44 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: Jean Louis <bugs <at> gnu.support>,  30106 <at> debbugs.gnu.org
> Date: Wed, 17 Jan 2018 13:51:05 -0500
> 
> Eli Zaretskii wrote:
> 
> > Does anyone else on this list see anything similar?
> 
> Same error on rhel 7.4 if configure with --without-threads --with-modules.
> 
>   Emacs module assertion: Module function called from outside the current
>   Lisp thread

Does this go away if you put

  return true;

at the end of in_current_thread, outside of all the #ifdef's?

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

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30106 <at> debbugs.gnu.org, bugs <at> gnu.support
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Wed, 17 Jan 2018 15:29:19 -0500

Eli Zaretskii wrote:

>> Same error on rhel 7.4 if configure with --without-threads --with-modules.
>> 
>>   Emacs module assertion: Module function called from outside the current
>>   Lisp thread
>
> Does this go away if you put
>
>   return true;
>
> at the end of in_current_thread, outside of all the #ifdef's?

No.

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 30106 <at> debbugs.gnu.org, bugs <at> gnu.support
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Wed, 17 Jan 2018 22:16:58 +0000

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

Glenn Morris <rgm <at> gnu.org> schrieb am Mi., 17. Jan. 2018 um 21:31 Uhr:

> Eli Zaretskii wrote:
>
> >> Same error on rhel 7.4 if configure with --without-threads
> --with-modules.
> >>
> >>   Emacs module assertion: Module function called from outside the
> current
> >>   Lisp thread
> >
> > Does this go away if you put
> >
> >   return true;
> >
> > at the end of in_current_thread, outside of all the #ifdef's?
>
> No.
>
>
>
>
>
The current implementation of in_current_thread is definitely bogus if
threads are disabled; I can't even compile temacs with --without-threads
--with-modules:

*emacs-module.c:814:42: **error: **incompatible integer to pointer
conversion passing 'sys_thread_t' (aka 'int') to parameter of type
'pthread_t _Nullable'*

*      (aka 'struct _opaque_pthread_t *') [-Werror,-Wint-conversion]*

  return pthread_equal (pthread_self (), current_thread->thread_id);

*                                         ^~~~~~~~~~~~~~~~~~~~~~~~~*

*/usr/include/pthread.h:340:59: note: *passing argument to parameter here

int pthread_equal(pthread_t _Nullable, pthread_t _Nullable);


because if threads are disabled, the thread ID is an int.

The function also doesn't handle the case where neither HAVE_PTHREAD nor
WINDOWSNT are defined (but maybe we don't have such platforms).

Maybe systhread.h should have a function

extern sys_thread_t sys_thread_self ();

so emacs-module.c doesn't have to care about the threading implementations.

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

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 30106 <at> debbugs.gnu.org, bugs <at> gnu.support
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Wed, 17 Jan 2018 22:18:54 +0000

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

Philipp Stephani <p.stephani2 <at> gmail.com> schrieb am Mi., 17. Jan. 2018 um
23:16 Uhr:

> Maybe systhread.h should have a function
>
> extern sys_thread_t sys_thread_self ();
>
>
> Uh, it already has that :)

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

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org>,
 30106 <at> debbugs.gnu.org
Cc: Philipp Stephani <phst <at> google.com>
Subject: [PATCH 1/2] Use recommended long options syntax in man page
Date: Wed, 17 Jan 2018 23:28:45 +0100

* doc/man/emacs.1.in: Specify equals sign for long options, as
recommended in the manual.
---
 doc/man/emacs.1.in | 50 +++++++++++++++++++++++++-------------------------
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/doc/man/emacs.1.in b/doc/man/emacs.1.in
index 7654c9610d..5116953041 100644
--- a/doc/man/emacs.1.in
+++ b/doc/man/emacs.1.in
@@ -61,7 +61,7 @@ The following options are of general interest:
 Edit
 .IR file .
 .TP
-.BI \-\-file " file\fR,\fP " \-\-find-file " file\fR,\fP " \-\-visit " file"
+.BI \-\-file= "file\fR,\fP " \-\-find-file= "file\fR,\fP " \-\-visit= "file"
 The same as specifying
 .I file
 directly as an argument.
@@ -79,7 +79,7 @@ Go to the specified
 and
 .IR column .
 .TP
-.BI \-\-chdir " directory"
+.BI \-\-chdir= "directory"
 Change to
 .IR directory .
 .TP
@@ -112,12 +112,12 @@ Lisp debugger during the processing of the user init file
 .BR ~/.emacs .
 This is useful for debugging problems in the init file.
 .TP
-.BI \-u " user\fR,\fP " \-\-user " user"
+.BI \-u " user\fR,\fP " \-\-user= "user"
 Load
 .IR user 's
 init file.
 .TP
-.BI \-t " file\fR,\fP " \-\-terminal " file"
+.BI \-t " file\fR,\fP " \-\-terminal= "file"
 Use specified
 .I file
 as the terminal instead of using stdin/stdout.
@@ -144,15 +144,15 @@ The following options are Lisp-oriented
 (these options are processed in the order encountered):
 .RS
 .TP 8
-.BI \-f " function\fR,\fP " \-\-funcall " function"
+.BI \-f " function\fR,\fP " \-\-funcall= "function"
 Execute the lisp function
 .IR function .
 .TP
-.BI \-l " file\fR,\fP " \-\-load " file"
+.BI \-l " file\fR,\fP " \-\-load= "file"
 Load the lisp code in the file
 .IR file .
 .TP
-.BI \-\-eval " expr\fR,\fP " \-\-execute " expr"
+.BI \-\-eval= "expr\fR,\fP " \-\-execute= "expr"
 Evaluate the Lisp expression
 .IR expr .
 .RE
@@ -168,12 +168,12 @@ The editor will send messages to stderr.
 You must use \-l and \-f options to specify files to execute
 and functions to call.
 .TP
-.BI \-\-script " file"
+.BI \-\-script= "file"
 Run
 .I file
 as an Emacs Lisp script.
 .TP
-.BI \-\-insert " file"
+.BI \-\-insert= "file"
 Insert contents of
 .I file
 into the current buffer.
@@ -183,7 +183,7 @@ Exit
 .I Emacs
 while in batch mode.
 .TP
-.BI \-L " dir\fR,\fP " \-\-directory " dir"
+.BI \-L " dir\fR,\fP " \-\-directory= "dir"
 Add
 .I dir
 to the list of directories
@@ -206,13 +206,13 @@ process so that you can continue using your original window.
 can be started with the following X switches:
 .RS
 .TP 8
-.BI \-\-name " name"
+.BI \-\-name= "name"
 Specify the name which should be assigned to the initial
 .I Emacs
 window.
 This controls looking up X resources as well as the window title.
 .TP
-.BI \-T " name\fR,\fP " \-\-title " name"
+.BI \-T " name\fR,\fP " \-\-title= "name"
 Specify the title for the initial X window.
 .TP
 .BR \-r ", " \-rv ", " \-\-reverse\-video
@@ -220,7 +220,7 @@ Display the
 .I Emacs
 window in reverse video.
 .TP
-.BI \-fn " font\fR,\fP " \-\-font " font"
+.BI \-fn " font\fR,\fP " \-\-font= "font"
 Set the
 .I Emacs
 window's font to that specified by
@@ -247,7 +247,7 @@ for more information.
 When you specify a font, be sure to put a space between the
 switch and the font name.
 .TP
-.BI \-\-xrm " resources"
+.BI \-\-xrm= "resources"
 Set additional X resources.
 .TP
 .BI "\-\-color\fR,\fP \-\-color=" mode
@@ -256,20 +256,20 @@ Override color mode for character terminals;
 defaults to "auto", and can also be "never", "auto", "always",
 or a mode name like "ansi8".
 .TP
-.BI \-bw " pixels\fR,\fP " \-\-border\-width " pixels"
+.BI \-bw " pixels\fR,\fP " \-\-border\-width= "pixels"
 Set the
 .I Emacs
 window's border width to the number of pixels specified by
 .IR pixels .
 Defaults to one pixel on each side of the window.
 .TP
-.BI \-ib " pixels\fR,\fP " \-\-internal\-border " pixels"
+.BI \-ib " pixels\fR,\fP " \-\-internal\-border= "pixels"
 Set the window's internal border width to the number of pixels specified
 by
 .IR pixels .
 Defaults to one pixel of padding on each side of the window.
 .TP
-.BI \-g " geometry\fR,\fP " \-\-geometry " geometry"
+.BI \-g " geometry\fR,\fP " \-\-geometry= "geometry"
 Set the
 .I Emacs
 window's width, height, and position as specified.
@@ -282,7 +282,7 @@ See the Emacs manual, section "Options for Window Size and Position",
 for information on how window sizes interact
 with selecting or deselecting the tool bar and menu bar.
 .TP
-.BI \-lsp " pixels\fR,\fP " \-\-line\-spacing " pixels"
+.BI \-lsp " pixels\fR,\fP " \-\-line\-spacing= "pixels"
 Additional space to put between lines.
 .TP
 .BR \-vb ", " \-\-vertical\-scroll\-bars
@@ -300,26 +300,26 @@ Make the first frame as wide as the screen.
 .BR \-mm ", " \-\-maximized
 Maximize the first frame, like "\-fw \-fh".
 .TP
-.BI \-fg " color\fR,\fP " \-\-foreground\-color " color"
+.BI \-fg " color\fR,\fP " \-\-foreground\-color= "color"
 On color displays, set the color of the text.
 
 Use the command
 .I M\-x list\-colors\-display
 for a list of valid color names.
 .TP
-.BI \-bg " color\fR,\fP " \-\-background\-color " color"
+.BI \-bg " color\fR,\fP " \-\-background\-color= "color"
 On color displays, set the color of the window's background.
 .TP
-.BI \-bd " color\fR,\fP " \-\-border\-color " color"
+.BI \-bd " color\fR,\fP " \-\-border\-color= "color"
 On color displays, set the color of the window's border.
 .TP
-.BI \-cr " color\fR,\fP " \-\-cursor\-color " color"
+.BI \-cr " color\fR,\fP " \-\-cursor\-color= "color"
 On color displays, set the color of the window's text cursor.
 .TP
-.BI \-ms " color\fR,\fP " \-\-mouse\-color " color"
+.BI \-ms " color\fR,\fP " \-\-mouse\-color= "color"
 On color displays, set the color of the window's mouse cursor.
 .TP
-.BI \-d " displayname\fR,\fP " \-\-display " displayname"
+.BI \-d " displayname\fR,\fP " \-\-display= "displayname"
 Create the
 .I Emacs
 window on the display specified by
@@ -337,7 +337,7 @@ in iconified state.
 .BR \-nbc ", " \-\-no\-blinking\-cursor
 Disable blinking cursor.
 .TP
-.BI \-\-parent-id " xid"
+.BI \-\-parent-id= "xid"
 Set parent window.
 .TP
 .BR \-nw ", " \-\-no\-window\-system
-- 
2.15.1

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org>,
 30106 <at> debbugs.gnu.org
Cc: Philipp Stephani <phst <at> google.com>
Subject: [PATCH 2/2] Fix module support if threads are disabled (Bug#30106)
Date: Wed, 17 Jan 2018 23:28:46 +0100

* src/systhread.c (sys_thread_equal): New function.
* src/emacs-module.c (in_current_thread): Use it.
---
 src/emacs-module.c |  7 ++-----
 src/systhread.c    | 18 ++++++++++++++++++
 src/systhread.h    |  1 +
 3 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/src/emacs-module.c b/src/emacs-module.c
index 00f0e86d7d..298080e646 100644
--- a/src/emacs-module.c
+++ b/src/emacs-module.c
@@ -31,6 +31,7 @@ along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
 #include "coding.h"
 #include "keyboard.h"
 #include "syssignal.h"
+#include "systhread.h"
 #include "thread.h"
 
 #include <intprops.h>
@@ -805,11 +806,7 @@ in_current_thread (void)
 {
   if (current_thread == NULL)
     return false;
-#ifdef HAVE_PTHREAD
-  return pthread_equal (pthread_self (), current_thread->thread_id);
-#elif defined WINDOWSNT
-  return GetCurrentThreadId () == current_thread->thread_id;
-#endif
+  return sys_thread_equal (sys_thread_self (), current_thread->thread_id);
 }
 
 static void
diff --git a/src/systhread.c b/src/systhread.c
index 4ffb7db143..3f162a2bcb 100644
--- a/src/systhread.c
+++ b/src/systhread.c
@@ -74,6 +74,12 @@ sys_thread_self (void)
   return 0;
 }
 
+bool
+sys_thread_equal (sys_thread_t t, sys_thread_t u)
+{
+  return t == u;
+}
+
 int
 sys_thread_create (sys_thread_t *t, const char *name,
 		   thread_creation_function *func, void *datum)
@@ -155,6 +161,12 @@ sys_thread_self (void)
   return pthread_self ();
 }
 
+bool
+sys_thread_equal (sys_thread_t t, sys_thread_t u)
+{
+  return pthread_equal (t, u);
+}
+
 int
 sys_thread_create (sys_thread_t *thread_ptr, const char *name,
 		   thread_creation_function *func, void *arg)
@@ -323,6 +335,12 @@ sys_thread_self (void)
   return (sys_thread_t) GetCurrentThreadId ();
 }
 
+bool
+sys_thread_equal (sys_thread_t t, sys_thread_t u)
+{
+  return t == u;
+}
+
 static thread_creation_function *thread_start_address;
 
 /* _beginthread wants a void function, while we are passed a function
diff --git a/src/systhread.h b/src/systhread.h
index 4745d22065..5dbb12dffb 100644
--- a/src/systhread.h
+++ b/src/systhread.h
@@ -100,6 +100,7 @@ extern void sys_cond_broadcast (sys_cond_t *);
 extern void sys_cond_destroy (sys_cond_t *);
 
 extern sys_thread_t sys_thread_self (void);
+extern bool sys_thread_equal (sys_thread_t, sys_thread_t);
 
 extern int sys_thread_create (sys_thread_t *, const char *,
 			      thread_creation_function *,
-- 
2.15.1

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org>,
 30106 <at> debbugs.gnu.org
Cc: Philipp Stephani <phst <at> google.com>
Subject: Re: bug#30106: [PATCH 1/2] Use recommended long options syntax in man
 page
Date: Wed, 17 Jan 2018 22:35:24 +0000

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

Philipp Stephani <p.stephani2 <at> gmail.com> schrieb am Mi., 17. Jan. 2018 um
23:30 Uhr:

> * doc/man/emacs.1.in: Specify equals sign for long options, as
> recommended in the manual.
>

Please ignore this, it obviously has nothing to do with this bug. I've
started off from the wrong branch and then didn't pay close attention to
the output of `git send-email'.

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: rgm <at> gnu.org, 30106 <at> debbugs.gnu.org, bugs <at> gnu.support
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Thu, 18 Jan 2018 15:59:47 +0200

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Wed, 17 Jan 2018 22:16:58 +0000
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 30106 <at> debbugs.gnu.org, bugs <at> gnu.support
> 
> The function also doesn't handle the case where neither HAVE_PTHREAD nor WINDOWSNT are defined
> (but maybe we don't have such platforms).

We don't, see sys_thread.c.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: phst <at> google.com, rgm <at> gnu.org, 30106 <at> debbugs.gnu.org
Subject: Re: [PATCH 2/2] Fix module support if threads are disabled (Bug#30106)
Date: Thu, 18 Jan 2018 16:04:05 +0200

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Cc: Philipp Stephani <phst <at> google.com>
> Date: Wed, 17 Jan 2018 23:28:46 +0100
> 
> * src/systhread.c (sys_thread_equal): New function.
> * src/emacs-module.c (in_current_thread): Use it.

I'd prefer that the only file that calls systhread.c functions is
thread.c; systhread.c is supposed to be low-level code concealed from
application levels.  So this would call for another level of
indirection: add a new function to thread.c, and call that from
emacs-module.c.

Otherwise, LGTM for master; thanks.

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: phst <at> google.com, 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: [PATCH 2/2] Fix module support if threads are disabled
 (Bug#30106)
Date: Thu, 18 Jan 2018 14:23:03 +0000

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

Eli Zaretskii <eliz <at> gnu.org> schrieb am Do., 18. Jan. 2018 um 15:05 Uhr:

> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Cc: Philipp Stephani <phst <at> google.com>
> > Date: Wed, 17 Jan 2018 23:28:46 +0100
> >
> > * src/systhread.c (sys_thread_equal): New function.
> > * src/emacs-module.c (in_current_thread): Use it.
>
> I'd prefer that the only file that calls systhread.c functions is
> thread.c; systhread.c is supposed to be low-level code concealed from
> application levels.  So this would call for another level of
> indirection: add a new function to thread.c, and call that from
> emacs-module.c.
>

Makes sense, I've moved in_current_thread to thread.c because it's
unrelated to modules.


>
> Otherwise, LGTM for master; thanks.
>
>
Can we push this to emacs-26? Right now emacs-26 can't even be compiled
with --without-threads --with-modules (on some systems at least).

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: phst <at> google.com, 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: [PATCH 2/2] Fix module support if threads are disabled
 (Bug#30106)
Date: Thu, 18 Jan 2018 17:23:29 +0200

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Thu, 18 Jan 2018 14:23:03 +0000
> Cc: phst <at> google.com, 30106 <at> debbugs.gnu.org
> 
>  I'd prefer that the only file that calls systhread.c functions is
>  thread.c; systhread.c is supposed to be low-level code concealed from
>  application levels.  So this would call for another level of
>  indirection: add a new function to thread.c, and call that from
>  emacs-module.c.
> 
> Makes sense, I've moved in_current_thread to thread.c because it's unrelated to modules.

Thanks.

>  Otherwise, LGTM for master; thanks.
> 
> Can we push this to emacs-26? Right now emacs-26 can't even be compiled with --without-threads
> --with-modules (on some systems at least). 

How important is this?  --with-modules is an opt-in switch, and the
default is to build with threads.  So this sounds not very important
to me, and the change, although simple, is not really trivial, and
will affect any module.  So I'm uneasy putting this on emacs-26,
especially since the Emacs 26.0.91 tarball is already ready and is
awaiting upload, so this will only go into the next pretest, which I
hoped could be a release candidate...

Do you think leaving this for the next release will be so bad?

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

From: Glenn Morris <rgm <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 30106 <at> debbugs.gnu.org, bugs <at> gnu.support
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Thu, 18 Jan 2018 12:40:32 -0500

Philipp Stephani wrote:

> The function also doesn't handle the case where neither HAVE_PTHREAD nor
> WINDOWSNT are defined (but maybe we don't have such platforms).

I don't know, but if not then IMO configure should explicitly reject
that situation.

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

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: phst <at> google.com, Philipp Stephani <p.stephani2 <at> gmail.com>,
 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: [PATCH 2/2] Fix module support if threads are disabled
 (Bug#30106)
Date: Thu, 18 Jan 2018 12:41:37 -0500

If it's not to be fixed then IMO in the meantime configure should
explicitly reject --with-modules if threads are disabled.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: phst <at> google.com, p.stephani2 <at> gmail.com, 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: [PATCH 2/2] Fix module support if threads are disabled
 (Bug#30106)
Date: Thu, 18 Jan 2018 20:53:11 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: Philipp Stephani <p.stephani2 <at> gmail.com>,  phst <at> google.com,  30106 <at> debbugs.gnu.org
> Date: Thu, 18 Jan 2018 12:41:37 -0500
> 
> 
> If it's not to be fixed then IMO in the meantime configure should
> explicitly reject --with-modules if threads are disabled.

That'd replace one non-trivial change with another, so I think it's
worse than fixing the problem.

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: phst <at> google.com, 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: [PATCH 2/2] Fix module support if threads are disabled
 (Bug#30106)
Date: Thu, 18 Jan 2018 19:25:53 +0000

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

Eli Zaretskii <eliz <at> gnu.org> schrieb am Do., 18. Jan. 2018 um 16:23 Uhr:

> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Thu, 18 Jan 2018 14:23:03 +0000
> > Cc: phst <at> google.com, 30106 <at> debbugs.gnu.org
> >
> >  I'd prefer that the only file that calls systhread.c functions is
> >  thread.c; systhread.c is supposed to be low-level code concealed from
> >  application levels.  So this would call for another level of
> >  indirection: add a new function to thread.c, and call that from
> >  emacs-module.c.
> >
> > Makes sense, I've moved in_current_thread to thread.c because it's
> unrelated to modules.
>
> Thanks.
>
> >  Otherwise, LGTM for master; thanks.
> >
> > Can we push this to emacs-26? Right now emacs-26 can't even be compiled
> with --without-threads
> > --with-modules (on some systems at least).
>
> How important is this?  --with-modules is an opt-in switch, and the
> default is to build with threads.  So this sounds not very important
> to me, and the change, although simple, is not really trivial, and
> will affect any module.  So I'm uneasy putting this on emacs-26,
> especially since the Emacs 26.0.91 tarball is already ready and is
> awaiting upload, so this will only go into the next pretest, which I
> hoped could be a release candidate...
>
> Do you think leaving this for the next release will be so bad?
>

OK, pushed to master as  694ee38f8b.

I don't expect this bug to cause correctness problems, even with the
combination --without-threads --with-modules. The test is buggy, but it
will only cause false positives with --module-assertions. That's annoying,
but users can ignore these assertions. However, in the correct
implementation, in_current_thread is effectively always true if threads are
unavailable, so occasionally returning false is not a problem as far as
modules are concerned.

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

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 30106 <at> debbugs.gnu.org,
 Jean Louis <bugs <at> gnu.support>
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Thu, 18 Jan 2018 19:35:26 +0000

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

Glenn Morris <rgm <at> gnu.org> schrieb am Mo., 15. Jan. 2018 um 18:57 Uhr:

>
> It seems that Fmodule_load does not update load-history.
> This is causing Frequire to report the wrong file names in its error
> message, which is making it hard to diagnose the real problem.
>
>
>
>
Sigh, Fmodule_load has many other bugs, now that I look at it:
- It doesn't protect against recursive loads
- It doesn't print load messages even if force-load-messages is t
- It doesn't update loads-in-progress
- It doesn't do any of the other things that Fload does for .el and .elc
files
I think we should get rid of Fmodule_load entirely and add the
module-specific parts to Fload (the module initialization step itself
should stay in emacs-module.c though).

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

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

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: phst <at> google.com, p.stephani2 <at> gmail.com, 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: [PATCH 2/2] Fix module support if threads are disabled
 (Bug#30106)
Date: Thu, 18 Jan 2018 17:55:22 -0500

Eli Zaretskii wrote:

>> If it's not to be fixed then IMO in the meantime configure should
>> explicitly reject --with-modules if threads are disabled.
>
> That'd replace one non-trivial change with another, so I think it's
> worse than fixing the problem.

You think the following is non-trivial?

--- a/configure.ac
+++ b/configure.ac
@@ -3513,6 +3513,8 @@ case $opsys in
   *) MODULES_SUFFIX=".so" ;;
 esac
 if test "${with_modules}" != "no"; then
+  test "${threads_enabled}" = "no" && \
+    AC_MSG_ERROR([modules currently require threads])
   case $opsys in
     gnu|gnu-linux)
       LIBMODULES="-ldl"

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

From: Glenn Morris <rgm <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 30106 <at> debbugs.gnu.org,
 Jean Louis <bugs <at> gnu.support>
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Thu, 18 Jan 2018 18:00:03 -0500

Philipp Stephani wrote:

>> It seems that Fmodule_load does not update load-history.
>> This is causing Frequire to report the wrong file names in its error
>> message, which is making it hard to diagnose the real problem.

Sorry, I made a separate report for this before seeing your reply.
bug#30164

Message #132 received at 30106-done <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 30106-done <at> debbugs.gnu.org
Subject: Re: bug#30106: Loading file /sources/emacs/lisp/emacs-lisp/ert.elc
 failed to provide feature `mod-test'
Date: Thu, 18 Jan 2018 18:01:37 -0500

Jean Louis wrote:

> However, now at this point, but maybe after patching, I could compile
> it so that it works. I can load the dynamic module with (require 'pq)

Based on this comment I am closing this report.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: phst <at> google.com, p.stephani2 <at> gmail.com, 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: [PATCH 2/2] Fix module support if threads are disabled
 (Bug#30106)
Date: Fri, 19 Jan 2018 09:58:51 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: p.stephani2 <at> gmail.com,  phst <at> google.com,  30106 <at> debbugs.gnu.org
> Date: Thu, 18 Jan 2018 17:55:22 -0500
> 
> Eli Zaretskii wrote:
> 
> >> If it's not to be fixed then IMO in the meantime configure should
> >> explicitly reject --with-modules if threads are disabled.
> >
> > That'd replace one non-trivial change with another, so I think it's
> > worse than fixing the problem.
> 
> You think the following is non-trivial?

Yes, because it changes the configure script.  How do we know it won't
fail builds on some obscure platforms?

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

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: phst <at> google.com, p.stephani2 <at> gmail.com, 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: [PATCH 2/2] Fix module support if threads are disabled
 (Bug#30106)
Date: Sat, 20 Jan 2018 13:07:47 -0500

Eli Zaretskii wrote:

>> You think the following is non-trivial?
>
> Yes, because it changes the configure script.  How do we know it won't
> fail builds on some obscure platforms?

Basic common sense.

But don't worry, I've learnt that expressing my opinion is a waste of time.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: phst <at> google.com, p.stephani2 <at> gmail.com, 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: [PATCH 2/2] Fix module support if threads are disabled
 (Bug#30106)
Date: Sat, 20 Jan 2018 21:01:06 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: p.stephani2 <at> gmail.com,  phst <at> google.com,  30106 <at> debbugs.gnu.org
> Date: Sat, 20 Jan 2018 13:07:47 -0500
> 
> Eli Zaretskii wrote:
> 
> >> You think the following is non-trivial?
> >
> > Yes, because it changes the configure script.  How do we know it won't
> > fail builds on some obscure platforms?
> 
> Basic common sense.

I'm afraid that has failed us more than once in the past.

> But don't worry, I've learnt that expressing my opinion is a waste of time.

I value your opinions very much, I just don't always agree with them
(as you don't with mine).  I very much hope you don't decide to stop
voicing your opinions here.

Previous Next

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