vsgi-server-module.vala:67: libvsgi-http.so: cannot open shared object file: No such file or directory

[devnix]

Hi! As soon as I include a gnome.compile_resources line in my meson.build, I'm getting a runtime error like the one of the title:

 ** (process:1): CRITICAL **: vsgi-server-module.vala:67: libvsgi-http.so: cannot open shared object file: No such file or director
 ** (process:1): CRITICAL **: vsgi_server_run: assertion 'self != NULL' failed

My meson.build looks like this:

project('valabb', 'c', 'vala')
gnome = import('gnome')

dependencies = [
	dependency('glib-2.0'),
	dependency('gobject-2.0'),
	dependency('gio-2.0'),
	dependency('libsoup-2.4'),
	dependency('vsgi-0.3'),
	dependency('valum-0.3'),
	dependency('template-glib-1.0'),
]

sources = files(
	'src/Application.vala',
	'src/Controller/IndexController.vala',
	'src/Controller/RegisterController.vala',
	'src/Controller/Admin/IndexController.vala',
)

sources += gnome.compile_resources(
	'template-glib-resources',
	'resources/app.gresource.xml',
	source_dir: './src'
)

vala_flags = '--gresourcesdir=' + join_paths(meson.current_source_dir(), 'resources')

executable(
	'valabb',
	sources,
	dependencies: dependencies,
	vala_args: vala_flags
)

If this is not related at all with Valum, please just let me know to open an issue somewhere else :smile:

[arteymix]

Server modules are loaded dynamically using -rtpath and $ORIGIN and I noticed it's not very robust in some linking setup.

Have you tried to use Meson built-in support for GResource?

[devnix]

I don't know any other way to use gresource with Meson, I thought that gnome.compile_resources was the supported method...

[arteymix]

You shouldn't have to pass --gresourcedir if you already pass the result of gnome.compile_resources to your target.

There's a working example in https://github.com/valum-framework/valum/blob/master/examples/app/meson.build

I'm currently investigating how libgda does load its providers.

[devnix]

In my first attempts I was not passing any --gresourcedir. I've modified again my meson.build to look a little more like the example you are showing me but with the same results:

project('valabb', 'c', 'vala')
gnome = import('gnome')

dependencies = [
	dependency('glib-2.0'),
	dependency('gobject-2.0'),
	dependency('gio-2.0'),
	dependency('libsoup-2.4'),
	dependency('vsgi-0.3'),
	dependency('valum-0.3'),
	dependency('template-glib-1.0'),
]

sources = [
	'src/Application.vala',
	'src/Controller/IndexController.vala',
	'src/Controller/RegisterController.vala',
	'src/Controller/Admin/IndexController.vala',
]

sources += gnome.compile_resources(
	'template-glib-resources',
	'resources/app.gresource.xml',
	source_dir: './src'
)

executable(
	'valabb',
	sources,
	dependencies: dependencies
)

By the way, my initial work was based on https://github.com/valum-framework/valum/blob/master/examples/template-glib/meson.build

[msmaldi]

Some problem

[arteymix]

Is this still happening in the current trunk? I think we've addressed this in https://github.com/valum-framework/vsgi/pull/6 by passing -Wl,--disable-new-dtags.

Maybe @colinkiama could have a look?

[colinkiama]

I replicated the template-glib example and managed to get it working but only after adding the linker flags and rpath like I did in valum-framework/vsgi#6

Here's what the meson.build file looks like:

sources = [
  'main.vala'
]

sources += gnome.compile_resources(
  'template-glib-resources',
  'app.gresource.xml',
  source_dir: '.'
)

executable('valabb',
  sources,
  dependencies: dependencies,
  link_args: ['-Wl,--disable-new-dtags'],
  build_rpath: join_paths(get_option('prefix'), get_option('libdir'), 'vsgi-@0@/servers'.format('0.4')),
  install: true)

[arteymix]

It's about time we get this fixed.

The -rpath trick I've been using does not reliably work. We need a solution that works both when compiling as a Meson subproject and when linking against a regular installation.

[colinkiama]

I suggest introducing some sort of configuration file system that allows us to load modules dynamically, like Apache and NGINX do.

What do you think?