bug#34854: stepmania does not work

bug#34854: stepmania does not work

[Ricardo Wurmus]

“stepmania” cannot find its Songs directory, so I created it.  After
doing that, however, “stepmania” still cannot be started as it can’t
find GtkModule.so.

--8<---------------cut here---------------start------------->8---
$ /gnu/store/awp5w5v3hfg8zilviarwj85s2y820lyg-stepmania-5.1.0-b2/bin/stepmania --help

//////////////////////////////////////////////////////
Exception: Couldn't find 'Songs'
//////////////////////////////////////////////////////

Error: Couldn't find 'Songs'

$ mkdir Songs
$ /gnu/store/awp5w5v3hfg8zilviarwj85s2y820lyg-stepmania-5.1.0-b2/bin/stepmania 
StepMania5.1-UNKNOWN
Compiled 19700101 @ 00:00:01 (build UNKNOWN)
Log starting 2019-03-14 09:15:27
Couldn't load driver gtk: dlopen(): /gnu/store/awp5w5v3hfg8zilviarwj85s2y820lyg-stepmania-5.1.0-b2/bin/GtkModule.so: cannot open shared object file: No such file or directory
Error: Couldn't open any loading windows.
--8<---------------cut here---------------end--------------->8---

-- 
Ricardo

bug#34854: stepmania does not work

[Nicolas Goaziou]

Hello,

Ricardo Wurmus <rekado@elephly.net> writes:

> “stepmania” cannot find its Songs directory, so I created it.  After
> doing that, however, “stepmania” still cannot be started as it can’t
> find GtkModule.so.
>
> --8<---------------cut here---------------start------------->8---
> $ /gnu/store/awp5w5v3hfg8zilviarwj85s2y820lyg-stepmania-5.1.0-b2/bin/stepmania --help
>
> //////////////////////////////////////////////////////
> Exception: Couldn't find 'Songs'
> //////////////////////////////////////////////////////
>
> Error: Couldn't find 'Songs'
>
> $ mkdir Songs
> $ /gnu/store/awp5w5v3hfg8zilviarwj85s2y820lyg-stepmania-5.1.0-b2/bin/stepmania 
> StepMania5.1-UNKNOWN
> Compiled 19700101 @ 00:00:01 (build UNKNOWN)
> Log starting 2019-03-14 09:15:27
> Couldn't load driver gtk: dlopen(): /gnu/store/awp5w5v3hfg8zilviarwj85s2y820lyg-stepmania-5.1.0-b2/bin/GtkModule.so: cannot open shared object file: No such file or directory\a
> Error: Couldn't open any loading windows.
> --8<---------------cut here---------------end--------------->8---

Oddly, I cannot reproduce the issue on a foreign distribution (Debian):
the program runs properly.

Nevertheless, as a hint, "GtkModule.so" is located in
"/gnu/store/…-stepmania-5.1.0-b2/share/stepmania/".

If I read the following excerpt from Makefile.am correctly:

--8<---------------cut here---------------start------------->8---
installFiles = src/stepmania
if HAVE_GTK
installFiles += src/GtkModule.so
endif

[...]

install-exec-hook:
	mkdir -p "$(DESTDIR)$(prefix)/stepmania-$(VERSION)"
	$(INSTALL) $(installFiles) "$(DESTDIR)$(prefix)/stepmania-$(VERSION)"
--8<---------------cut here---------------end--------------->8---

"GtkModule.so" should be located in the same directory as the executable
"stepmania". This is the case in our package: both are located in
"…stepmania-5.1.0-b2/share/stepmania/".

However, our package definition also creates a symlink to the
"stepmania" executable in the "bin/" directory. Since the symlink is
launched, and not the executable, the working directory seems to be off.

As another data point, the one place in the code base that actually
makes use of "GtkModule.so" is "LoadingWindow/LoadingWindow_Gtk.cpp"
file:

