similar to: RTLD_GLOBAL flag for dlopen

Hi, Today, I've made the transition from LLVM 2.1 to 2.3. I invoke opt with two dynamic libraries to "-load", the first of which contains transformation passes and support code whereas the second one provides extra passes which make use of the first library's support code. In other words, the symbols loaded in for the first library should be available when the second

On Wed, 9 Jul 2008, Bram Adams wrote: > Today, I've made the transition from LLVM 2.1 to 2.3. I invoke opt > with two dynamic libraries to "-load", the first of which contains > transformation passes and support code whereas the second one provides > extra passes which make use of the first library's support code. In > other words, the symbols loaded in for the

All, I use a code which has a python (I use python36) wrapper loading shared libraries. The code worked fine in RHEL 7 but as I was testing it on Centos 8, python cannot import the shared library (the import is done via dlopen with flags set as > sys.setdlopenflags(os.RTLD_LAZY | os.RTLD_GLOBAL) python then does a bunch of imports and most results in a shared library with indefined

Attached is a quick patch which adds a logging framework to compiz. I think it should be fairly self explanitory. I think it should allow plugin writers to extend it for any purpose, but I would appreciate any feedback or comments before going any further. Regards Mike -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: logging.diff Url:

Here is my python loader plugin which loads plain python scripts as full plugins. There is not much documentation, but I have included a few examples to get you going. triangle - Just a basic plugin which shows a triangle on a button press. This shows using ctypes to pass values from compiz to the python opengl bindings. basiczoom - Zooms in on the screen (basically) inactive - This is a port

I've started work on a rewrite of sorts for the dbus plugin that changes how it listens/responds to messages to make it possible to generate introspection data. The main changes are registering every plugin, screen, option, etc with dbus_connection_register_object_path and using libxml2 to generate the introspection data. This more or less works I just need to hook up the rest of the methods

Hi everyone, Some of you probably received the following thread from the Rcpp-devel mailing list: http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2018-August/010072.html Summing up, the issue described is the following: pkg1 provides type1 in pkg1.so building on some headers. pkg2 links to pkg1 (BTW, LinkingTo is actually misleading, because it doesn't really link to it), i.e.,

I have written an initial flat file configuration backend for Compiz. At the moment it is using FAM for monitoring of files (it can be compiled without monitoring support for now). It is working fine but there are a couple of problems. 1. It looks like I should use addFileWatch rather than directly accessing FAM, is this correct? I notice dbus uses addFileWatch rather than

I have downloaded compiz-0.2.0 and tried to compile it. The INSTALL file talks about autgen.sh, but I am unable to locate it. I tried ./configure but it complains about a number of missing packages. Is there any docs on how to compile compiz on SLED 10 ? I have searched in a lot of places, but have not been able to dig up anything. A detailed list of what packages is required (and where to locate

Thomas Lumley writes: > > > I've been trying to get Matt Calder's S compiler to work in R using R > COMPILE and R SHLIB so it will be fairly platform-independent. > > I'm sure someone has claimed in the past that it is possible/easy to > dyn.load() two dynamic libraries and have one call functions in the other. > I can't get it to work (Red Hat

I was writing a simple plugin a while ago which just sets the paint values on inactive windows. The plugin is very simple and the main part is below. When I load this plugin it blocks dbus and fuse plugins so that they only reply to requests when the active window changes. Is there anything obvious here that would cause that? static Bool inactivePaintWindow (CompWindow *w, const

Hi, some of you might noticed that there was recently some discussion on the Beryl ML about an interface which provides sharing functions and allows us to do library plugins. One example for this kind of plugins is text, which was recently ported to that system. I now want to explain here how it works in general. Core does save the shared library functions in a CompLibraryFunction struct: struct

I seem to be having problems with the latest dbus code. Here is a backtrace. This is happening at startup. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47449612229888 (LWP 28353)] 0x00002b27b87991c0 in strlen () from /lib/libc.so.6 (gdb) bt #0 0x00002b27b87991c0 in strlen () from /lib/libc.so.6 #1 0x00002aaaac1b0657 in dbus_watch_handle () from

hi, I saw that Mike Dransfield tried to port 'state' plugin from beryl. What does it do? It should be able to place windows, based on name, class etc., to specific viewports. I recently converted to compiz window manager from WindowMaker (used it for 8 years), and I miss automatic 'pinning' of specific windows to particular workspace (or viewport in this case). Mike's

Hi, well after some ever further investigation of some bugs, I ended up cleaning up the code, again. I also fixed some really heavy memory leaks in csvToList and made it in general more stable. Regards, Patrick "Marex" Niklaus -------------- next part -------------- A non-text attachment was scrubbed... Name: ini.c.patch Type: text/x-patch Size: 8275 bytes Desc: not available Url :

For some reason all mozilla and open office menus are Normal type. This causes problems with all plugins which use the window type. This patch is applied to all plugins and seems to work flawlessly. I am submitting it for blur because the first window of all firefox menus are blurred. I know its a hack, but at least it should be fairly harmless inside each plugin. It is always marked with

It seems to me that the plugin dependencies are not flexible enough for most plugins. The particular problem I am thinking about is animation/group and fade. They both specify RuleAfter but compiz interprets that as 'load after AND require it', there is a Require rule, but this relates to features not plugins. I would like to propose these changes and definitions, they seem more logical

My recent work on Compiz-scheme has brought to my attention several problems preventing a real compiz extension language. Note that when I refer to an extension language, I am not referring to the ability to add plugins in some other languages, but more of something in the vein of emacs lisp. The major problem right now is extension languages are locked in to one plugin and what core exposes.

Hi, I am trying to compile a dynamic loader using LLVM. Part of the IR for this loader looks like this: @_rtld_local = hidden alias %struct.rtld_global* @_rtld_global @_rtld_global = unnamed_addr global %struct.rtld_global { ... } The purpose of _rtld_local is to allow _rtld_global to be referenced without using the GOT, as this global is accessed before the dynamic loader initialises the GOT.

On Mon, Oct 22, 2012 at 11:40:32AM -0700, Nick Kledzik wrote: > > On Oct 22, 2012, at 11:34 AM, Jack Howarth wrote: > > > Nick, > > I have uploaded the full walk with 'set env DYLD_PRINT_INITIALIZERS'. It didn't seem very informative > > as the dyld error occurs right after... > > > > (gdb) > >