Re: emacs25 dynamic module dlopen flags

[Philipp Stephani]

hx <address@hidden> schrieb am Di., 13. Sep. 2016 um 10:45 Uhr:

On Tue, Sep 13, 2016 at 2:25 PM, Philipp Stephani <address@hidden> wrote:

hx <address@hidden> schrieb am Di., 13. Sep. 2016 um 02:17 Uhr:

current dlopen flag is RTLD_LAZY,

//src/dynlib.c

dynlib_handle_ptr
dynlib_open (const char *path)
{
  return dlopen (path, RTLD_LAZY);
}

my module will also load other shared libs, I got some error like symbol undefined,

I found this article http://www.perlmonks.org/?node_id=673396 ,

after I changed dlopen flags to RTLD_LAZY|RTLD_GLOBAL in src/dynlib.c, the problem is solved.

could emacs developer consider to add the RTLD_GLOBAL flag in emacs's source code ?

Reading the manpage of dlopen, I don't think this flag should be added. Emacs modules should typically export only two symbols (plugin_is_GPL_compatible and emacs_module_init), which aren't useful outside Emacs.

 

thanks for your reply,

here is the detail: 

my emacs module linked with libperl.so, 

when perl interpreter in the module execute some scripts, it may load other .so files depending on which perl package is going to be loaded,

for example, DBD::mysql will load DBD/mysql/mysql.so, Socket will load Socket.so,

without that flag, loading Socket.so will fail, the error message is like Socket.so can't find some symbols from libperl.so .

it may look like the problem is in libperl.so,

but if I add RTLD_GLOBAL in emacs/src/dynlib.c, Socket.so will be loaded successful,

if modify my module code and compile it as a standalone application, still do same process(create perl interpreter and execute perl script), it also can load Socket.pm and Socket.so.

so I think lack of RTLD_GLOBAL in emacs stops libperl.so loading Socket.so .

# nm -a mymodule.so |grep PL_thr

         U PL_thr_key

I did see error message complain symbol PL_thr_key is undefined when loading other perl *.so.

Unfortunately I know too little about shared objects to provide an authoritative answer, but IIUC plugin systems should always use RTLD_LOCAL so that separate plugins can define the same symbols without interfering with each other. But a person who is more knowledgeable about shared object should probably comment.