--8<---------------cut here---------------start------------->8---
std::string LoadingWindow_Gtk::Init()
{
	ASSERT( Handle == nullptr );

	Handle = dlopen( (RageFileManagerUtil::sDirOfExecutable + "/" + "GtkModule.so").c_str(), RTLD_NOW );
--8<---------------cut here---------------end--------------->8---

I'm not sure about how to proceed from there. Maybe use `wrap-program'
around the "stepmania" symlink. If so, what to wrap? Another option is
to patch the "LoadingWindow_Gtk.cpp" file like:

--8<---------------cut here---------------start------------->8---
Handle = dlopen( (RageFileManagerUtil::sDirOfExecutable + "/" + "../share/stepmania/GtkModule.so").c_str(), RTLD_NOW );
--8<---------------cut here---------------end--------------->8---

I'd favor the second option, but I cannot test the results since
I cannot reproduce the problem.

WDYT?

Regards,

-- 
Nicolas Goaziou

bug#34854: stepmania does not work

[Ricardo Wurmus]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> "GtkModule.so" should be located in the same directory as the executable
> "stepmania". This is the case in our package: both are located in
> "…stepmania-5.1.0-b2/share/stepmania/".
>
> However, our package definition also creates a symlink to the
> "stepmania" executable in the "bin/" directory. Since the symlink is
> launched, and not the executable, the working directory seems to be off.
>
> As another data point, the one place in the code base that actually
> makes use of "GtkModule.so" is "LoadingWindow/LoadingWindow_Gtk.cpp"
> file:
>
> --8<---------------cut here---------------start------------->8---
> std::string LoadingWindow_Gtk::Init()
> {
> 	ASSERT( Handle == nullptr );
>
> 	Handle = dlopen( (RageFileManagerUtil::sDirOfExecutable + "/" + "GtkModule.so").c_str(), RTLD_NOW );
> --8<---------------cut here---------------end--------------->8---
>
> I'm not sure about how to proceed from there. Maybe use `wrap-program'
> around the "stepmania" symlink. If so, what to wrap? Another option is
> to patch the "LoadingWindow_Gtk.cpp" file like:
>
> --8<---------------cut here---------------start------------->8---
> Handle = dlopen( (RageFileManagerUtil::sDirOfExecutable + "/" + "../share/stepmania/GtkModule.so").c_str(), RTLD_NOW );
> --8<---------------cut here---------------end--------------->8---
>
> I'd favor the second option, but I cannot test the results since
> I cannot reproduce the problem.

I implemented something similar in commit
45aba232abe50b6642abfaa06030985c7febbe07.

There still are problems, though.  The program expects a directory
“Songs” to exist in the current working directory.  It then fails with
this error:

    Error: No NoteSkins found

This seems to work fine only when when “stepmania” is executed from
within the “share/stepmania” directory.  I suspect that this is the same
kind of problem.

--
Ricardo

bug#34854: stepmania does not work

[Ricardo Wurmus]

Ricardo Wurmus <rekado@elephly.net> writes:

> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> "GtkModule.so" should be located in the same directory as the executable
>> "stepmania". This is the case in our package: both are located in
>> "…stepmania-5.1.0-b2/share/stepmania/".
>>
>> However, our package definition also creates a symlink to the
>> "stepmania" executable in the "bin/" directory. Since the symlink is
>> launched, and not the executable, the working directory seems to be off.
>>
>> As another data point, the one place in the code base that actually
>> makes use of "GtkModule.so" is "LoadingWindow/LoadingWindow_Gtk.cpp"
>> file:
>>
>> --8<---------------cut here---------------start------------->8---
>> std::string LoadingWindow_Gtk::Init()
>> {
>> 	ASSERT( Handle == nullptr );
>>
>> 	Handle = dlopen( (RageFileManagerUtil::sDirOfExecutable + "/" + "GtkModule.so").c_str(), RTLD_NOW );
>> --8<---------------cut here---------------end--------------->8---
>>
>> I'm not sure about how to proceed from there. Maybe use `wrap-program'
>> around the "stepmania" symlink. If so, what to wrap? Another option is
>> to patch the "LoadingWindow_Gtk.cpp" file like:
>>
>> --8<---------------cut here---------------start------------->8---
>> Handle = dlopen( (RageFileManagerUtil::sDirOfExecutable + "/" + "../share/stepmania/GtkModule.so").c_str(), RTLD_NOW );
>> --8<---------------cut here---------------end--------------->8---
>>
>> I'd favor the second option, but I cannot test the results since
>> I cannot reproduce the problem.
>
> I implemented something similar in commit
> 45aba232abe50b6642abfaa06030985c7febbe07.
>
> There still are problems, though.  The program expects a directory
> “Songs” to exist in the current working directory.  It then fails with
> this error:
>
>     Error: No NoteSkins found
>
> This seems to work fine only when when “stepmania” is executed from
> within the “share/stepmania” directory.  I suspect that this is the same
> kind of problem.

This is now fixed with commit 4774677228.

-- 
Ricardo