add_color_stop_rgba doesn't exist?

[spotaws]

First off, thank you for your project. I came here as part of the effort to migrate Fedora's lua to 5.5 and I'm grateful for all the work you've done in your fork/modernization of lgi. Fedora has lua-lgi but only as a dependency of awesome (a lua window manager). I modified awesome to replace all the lgi calls with LuaGObject calls and then I ran into this oddity:

Error:
/usr/bin/lua: /home/spot/git/sandbox/lua55/awesome/awesome-4.3-build/awesome-73b20cc3eca34c0dbe40e7798f469e1df787f44d/lib/gears/color.lua:170: cairo.Pattern: no `add_color_stop_rgba'
stack traceback:
[C]: in upvalue 'error'
/usr/share/lua/5.5/LuaGObject/component.lua:141: in function </usr/share/lua/5.5/LuaGObject/component.lua:137>
[C]: in metamethod 'index'
/home/spot/git/sandbox/lua55/awesome/awesome-4.3-build/awesome-73b20cc3eca34c0dbe40e7798f469e1df787f44d/lib/gears/color.lua:170: in upvalue 'add_stops_table'
/home/spot/git/sandbox/lua55/awesome/awesome-4.3-build/awesome-73b20cc3eca34c0dbe40e7798f469e1df787f44d/lib/gears/color.lua:212: in function 'gears.color.create_linear_pattern'
(...tail calls...)
/home/spot/git/sandbox/lua55/awesome/awesome-4.3-build/awesome-73b20cc3eca34c0dbe40e7798f469e1df787f44d/lib/wibox/widget/graph.lua:333: in local 'build_fallback_nan_color'
/home/spot/git/sandbox/lua55/awesome/awesome-4.3-build/awesome-73b20cc3eca34c0dbe40e7798f469e1df787f44d/lib/wibox/widget/graph.lua:349: in main chunk
[C]: in global 'require'
/home/spot/git/sandbox/lua55/awesome/awesome-4.3-build/awesome-73b20cc3eca34c0dbe40e7798f469e1df787f44d/lib/wibox/widget/init.lua:22: in main chunk
[C]: in global 'require'
/home/spot/git/sandbox/lua55/awesome/awesome-4.3-build/awesome-73b20cc3eca34c0dbe40e7798f469e1df787f44d/lib/wibox/container/tile.lua:14: in main chunk
[C]: in global 'require'
/home/spot/git/sandbox/lua55/awesome/awesome-4.3-build/awesome-73b20cc3eca34c0dbe40e7798f469e1df787f44d/lib/wibox/container/init.lua:20: in main chunk
[C]: in global 'require'
/home/spot/git/sandbox/lua55/awesome/awesome-4.3-build/awesome-73b20cc3eca34c0dbe40e7798f469e1df787f44d/lib/wibox/init.lua:30: in main chunk
[C]: in global 'require'
/home/spot/git/sandbox/lua55/awesome/awesome-4.3-build/awesome-73b20cc3eca34c0dbe40e7798f469e1df787f44d/lib/awful/widget/common.lua:17: in main chunk
[C]: in global 'require'
/home/spot/git/sandbox/lua55/awesome/awesome-4.3-build/awesome-73b20cc3eca34c0dbe40e7798f469e1df787f44d/lib/awful/widget/taglist.lua:49: in main chunk
[C]: in global 'require'
/home/spot/git/sandbox/lua55/awesome/awesome-4.3-build/awesome-73b20cc3eca34c0dbe40e7798f469e1df787f44d/tests/examples/sequences/template.lua:15: in main chunk
[C]: in ?

My best guess here is that this lookup is failing because of how Cairo inheritance is being done? The awesome code (from lib/gears/color.lua) is this:

--- Add a list of stops to a given pattern
local function add_stops_table(pat, arg)
    for _, stop in ipairs(arg) do
        pat:add_color_stop_rgba(stop[1], color.parse_color(stop[2]))
    end
end

local pat
pat = cairo.Pattern.create_linear(arg.from[1], arg.from[2], arg.to[1], arg.to[2])
add_stops_table(pat, arg.stops)

If I copy the add_color_stop_rgba method define from GradientPattern into Pattern, this error goes away, but I'm not at all convinced this is the correct fix. Thanks for any insights you can add here!

[vtrlx]

Hi! First, thank you for the kind words.

Second,

I can see that the add_color_stop_rgba method is listed in LuaGObject's override code for Cairo's GradientPattern class, from which LinearGradient should inherit it.

Unfortunately, I'm not terribly familiar with the Cairo override. Functionally, it's entirely unmodified from LGI, so anything wrong there should be wrong here too. I see that Fedora packages the ancient 0.9.2 release of LGI, which makes me wonder if an upstream change between the release of that and July 2025 (when I forked it) somehow broke the method.

Here's where it gets interesting—the samples/cairo.lua file contains the following function:

...

function samples.gradient(cr)
	local pat = cairo.Pattern.create_linear(0, 0, 0, 256)
	pat:add_color_stop_rgba(1, 0, 0, 0, 1)
	pat:add_color_stop_rgba(0, 1, 1, 1, 1)
	cr:rectangle(0, 0, 256, 256)
	cr.source = pat
	cr:fill()

	pat = cairo.Pattern.create_radial(115.2, 102.4, 25.6, 102.4, 102.4, 128)
	pat:add_color_stop_rgba(0, 1, 1, 1, 1);
	pat:add_color_stop_rgba(1, 0, 0, 0, 0);
	cr.source = pat
	cr:arc(128, 128, 76.8, 0, math.rad(360))
	cr:fill()
end

...

The add_color_stop_rgba method is used for the LinearPattern class here. On my machine, this sample seems to work fine in both LuaGObject and LGI (using Lua 5.4 for LGI), producing the same cairodemo-gradient.png image file. If it doesn't work correctly on your machine, I would suspect an installation issue.

Assuming that the sample does work for you, then the last place to look would have to be AwesomeWM itself. From its issue history I found this peculiar issue but I doubt it'd be related unless you are also trying to run on an unusual architecture.

The other cause I could think about would be if AwesomeWM did some of its own overrides to Cairo to keep up with it given that LGI has seen no releases in years. If that override were to have some kind of conflict, then this issue might arise, but I don't see any sign of such a thing.

Are your WIP changes to Awesome available anywhere? I could try to run your branch to see if I might be able to figure out what's wrong.

[spotaws]

The sample case fails for me in the same manner (I simplified it down to just that function):

local LuaGObject = require 'LuaGObject'
local cairo = LuaGObject.cairo

local pat = cairo.Pattern.create_linear(0, 0, 0, 256)
pat:add_color_stop_rgba(1, 0, 0, 0, 1)
pat:add_color_stop_rgba(0, 1, 1, 1, 1)
cr:rectangle(0, 0, 256, 256)
cr.source = pat
cr:fill()

pat = cairo.Pattern.create_radial(115.2, 102.4, 25.6, 102.4, 102.4, 128)
pat:add_color_stop_rgba(0, 1, 1, 1, 1);
pat:add_color_stop_rgba(1, 0, 0, 0, 0);
cr.source = pat
cr:arc(128, 128, 76.8, 0, math.rad(360))
cr:fill()

spot@triceratops:~/sandbox$ lua cairo.lua
lua: cairo.lua:5: cairo.Pattern: no `add_color_stop_rgba'
stack traceback:
[C]: in upvalue 'error'
/usr/share/lua/5.5/LuaGObject/component.lua:141: in function </usr/share/lua/5.5/LuaGObject/component.lua:137>
[C]: in metamethod 'index'
cairo.lua:5: in main chunk
[C]: in ?

