Re: [cairo] gobject boxed types

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [cairo] gobject boxed types

Colin Walters
On Sat, Sep 13, 2008 at 1:12 PM, Vladimir Vukicevic <[hidden email]> wrote:
>
> Hmm.. my biggest problem with this is that it's essentially putting a
> language binding into Cairo -- a binding to the glib type system.  No other
> language binding is present inside Cairo.  However, I do understand that
> there are a lot of glib-using projects for which this would be beneficial.
>  Why not put this in an entirely separate (and simple) cairo-glib library?

Right; we can do that, the reason I wanted to try this first though is
because the cairo-glib library would right now be entirely composed of
six 4 line functions to register types.

On Sat, Sep 13, 2008 at 1:32 PM, Chris Wilson <[hidden email]> wrote:
>
> There's also been discussion about making gio-friendly streams interface
> for cairo which would seem to also belong in a cairo-glib. Then given
> such a library there is scope for including more cairo utility functions
> that are common to GLib/GObject based applications. For example, having
> a good region management library - i.e. move GdkRegion down the stack
> and improve its memory footprint. So I think the argument against adding
> another small library to the application stack is self-defeating.

(just saw this) Yes, that is a strong argument.  Ok.  Then I need to
build consensus the other way - make sure that the GObject projects
above cairo are ready to add another library dependency.  Pulling in
gtk-devel-list as hopefully the major stakeholders like GTK+,
GooCanvas, HippoCanvas, Clutter etc. are reading.

Actually I just had a random thought - what about putting this code
into pangocairo?  All of Gtk+, GooCanvas, HippoCanvas and Clutter
depend on Pango, and Pango depends on both cairo and gobject.  It's a
bit of an odd fit but the dependency graph would remain unchanged.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [cairo] gobject boxed types

Havoc Pennington-2
Hi,

On Sat, Sep 13, 2008 at 1:38 PM, Colin Walters <[hidden email]> wrote:
> Actually I just had a random thought - what about putting this code
> into pangocairo?  All of Gtk+, GooCanvas, HippoCanvas and Clutter
> depend on Pango, and Pango depends on both cairo and gobject.  It's a
> bit of an odd fit but the dependency graph would remain unchanged.

cairo-glib seems a bit like shooting a squirrel with a bazooka, in
terms of adding another tarball someone has to release and adding more
overhead to symbol lookups in all apps.

Stuffing in other libs seems more appropriate. If anyone ever
implements the GIO or GdkRegion stuff it could be in any of cairo,
pangocairo, or GDK and be fine in any of those places.

Or, here is the outrageous hack idea of the day: have a library that
consists only of get_type functions for *all* non-glib-dependent libs,
and it does dlopen(NULL) to grab the copy/free functions rather than
linking to any of the libs, throwing a runtime assertion if the app
doesn't link to the copy/free stuff that gets used ... throw this
library into the glib tarball ... it could deal with dbus in addition
to cairo ... scared yet?

Havoc
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [cairo] gobject boxed types

Bugzilla from ku.b@gmx.de
In reply to this post by Colin Walters
Am 13.09.08, 13:38 -0400 schrieb Colin Walters:

> On Sat, Sep 13, 2008 at 1:12 PM, Vladimir Vukicevic <[hidden email]> wrote:
> >
> > Hmm.. my biggest problem with this is that it's essentially putting a
> > language binding into Cairo -- a binding to the glib type system.  No other
> > language binding is present inside Cairo.  However, I do understand that
> > there are a lot of glib-using projects for which this would be beneficial.
> >  Why not put this in an entirely separate (and simple) cairo-glib library?
>
> Right; we can do that, the reason I wanted to try this first though is
> because the cairo-glib library would right now be entirely composed of
> six 4 line functions to register types.

Making each application, using Cairo, practical dependent to Glib, appears
not nice for non Gtk applications. A Cairo package would nearly always
depend on glib, which makes things like the before mentioned independence
and upgrading more complicated.
I'd agree, as a non core function this seems better exposed in a higher
layer.

kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [cairo] gobject boxed types

Havoc Pennington-2
In reply to this post by Havoc Pennington-2
Hi,

Johan suggested on IRC that the patch to cairo could be changed to use
dlopen to grab the copy/free functions lazily, to avoid a compile-time
dependency on glib (and also avoid a runtime dependency, if running in
an app that doesn't link to glib). It's still a hack, but a working
and maintainable one, and it doesn't imply a new module to maintain /
link to just for 4 trivial functions, and doesn't mess up the
dependency graph. The dlopen could be of NULL not libgobject.so
(assume the app has already loaded the library), so no tricky issues
about finding the thing to dlopen would arise.

I'd be willing to do something similar for DBUS_TYPE_CONNECTION, etc.
in libdbus, it seems like a decent solution in general.

Havoc
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [cairo] gobject boxed types

Colin Walters
On Sun, Sep 14, 2008 at 10:09 AM, Havoc Pennington <[hidden email]> wrote:

> Johan suggested on IRC that the patch to cairo could be changed to use
> dlopen to grab the copy/free functions lazily, to avoid a compile-time
> dependency on glib (and also avoid a runtime dependency, if running in
> an app that doesn't link to glib). It's still a hack, but a working
> and maintainable one, and it doesn't imply a new module to maintain /
> link to just for 4 trivial functions, and doesn't mess up the
> dependency graph.

Right, this was actually my first thought.  But it doesn't address
where GIO+cairo using functions would land.  I'm not sure how
important those are - maybe we could put those in Pango.

> I'd be willing to do something similar for DBUS_TYPE_CONNECTION, etc.
> in libdbus, it seems like a decent solution in general.

Yeah, though dbus is special enough that it cries out for completely
custom language bindings, and it doesn't tend to be exposed by other
libraries (by signals, methods etc.), with the notable exception of
Telepathy*.

Any opinion from the GObject side on the option of putting them in
Pango?  We already have things like a PangoCairoFont GInterface in
there.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [cairo] gobject boxed types

Bugzilla from vladimir@pobox.com
In reply to this post by Havoc Pennington-2

On Sep 14, 2008, at 7:09 AM, Havoc Pennington wrote:

> Hi,
>
> Johan suggested on IRC that the patch to cairo could be changed to use
> dlopen to grab the copy/free functions lazily, to avoid a compile-time
> dependency on glib (and also avoid a runtime dependency, if running in
> an app that doesn't link to glib). It's still a hack, but a working
> and maintainable one, and it doesn't imply a new module to maintain /
> link to just for 4 trivial functions, and doesn't mess up the
> dependency graph. The dlopen could be of NULL not libgobject.so
> (assume the app has already loaded the library), so no tricky issues
> about finding the thing to dlopen would arise.

I don't understand the concern about "doesn't mess up the dependency  
graph" -- there are already a dozen libraries that get linked to any  
glib-using app -- why does one more hurt, especially when it would be  
a natural place for other things to go?  (e.g. the GdkRegion stuff  
that was mentioned earlier)

     - Vlad

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [cairo] gobject boxed types

Behdad Esfahbod-3
In reply to this post by Colin Walters
Colin Walters wrote:

> Here is a patch, should apply to the latest git.

I also like to see gobject enum types for cairo.

Also, should the type names be CairoContext-like or simply cairo_t?  If this
is going to be used by introspection stuff, CairoContext sounds correct.

Vladimir Vukicevic wrote:

> Hmm.. my biggest problem with this is that it's essentially putting a
> language binding into Cairo -- a binding to the glib type system.  No
> other language binding is present inside Cairo.  However, I do
> understand that there are a lot of glib-using projects for which this
> would be beneficial.  Why not put this in an entirely separate (and
> simple) cairo-glib library?  That gives glib-using projects something
> clear to link with, and it avoids the dependency problems that Luiz
> and others have mentioned.

Another pro argument here is that glib bindings like the one proposed are
meta-bindings, enabling automatic binding of cairo types to various languages.

As it stands [1], the proposed cairo-glib feature/library may also include
typelib data needed for glib introspection framework to automatically bind
cairo to supporting languages.  That saves quite some work of writing manual
bindings for cairo which is the case now.

[1] http://live.gnome.org/GObjectIntrospection/CairoProblem

Colin Walters wrote:

> Right; we can do that, the reason I wanted to try this first though is
> because the cairo-glib library would right now be entirely composed of
> six 4 line functions to register types.

It will quickly grow into two digit numbers, but I expect it to stay very low
at that.

> Actually I just had a random thought - what about putting this code
> into pangocairo?  All of Gtk+, GooCanvas, HippoCanvas and Clutter
> depend on Pango, and Pango depends on both cairo and gobject.  It's a
> bit of an odd fit but the dependency graph would remain unchanged.

I had thought about that before [2].  I religiously hate that solution.  So
that's not gonna happen :).

[2] http://bugzilla.gnome.org/show_bug.cgi?id=502920

Havoc Pennington wrote:

> cairo-glib seems a bit like shooting a squirrel with a bazooka, in
> terms of adding another tarball someone has to release and adding more
> overhead to symbol lookups in all apps.

libcairo-glib.so can be installed from the cairo tarball.  Separate library
doesn't mean separate tarball.  I'm in favor of this solution right now.
Remains a penalty of one dirty page per process of course.

> Or, here is the outrageous hack idea of the day: have a library that
> consists only of get_type functions for *all* non-glib-dependent libs,
> and it does dlopen(NULL) to grab the copy/free functions rather than
> linking to any of the libs, throwing a runtime assertion if the app
> doesn't link to the copy/free stuff that gets used ... throw this
> library into the glib tarball ... it could deal with dbus in addition
> to cairo ... scared yet?

Nah, imagine adding a new enum value in cairo and the pain it would be to go
update that binding library which should still be able to build against older
cairo too.

Havoc Pennington wrote:

> Johan suggested on IRC that the patch to cairo could be changed to use
> dlopen to grab the copy/free functions lazily, to avoid a compile-time
> dependency on glib (and also avoid a runtime dependency, if running in
> an app that doesn't link to glib). It's still a hack, but a working
> and maintainable one, and it doesn't imply a new module to maintain /
> link to just for 4 trivial functions, and doesn't mess up the
> dependency graph. The dlopen could be of NULL not libgobject.so
> (assume the app has already loaded the library), so no tricky issues
> about finding the thing to dlopen would arise.

No dlopen in cairo please.  We'll either link to glib from libcairo.so or
libcairo-glib.so.

Colin Walters wrote:

> Right, this was actually my first thought.  But it doesn't address
> where GIO+cairo using functions would land.  I'm not sure how
> important those are - maybe we could put those in Pango.

The GIO+cairo callbacks can actually go in gio, but cairo-glib is a better
place indeed.

> Any opinion from the GObject side on the option of putting them in
> Pango?  We already have things like a PangoCairoFont GInterface in
> there.

PangoCairoFont is a pangocairo-specific thing.  I hate adding non-pango bits
in pangocairo just for the sake of dep tree.

Kai-Uwe Behrmann wrote:

> Making each application, using Cairo, practical dependent to Glib, appears
> not nice for non Gtk applications. A Cairo package would nearly always
> depend on glib, which makes things like the before mentioned independence
> and upgrading more complicated.

I don't get the logic here at all.  If your distribution decides to build
their cairo with glib, just let them deal with it.  It causes no problem for a
cairo user.

Craig Bradney wrote:

> 100% agree - please keep direct glib dependencies out of the main cairo
> library.

I won't call a compile-time opt-in dependency a "direct glib dependencies".

Chris Wilson wrote:

> There's also been discussion about making gio-friendly streams interface
> for cairo which would seem to also belong in a cairo-glib. Then given
> such a library there is scope for including more cairo utility functions
> that are common to GLib/GObject based applications. For example, having
> a good region management library - i.e. move GdkRegion down the stack
> and improve its memory footprint. So I think the argument against adding
> another small library to the application stack is self-defeating.

Can you elaborate?  The idea for having a lower-level region code was to reuse
it in pixman, cairo, xorg, and gdk.  putting it in cairo-glib solves none of
that problem.


I'm probably make it a separate .so.  The intereface to use it is no different
than having it in cairo.so.  One simply brings in cairo-glib pkg-config
dependencies.  Where the actual code lives is implementation details.  Any
objections to that?

Has to wait till after 1.8 at this point though....

behdad
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [cairo] gobject boxed types

Damian Frank
On Sun, Sep 14, 2008 at 11:49 PM, Behdad Esfahbod <[hidden email]> wrote:
> Kai-Uwe Behrmann wrote:
>> Making each application, using Cairo, practical dependent to Glib, appears
>> not nice for non Gtk applications. A Cairo package would nearly always
>> depend on glib, which makes things like the before mentioned independence
>> and upgrading more complicated.
>
> I don't get the logic here at all.  If your distribution decides to build
> their cairo with glib, just let them deal with it.  It causes no problem for a
> cairo user.

Sorry for the massive quote.  I'd like to chime in here that adding a
glib compile dependency to Cairo will seriously complicate the lives
of people like me and my colleagues who are building cairo libs
ourselves on Windows, Mac, and Linux, and adding a glib compilation
dependency seriously complicates building on Windows and Mac.

I guess I'd be satisfied if the glib dependency were easily disabled
on the configure line on Mac and Linux, and off by default in
Makefile.win32.  To be honest, though, glib dependencies scare me.  I
like to know what my software is pulling in and using when I'm writing
the code, and I really like how contained cairo's dependencies are.
Adding even a soft glib dependency kind of threatens that beautiful
simplicity, since GNOME is such a hulking mass of interdependencies.

Personally, I like the idea of adding it as an outboard library, with
its own build scripts.

Damian
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [cairo] gobject boxed types

Alexander Larsson
In reply to this post by Havoc Pennington-2
On Sat, 2008-09-13 at 15:05 -0400, Havoc Pennington wrote:

> Hi,
>
> On Sat, Sep 13, 2008 at 1:38 PM, Colin Walters <[hidden email]> wrote:
> > Actually I just had a random thought - what about putting this code
> > into pangocairo?  All of Gtk+, GooCanvas, HippoCanvas and Clutter
> > depend on Pango, and Pango depends on both cairo and gobject.  It's a
> > bit of an odd fit but the dependency graph would remain unchanged.
>
> cairo-glib seems a bit like shooting a squirrel with a bazooka, in
> terms of adding another tarball someone has to release and adding more
> overhead to symbol lookups in all apps.

If you dlopen cairo-glib and use RTLD_LOCAL I think you avoid the symbol
lookup overhead. Maybe this is useful?


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [cairo] gobject boxed types

Havoc Pennington-2
In reply to this post by Bugzilla from vladimir@pobox.com
Hi,

On Sun, Sep 14, 2008 at 9:45 PM, Vladimir Vukicevic <[hidden email]> wrote:
> I don't understand the concern about "doesn't mess up the dependency graph"
> -- there are already a dozen libraries that get linked to any glib-using app
> -- why does one more hurt, especially when it would be a natural place for
> other things to go?  (e.g. the GdkRegion stuff that was mentioned earlier)
>

I think I meant stuffing it in Pango would mess up the dependency
graph, while cairo-glib adds bloat / maintenance headache. The extra
tarball is definitely the worst of cairo-glib though, so if that is
avoided, I guess slowing down every symbol lookup is a slippery slope
we're already well down in most apps.

Havoc
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [cairo] gobject boxed types

Johan Dahlin
In reply to this post by Behdad Esfahbod-3
Behdad Esfahbod wrote:
> Colin Walters wrote:
>
>> Here is a patch, should apply to the latest git.
>
> I also like to see gobject enum types for cairo.
>
> Also, should the type names be CairoContext-like or simply cairo_t?  If this
> is going to be used by introspection stuff, CairoContext sounds correct.

Cairo.Context is correct, if we include the namespacing.

> Another pro argument here is that glib bindings like the one proposed are
> meta-bindings, enabling automatic binding of cairo types to various languages.
>
> As it stands [1], the proposed cairo-glib feature/library may also include
> typelib data needed for glib introspection framework to automatically bind
> cairo to supporting languages.  That saves quite some work of writing manual
> bindings for cairo which is the case now.
>
> [1] http://live.gnome.org/GObjectIntrospection/CairoProblem

The GObjectIntrospection framework provides an XML format description of the
API which is independent of gobject itself, that could be distributed/used
outside of the glib bindings.

We also have typelib which /is/ dependent on glib, that should obviously go
with the rest of the cairo-glib stuff.

> I'm probably make it a separate .so.  The intereface to use it is no different
> than having it in cairo.so.  One simply brings in cairo-glib pkg-config
> dependencies.  Where the actual code lives is implementation details.  Any
> objections to that?
>
> Has to wait till after 1.8 at this point though....

This sounds perfectly fine to me.
It'll be trivial for gobject based applications to use cairo-glib instead of
cairo in their configure/makefile.

Johan
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [cairo] gobject boxed types

Bugzilla from ku.b@gmx.de
In reply to this post by Alexander Larsson
Am 15.09.08, 13:46 +0200 schrieb Alexander Larsson:

> On Sat, 2008-09-13 at 15:05 -0400, Havoc Pennington wrote:
> > Hi,
> >
> > On Sat, Sep 13, 2008 at 1:38 PM, Colin Walters <[hidden email]> wrote:
> > > Actually I just had a random thought - what about putting this code
> > > into pangocairo?  All of Gtk+, GooCanvas, HippoCanvas and Clutter
> > > depend on Pango, and Pango depends on both cairo and gobject.  It's a
> > > bit of an odd fit but the dependency graph would remain unchanged.
> >
> > cairo-glib seems a bit like shooting a squirrel with a bazooka, in
> > terms of adding another tarball someone has to release and adding more
> > overhead to symbol lookups in all apps.
>
> If you dlopen cairo-glib and use RTLD_LOCAL I think you avoid the symbol
> lookup overhead. Maybe this is useful?

Interessting. How portable is this, e.g. win32?

kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [cairo] gobject boxed types

Mathieu Lacage

On Tue, 2008-09-16 at 05:55 +0200, Kai-Uwe Behrmann wrote:

> Am 15.09.08, 13:46 +0200 schrieb Alexander Larsson:
> > On Sat, 2008-09-13 at 15:05 -0400, Havoc Pennington wrote:
> > > Hi,
> > >
> > > On Sat, Sep 13, 2008 at 1:38 PM, Colin Walters <[hidden email]> wrote:
> > > > Actually I just had a random thought - what about putting this code
> > > > into pangocairo?  All of Gtk+, GooCanvas, HippoCanvas and Clutter
> > > > depend on Pango, and Pango depends on both cairo and gobject.  It's a
> > > > bit of an odd fit but the dependency graph would remain unchanged.
> > >
> > > cairo-glib seems a bit like shooting a squirrel with a bazooka, in
> > > terms of adding another tarball someone has to release and adding more
> > > overhead to symbol lookups in all apps.
> >
> > If you dlopen cairo-glib and use RTLD_LOCAL I think you avoid the symbol
> > lookup overhead. Maybe this is useful?
>
> Interessting. How portable is this, e.g. win32?

win32 does not have stupid elf symbol lookup rules so, the problem this
trick solves does not exist on win32.

Mathieu

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [cairo] gobject boxed types

Havoc Pennington-2
In reply to this post by Alexander Larsson
Hi,

On Mon, Sep 15, 2008 at 7:46 AM, Alexander Larsson <[hidden email]> wrote:
> If you dlopen cairo-glib and use RTLD_LOCAL I think you avoid the symbol
> lookup overhead. Maybe this is useful?
>

It breaks to RTLD_LOCAL something that's also linked to, since you get
two copies of the lib (two copies of static variables for example) - I
think anyway. So RTLD_LOCAL is only usable for true plugins/modules.

Havoc
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [cairo] gobject boxed types

Mathieu Lacage

On Tue, 2008-09-16 at 15:45 -0400, Havoc Pennington wrote:

> Hi,
>
> On Mon, Sep 15, 2008 at 7:46 AM, Alexander Larsson <[hidden email]> wrote:
> > If you dlopen cairo-glib and use RTLD_LOCAL I think you avoid the symbol
> > lookup overhead. Maybe this is useful?
> >
>
> It breaks to RTLD_LOCAL something that's also linked to, since you get
> two copies of the lib (two copies of static variables for example) - I
> think anyway. So RTLD_LOCAL is only usable for true plugins/modules.

RTLD_LOCAL will not reload the library if it has been loaded already. If
the library has already been loaded _without_ RTLD_LOCAL (most likely,
you linked against it explicitely), then, RTLD_LOCAL is ignored, no
error is reported and the loader will return a handle to the
previously-loaded library (it increments its refcount) whose symbols are
RTLD_GLOBAL.

Mathieu

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [cairo] gobject boxed types

Mathieu Lacage

On Tue, 2008-09-16 at 13:56 -0700, Mathieu Lacage wrote:

> On Tue, 2008-09-16 at 15:45 -0400, Havoc Pennington wrote:
> > Hi,
> >
> > On Mon, Sep 15, 2008 at 7:46 AM, Alexander Larsson <[hidden email]> wrote:
> > > If you dlopen cairo-glib and use RTLD_LOCAL I think you avoid the symbol
> > > lookup overhead. Maybe this is useful?
> > >
> >
> > It breaks to RTLD_LOCAL something that's also linked to, since you get
> > two copies of the lib (two copies of static variables for example) - I
> > think anyway. So RTLD_LOCAL is only usable for true plugins/modules.
>
> RTLD_LOCAL will not reload the library if it has been loaded already. If
> the library has already been loaded _without_ RTLD_LOCAL (most likely,
> you linked against it explicitely), then, RTLD_LOCAL is ignored, no
> error is reported and the loader will return a handle to the
> previously-loaded library (it increments its refcount) whose symbols are
> RTLD_GLOBAL.

I should have pointed out that the converse is not true. i.e., it is
possible to open a library with RTLD_LOCAL first and promote that to
RTLD_GLOBAL by re-dl_opening it with the RTLD_GLOBAL switch (but once it
is done, you can't go back to RTLD_LOCAL).

This is a bit OT though.

Mathieu

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [cairo] gobject boxed types

Colin Walters
In reply to this post by Behdad Esfahbod-3
On Mon, Sep 15, 2008 at 12:49 AM, Behdad Esfahbod <[hidden email]> wrote:
>
> I'm probably make it a separate .so.  The intereface to use it is no different
> than having it in cairo.so.  One simply brings in cairo-glib pkg-config
> dependencies.  Where the actual code lives is implementation details.  Any
> objections to that?

Ok, so the conclusion is a separate .so currently planned to be built
from the cairo tarball?  Sounds reasonable.  Behdad, since you know
the Cairo build system well do you think you might be able to massage
my patch into a separate .so?
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [cairo] gobject boxed types

Behdad Esfahbod-3
Colin Walters wrote:

> On Mon, Sep 15, 2008 at 12:49 AM, Behdad Esfahbod <[hidden email]> wrote:
>> I'm probably make it a separate .so.  The intereface to use it is no different
>> than having it in cairo.so.  One simply brings in cairo-glib pkg-config
>> dependencies.  Where the actual code lives is implementation details.  Any
>> objections to that?
>
> Ok, so the conclusion is a separate .so currently planned to be built
> from the cairo tarball?  Sounds reasonable.  Behdad, since you know
> the Cairo build system well do you think you might be able to massage
> my patch into a separate .so?

I need to extend the build system for that.  Will do post 1.8.  In the mean
time, patch for generating enum times is appreciated.

behdad

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list