After updating glib from git master today I can no longer build with
MSVC. The build now fails to link because gio makes a call to
'g_openuri_portal_open_uri_finish()' (in function
'g_app_info_launch_default_for_uri_finish()')
Looking around at similar calls, I reckon the function should
On 28/05/2017 14:41, Sébastien Wilmet wrote:
On Wed, Apr 19, 2017 at 09:02:21AM +0100, John Emmas via gtk-devel-list wrote:
the following 11 header files stipulate GPL:-
gbase64.h
gbookmarkfile.h
gchecksum.h
ghmac.h
glib-private.h
glib-unix.h
Hi guys - whilst checking something else this morning I came across an
anomaly in the licensing mechanism for glib / gtk+ etc.
The vast majority of the header files state that it's LGPL. But
occasionally there are GPL headers here and there. For example in
glib-2, the following 11 header
On 17/04/2017 12:16, John Emmas via gtk-devel-list wrote:
my VS8 projects seem to use ".symbols" files for determining what gets
exported from the built DLLs. I can't remember why I needed to do
that but I probably just need to amend them - or hopefully find a way
to stop usin
On 17/04/2017 11:25, Emmanuele Bassi wrote:
Should I transfer this discussion to bugzilla here:-
https://bugzilla.gnome.org/show_bug.cgi?id=780634
Please, do, detailing how you build GLib.
Okay - just before I do that though, a bit more investigation might have
revealed the problem...
On 16/04/2017 19:25, Sébastien Wilmet wrote:
It's a GObject Introspection annotation !!!
https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations
Thanks Sébastien,
I can't claim to understand it all but it seems like GObject
Introspection is a way of compiling modules with one
All of a sudden I've hit a problem when building glib with MSVC. It
seems to be affecting calls to g_mkstemp() / g_getenv() and various
others. Let's take g_mkstemp() as an example. It gets called in
glib-genmarshal.c
Prior to commit #d1528402, git master had some lines looking like this
On 05/02/2017 03:59, Yale Zhang wrote:
I suggest adding a lrintf() fallback to fallback-c89.c too.
Currently, there are 2 rounding functions in the fall backs, round()
and rint()
Where does fallback-c89.c come from? Some auto-generated file maybe?
I can't seem to find it on my system :-(
On 4 Feb 2017, at 19:44, Emmanuele Bassi wrote:
>
> Please, file a bug against gdk-pixbuf:
>
> https://bugzilla.gnome.org/enter_bug.cgi?product=gdk-pixbuf
>
> I'd rather have a check at configure-time that looks if we have
> lrint() available, and if not, provides a fallback. We used this
>
On 04/02/2017 16:07, Martin Guy wrote:
On 04/02/2017, John Emmas via gtk-devel-list <gtk-devel-list@gnome.org> wrote:
I took a quick look through glib, gtk+ (v2) and gdk-pixbuf but I
can't see lrint getting used anywhere else. Any chance of a fix?
Thanks. The quick fix is to replac
Is this the right mailing list for gdk-pixbuf issues?
Commit #61e3edeb79 (6th Jan 2017) introduced these 2 calls in
'gdk-pixbuf/pixops/pixops.c' (at lines 1847 and 1848):-
tmp_width = lrint (src_width * prescale_x);
tmp_height = lrint (src_height * prescale_y);
AFAIK Microsoft's MSVC
Is it permissiable to #include in client code?
Here's the scenario (I discovered this in gtk-2-24 so apologies if it's
been fixed in a more recent version...)
'gdk/gdkwin32.h' declares some functions, including
gdk_win32_drawable_get_handle(). It isn't declared anywhere else AFAICT
and
12 matches
Mail list logo