I think this is a change in behavior with Lua 5.5, though, if it is, I can't find it documented. I'm going to try to reproduce it with Lua 5.4 and see if I'm correct.

[vtrlx]

Very, very odd. I needed to make just a few tweaks to your abridged sample to get it working in Lua 5.5:

local LuaGObject = require 'LuaGObject'
local cairo = LuaGObject.cairo

local surface = cairo.ImageSurface.create('ARGB32', 256, 256)
local cr = cairo.Context.create(surface)

local pat = cairo.Pattern.create_linear(0, 0, 0, 256)
pat:add_color_stop_rgba(1, 0, 0, 0, 1)
pat:add_color_stop_rgba(0, 1, 1, 1, 1)
cr:rectangle(0, 0, 256, 256)
cr.source = pat
cr:fill()

pat = cairo.Pattern.create_radial(115.2, 102.4, 25.6, 102.4, 102.4, 128)
pat:add_color_stop_rgba(0, 1, 1, 1, 1);
pat:add_color_stop_rgba(1, 0, 0, 0, 0);
cr.source = pat
cr:arc(128, 128, 76.8, 0, math.rad(360))
cr:fill()

surface:write_to_png "gradient.png"

Specifically, this is with Lua 5.5 (installed on Debian, from source) with the current master branch of LuaGObject also having been installed from source by running make LUA_VERSION=5.5 install from the repository root.

