search for: rtld_local

...ways use strcmp of the typeinfo names: > > https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=149964 > > Should we do the same with libc++? No. It pessimizes correctly behaving code to work around code that violates the ELF ABI. Consider an application that loads plugins with RTLD_LOCAL. Two plugins implement a (hidden) type called "Plugin". The GCC change now makes this completely separate types identical for all RTTI purposes. That makes no sense at all. Joerg

...cation 'Wait' [WaitExten] == Registered application 'WaitExten' Asterisk Dynamic Loader Starting: == Parsing '/etc/asterisk/modules.conf': Found [res_musiconhold.so]Apr 20 08:27:58 WARNING[13559]: loader.c:726 __load_resource: new style res_musiconhold.so (0x30) loaded RTLD_LOCAL => (Music On Hold Resource) == Registered application 'MusicOnHold' == Registered application 'WaitMusicOnHold' == Registered application 'SetMusicOnHold' == Registered application 'StartMusicOnHold' == Registered application 'StopMusicOnHold'...

...cation 'Wait' [WaitExten] == Registered application 'WaitExten' Asterisk Dynamic Loader Starting: == Parsing '/etc/asterisk/modules.conf': Found [res_musiconhold.so]Apr 20 08:27:58 WARNING[13559]: loader.c:726 __load_resource: new style res_musiconhold.so (0x30) loaded RTLD_LOCAL => (Music On Hold Resource) == Registered application 'MusicOnHold' == Registered application 'WaitMusicOnHold' == Registered application 'SetMusicOnHold' == Registered application 'StartMusicOnHold' == Registered application 'StopMusicOnHold'...

...to 10 and Asterisk to trunk and now after deleting all modules and previously compiled stuff and recompiling asterisk, zaptel, and libpri, I get this failure of asterisk to start: [pbx_realtime.so]Apr 25 03:36:41 WARNING[8269]: loader.c:726 __load_resource: new style pbx_realtime.so (0x31) loaded RTLD_LOCAL => (Realtime Switch) [chan_mgcp.so]Apr 25 03:36:41 WARNING[8269]: loader.c:726 __load_resource: new style chan_mgcp.so (0x1) loaded RTLD_LOCAL => (Media Gateway Control Protocol (MGCP)) == Parsing '/etc/asterisk/mgcp.conf': Found == MGCP Listening on 0.0.0.0:2727 == Using TOS...

I've just upgrade to the latest head (20843) and I get the following error .Apr 17 08:41:07 WARNING[8527]: loader.c:726 __load_resource: new style cdr_pgsql.so (0x0) loaded RTLD_LOCAL Apr 17 08:41:07 WARNING[8527]: loader.c:744 __load_resource: Key routine returned NULL in module /usr/lib/asterisk/modules/cdr_pgsql.so Apr 17 08:41:07 WARNING[8527]: loader.c:753 __load_resource: 5 errors loading module /usr/lib/asterisk/modules/cdr_pgsql.so, aborted Apr 17 08:41:07 WARNING[8527...

...other threads so R_init_XXXXX goes on? If some function of my extension library is called it can call R_CheckUserInterrupt() if and while the threads do not end. If such use of threads is safe inside R, is there a package that does it? Any tips? Flags currently sent to dlopen are (RTLD_LAZY | RTLD_LOCAL). Revolving the R sources could not find the flags R uses. Does any of you know for sure the flags used to load extensions with loadLibrary()? Looking into computeDLOpenFlag() did not answer the question. Is there a recommended flags set in this situation? Aparently dlopen() flags LM_ID_BASE a...

Hello, I have a probleme with the dynamic loading. I make two librairies "myfct.so" and "otherfct.so", where "myfct.so" is calling functions of "otherfct.so", and I want dyn.load() each of it, without generating a unique librarie. For exemple : myfct.c : void myfct(double *x, double *y) { otherfct(x); *y=(*x)+1.0; } myoth.c : void otherfct( double *x

...pe1 is exactly the same in pkg1.so and pkg2.so. *But* UBSAN sanitizers give a runtime error, which arguably is a false positive. Real example on CRAN: https://www.stats.ox.ac.uk/pub/bdr/memtests/gcc-UBSAN/ldat/ldat-Ex.Rout A solution to this would be to dlopen pkg1.so with RTLD_GLOBAL, instead of RTLD_LOCAL, i.e., dyn.load(local=FALSE). So my proposal is to automatically set RTLD_GLOBAL for those packages that are listed at the same time in Depends/Imports/Suggests and LinkingTo, at least for those machines on CRAN running UBSAN tests. Regards, -- I?aki Ucar

Hello there, tl;dr: Is it a known behaviour that using llvm-3.4 and llvm-3.6 at the same time in the same process (while llvm-3.6 is used from a linked shared library and llvm-3.4 is dlopen'ed - with a strange detail: Especially if -rdynamic is used when linking the program). If so, is there a workaround? If not, can it be fixed in llvm-3.6? Long story: I am writing a program that creates

Greetings, Peter Ross! > problem solved but part of the mystery remains: > It has to do with the root shell!! Oh? I'm no expert, but I could probably explain it. If you're using statically linked shell (busybox comes to mind), you are locked to whatever libs have been linked in at the compile time. Also re: your previous wonder about library name, it may differ between

[Was initially posted on cfe-users, sorry.] Hi, I'm sorry my message is quite long, the TL;DR version is "g++ and clang++ seem to have different opinions on how RTTI, templates, and ELF visibility should interact". I can't tell whether this is a bug or not: I have found no relevant documentation that could help me decide whether this behavior is meant, or not. All I can say