What's your OS and how are Lua and LuaGObject installed?

[spotaws]

Agree, that is weird. My environment is Fedora 45 (Rawhide) x86_64 which is under active development, so it's entirely plausible that:

• I broke something in the lua 5.5.0 build (I maintain that in Fedora)
  ** The only changes I have applied are the upstream fixes for "bug1" and "bug2"
• Something in the latest glibc/gcc/binutils is causing a behavior change
• Something is weird about my local environment

I am using your current LuaGObject code, which I tossed into a RPM and have installed in system paths.

I'm going to spin up some VMs to work in a "known" clean environment and see if I can figure out what reproduces this.

[spotaws]

Okay. I have a clean Fedora 44 x86_64 VM running. I have your test code as cairo-test.lua.

[fedora@ip-172-31-22-165 ~]$ lua -v
Lua 5.4.8  Copyright (C) 1994-2025 Lua.org, PUC-Rio
[fedora@ip-172-31-22-165 ~]$ lua cairo-test.lua 
lua: cairo-test.lua:8: cairo.Pattern: no `add_color_stop_rgba'
stack traceback:
	[C]: in function 'error'
	/usr/share/lua/5.4/LuaGObject/component.lua:141: in function </usr/share/lua/5.4/LuaGObject/component.lua:137>
	[C]: in metamethod 'index'
	cairo-test.lua:8: in main chunk
	[C]: in ?

LuaGObject is built with optflags set to -O2 (only), to try to eliminate compiler flags as the reason. The compiled parts are linked to glibc (2.43), libffi (3.5.2), glib2 (2.87.2).

I'm attaching the build log from LuaGObject in case I'm doing something dumb there.

build.log

[vtrlx]

I'm attaching the build log from LuaGObject in case I'm doing something dumb there.

build.log

I see this in your log at line 90:

+ mkdir -p /home/fedora/rpmbuild/BUILD/lua-LuaGObject-0.10.5-build/BUILDROOT/usr/lib64/lua/5.4 /home/fedora/rpmbuild/BUILD/lua-LuaGObject-0.10.5-build/BUILDROOT/usr/share/lua/5.4
+ make install PREFIX=/usr LUA_LIBDIR=/usr/lib64/lua/5.4 LUA_SHAREDIR=/usr/share/lua/5.4 DESTDIR=/home/fedora/rpmbuild/BUILD/lua-LuaGObject-0.10.5-build/BUILDROOT

Looks like you're installing LuaGObject for Lua 5.4.

[spotaws]

I'm attaching the build log from LuaGObject in case I'm doing something dumb there.
build.log

I see this in your log at line 90:

+ mkdir -p /home/fedora/rpmbuild/BUILD/lua-LuaGObject-0.10.5-build/BUILDROOT/usr/lib64/lua/5.4 /home/fedora/rpmbuild/BUILD/lua-LuaGObject-0.10.5-build/BUILDROOT/usr/share/lua/5.4
+ make install PREFIX=/usr LUA_LIBDIR=/usr/lib64/lua/5.4 LUA_SHAREDIR=/usr/share/lua/5.4 DESTDIR=/home/fedora/rpmbuild/BUILD/lua-LuaGObject-0.10.5-build/BUILDROOT

Looks like you're installing LuaGObject for Lua 5.4.

Correct. I am testing with Fedora 44 (lua 5.4.8) to try to eliminate the new lua (5.5.0) as the source of the problem.

[spotaws]

I installed Fedora's lua-lgi (0.9.2) to give another data point (and made a modified cairo-test-lgi.lua for it that simply does the s/LuaGObject/lgi change):

fedora@ip-172-31-22-165 ~]$ lua cairo-test-lgi.lua 
lua: /usr/share/lua/5.4/lgi/ffi.lua:87: bad argument #1 to 'fromarray' (lgi.record expected, got table)
stack traceback:
	[C]: in field 'fromarray'
	/usr/share/lua/5.4/lgi/ffi.lua:87: in function 'lgi.ffi.load_enum'
	/usr/share/lua/5.4/lgi/override/cairo.lua:55: in main chunk
	[C]: in function 'require'
	/usr/share/lua/5.4/lgi/namespace.lua:183: in function 'lgi.init.require'
	(...tail calls...)
	cairo-test-lgi.lua:2: in main chunk
	[C]: in ?

This failure is because that ancient lgi code doesn't work around modern glib2. If I apply your fixes there (just to get a test done):

diff -up lgi-0.9.2/lgi/ffi.lua.fix lgi-0.9.2/lgi/ffi.lua
--- lgi-0.9.2/lgi/ffi.lua.fix	2017-10-09 18:55:55.000000000 +0000
+++ lgi-0.9.2/lgi/ffi.lua	2026-02-20 15:28:11.622986107 +0000
@@ -76,18 +76,31 @@ end
 
 -- Creates new enum/flags table with all values from specified gtype.
 function ffi.load_enum(gtype, name)
-   local GObject = core.repo.GObject
+   local GLib, GObject = core.repo.GLib, core.repo.GObject
    local is_flags = GObject.Type.is_a(gtype, GObject.Type.FLAGS)
    local enum_component = component.create(
       gtype, is_flags and enum.bitflags_mt or enum.enum_mt, name)
-   local type_class = GObject.TypeClass.ref(gtype)
+   local type_class
+   if GLib.check_version(2, 86, 0) then
+      type_class = GObject.TypeClass.ref(gtype)
+   else
+      type_class = GObject.TypeClass.get(gtype)
+   end
    local enum_class = core.record.cast(
       type_class, is_flags and GObject.FlagsClass or GObject.EnumClass)
-   for i = 0, enum_class.n_values - 1 do
-      local val = core.record.fromarray(enum_class.values, i)
-      enum_component[core.upcase(val.value_nick):gsub('%-', '_')] = val.value
+   if GLib.check_version(2, 87, 0) then
+      for i = 0, enum_class.n_values - 1 do
+         local val = core.record.fromarray(enum_class.values, i)
+         enum_component[core.upcase(val.value_nick):gsub('%-', '_')] = val.value
+      end
+   else
+      for _, val in ipairs(enum_class.values) do
+         enum_component[core.upcase(val.value_nick):gsub('%-', '_')] = val.value
+      end
+   end
+   if GLib.check_version(2, 86, 0) then
+      type_class:unref()
    end
-   type_class:unref()
    return enum_component
 end

With just that change applied, the test case now ... succeeds with lgi.

[vtrlx]

That's a very useful data point. Could you try installing LuaGObject using LuaRocks? I'm interested in knowing if that works.

[spotaws]

That's a very useful data point. Could you try installing LuaGObject using LuaRocks? I'm interested in knowing if that works.

Certainly (first, removing my rpm build of LuaGObject):

[fedora@ip-172-31-22-165 ~]$ sudo rpm -e lua-LuaGObject
[fedora@ip-172-31-22-165 ~]$ sudo luarocks install LuaGObject
Installing https://luarocks.org/luagobject-0.10.5-1.src.rock

luagobject 0.10.5-1 depends on lua >= 5.1 (5.4-1 provided by VM)
make -C LuaGObject
make[1]: Entering directory '/tmp/luarocks_luagobject-0.10.5-1-lg0jYu/LuaGObject/LuaGObject'
pkg-config --exists 'girepository-2.0 >= 2.80.0' --print-errors
touch .depcheck
gcc  -fPIC  -O2 -fPIC -I/usr/include -DWITH_GZFILEOP -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-6 -pthread -Wall -Wextra -O2 -g -c -o buffer.o buffer.c
gcc  -fPIC  -O2 -fPIC -I/usr/include -DWITH_GZFILEOP -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-6 -pthread -Wall -Wextra -O2 -g -c -o callable.o callable.c
gcc  -fPIC  -O2 -fPIC -I/usr/include -DWITH_GZFILEOP -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-6 -pthread -Wall -Wextra -O2 -g -c -o core.o core.c
gcc  -fPIC  -O2 -fPIC -I/usr/include -DWITH_GZFILEOP -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-6 -pthread -Wall -Wextra -O2 -g -c -o gi.o gi.c
gi.c: In function ‘namespace_index’:
gi.c:609:29: warning: variable ‘index’ set but not used [-Wunused-but-set-variable=]
  609 |                         int index;
      |                             ^~~~~
gcc  -fPIC  -O2 -fPIC -I/usr/include -DWITH_GZFILEOP -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-6 -pthread -Wall -Wextra -O2 -g -c -o marshal.o marshal.c
gcc  -fPIC  -O2 -fPIC -I/usr/include -DWITH_GZFILEOP -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-6 -pthread -Wall -Wextra -O2 -g -c -o object.o object.c
gcc  -fPIC  -O2 -fPIC -I/usr/include -DWITH_GZFILEOP -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-6 -pthread -Wall -Wextra -O2 -g -c -o record.o record.c
gcc -shared  -o lua_gobject_core.so buffer.o callable.o core.o gi.o marshal.o object.o record.o -lgirepository-2.0 -lgobject-2.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 -lffi
echo "return '0.10.5'" > version.lua
make[1]: Leaving directory '/tmp/luarocks_luagobject-0.10.5-1-lg0jYu/LuaGObject/LuaGObject'
make -C LuaGObject install
make[1]: Entering directory '/tmp/luarocks_luagobject-0.10.5-1-lg0jYu/LuaGObject/LuaGObject'
mkdir -p /usr/lib/luarocks/rocks-5.4/luagobject/0.10.5-1/lib/LuaGObject
cp lua_gobject_core.so /usr/lib/luarocks/rocks-5.4/luagobject/0.10.5-1/lib/LuaGObject
mkdir -p /usr/lib/luarocks/rocks-5.4/luagobject/0.10.5-1/lua
cp ../LuaGObject.lua /usr/lib/luarocks/rocks-5.4/luagobject/0.10.5-1/lua
mkdir -p /usr/lib/luarocks/rocks-5.4/luagobject/0.10.5-1/lua/LuaGObject
cp class.lua component.lua core.lua enum.lua ffi.lua init.lua log.lua namespace.lua package.lua record.lua version.lua /usr/lib/luarocks/rocks-5.4/luagobject/0.10.5-1/lua/LuaGObject
mkdir -p /usr/lib/luarocks/rocks-5.4/luagobject/0.10.5-1/lua/LuaGObject/override
cp override/Adw.lua override/cairo.lua override/Clutter.lua override/Gdk.lua override/Gio-DBus.lua override/Gio.lua override/GLib-Bytes.lua override/GLib-Error.lua override/GLib.lua override/GLib-Markup.lua override/GLib-Source.lua override/GLib-Timer.lua override/GLib-Variant.lua override/GObject-Closure.lua override/GObject-Object.lua override/GObject-Type.lua override/GObject-Value.lua override/GooCanvas.lua override/Gst.lua override/Gtk3.lua override/Gtk4.lua override/Gtk.lua override/PangoCairo.lua override/Pango.lua /usr/lib/luarocks/rocks-5.4/luagobject/0.10.5-1/lua/LuaGObject/override
make[1]: Leaving directory '/tmp/luarocks_luagobject-0.10.5-1-lg0jYu/LuaGObject/LuaGObject'
No existing manifest. Attempting to rebuild...
luagobject 0.10.5-1 is now installed in /usr (license: MIT/X11)

[fedora@ip-172-31-22-165 ~]$ lua cairo-test.lua 
lua: cairo-test.lua:8: cairo.Pattern: no `add_color_stop_rgba'
stack traceback:
	[C]: in function 'error'
	/usr/share/lua/5.4/LuaGObject/component.lua:141: in function </usr/share/lua/5.4/LuaGObject/component.lua:137>
	[C]: in metamethod 'index'
	cairo-test.lua:8: in main chunk
	[C]: in ?

[vtrlx]

I've successfully replicated the issue using a Fedora 44 Toolbox. Will investigate now.

[spotaws]

Okay, next data point: I spun up a Fedora 43 x86_64 VM (lua 5.4.8) and I cannot reproduce the issue.

[spotaws]

Fedora 43 has glibc 2.42 and glib2 2.86.4 and libffi 3.5.2

[spotaws]

Upgrading just glib2 (and glibc) on that Fedora 43 machine to the Fedora 44 versions reproduces the issue. Going to revert and rebuild just glib2 to see if I can confirm that as the factor.

[spotaws]

Upgrading glib2 (just glib2) from 2.86.4 (included in Fedora 43) to 2.87.2 (included in Fedora 44), rebuild in the Fedora 43 env, reproduces the issue. I'm going to try to see if I can figure out which glib2 version in that gap is the "first to break".