Fix Source release with actual working source code please.

[GoogleCodeExporter]

I compiled everything, that went fine but, then I just get errors:

...
Video Error: Emulator core Video Extension API (v2.0.0) incompatible with 
plugin (v3.0.0)
UI-Console Error: Error: Video plugin library './mupen64plus-video-rice.so' 
failed to start.
Video Error: Emulator core Video Extension API (v2.0.0) incompatible with 
plugin (v3.0.0)
UI-Console Error: Error: Video plugin library './mupen64plus-video-rice.so' 
failed to start.
Video Error: Emulator core Video Extension API incompatible with this plugin
UI-Console Error: Error: Video plugin library 
'./mupen64plus-video-glide64mk2.so' failed to start.
UI-Console: using Video plugin: <dummy>
Audio Warning: No version number in 'Audio-SDL' config section. Setting 
defaults.
...
Audio: Initializing SDL audio subsystem...
Segmentation fault (core dumped)

Oddly enough running with gdb causes it to not segfault but it pretty much 
useless without video plugins.

Original issue reported on code.google.com by dan...@enemyplanet.geek.nz on 25 Jan 2014 at 6:30

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Please compile all against correct API headers and use the correct version of 
the plugins

Original comment by s...@narfation.org on 26 Jan 2014 at 7:11

[GoogleCodeExporter]

And use the core library (doesn't seem to be the case here because it expects a 
different video extension api)

Original comment by s...@narfation.org on 26 Jan 2014 at 7:12

[GoogleCodeExporter]

It was direct source from this site, Uninstalling the local copy (the one from 
the repos) allowed it to run, looks like something is causing it to prioritise 
system libraries over current directory.

Original comment by dan...@enemyplanet.geek.nz on 26 Jan 2014 at 9:17

[GoogleCodeExporter]

This line is responsible for setting the priorities in mupen64plus-ui-console 
in finding the core library: 
https://github.com/mupen64plus/mupen64plus-ui-console/blob/d1bbbcca5f2a2997fbf12
d2b133361561a1d5da4/src/osal_files_unix.c#L40

Original comment by s...@narfation.org on 26 Jan 2014 at 10:16

[GoogleCodeExporter]

Maybe the order should be changed to try cwd before /usr/lib?

Original comment by dan...@enemyplanet.geek.nz on 26 Jan 2014 at 11:51

[GoogleCodeExporter]

Both the core search path:

https://github.com/mupen64plus/mupen64plus-ui-console/blob/d1bbbcca5f2a2997fbf12
d2b133361561a1d5da4/src/core_interface.c#L121

and the plugin search path:

https://github.com/mupen64plus/mupen64plus-ui-console/blob/d1bbbcca5f2a2997fbf12
d2b133361561a1d5da4/src/osal_files_unix.c#L40

are written in such a way that it resamples the "unix" way of using the global 
stuff. Usually your search path for libraries and executables don't contain the 
cwd as current path. For convenience reasons, this idea was slightly modified 
to also search the local path as last resort.

I am personally (right now, at this specific time) are against modifying it 
because it would not things I am not expecting from a normal program running 
under Linux.

Users can still change it by specifying at different core library/plugin search 
path in their GUI. Or they can specify the search path (--plugindir), complete 
path to a specific plugin (--gfx, --audio, --input, --rsp) and the complete 
path to the core (--corelib).

But mixing installed and global stuff is done by the user (by specifying it on 
the command line or setting in the config) and he is responsible of handling it 
when he does it. Changing the search path priorities will not resolve it 
because then it will just get people expecting the other behavior (and having 
it right now) to experience "weird" things with the next version.

But I would propose following: The setting of the config option 
"UI-Console[PluginDir]" should not be "./" by default and instead use a global 
path during the first run to make it more consistent with the rest of the 
core/library search paths.

https://github.com/mupen64plus/mupen64plus-ui-console/blob/d1bbbcca5f2a2997fbf12
d2b133361561a1d5da4/src/main.c#L203

Leaving it empty by default and don't use it during the search when it is empty 
makes more sense to me right now.

Original comment by s...@narfation.org on 27 Jan 2014 at 10:42

[GoogleCodeExporter]

cwd first seems more logical to me as.

The chances of the cwd being filled with binaries that are incompatible are 
very unlikely. As in a system install trying to be run from a test directory 
seems very unlikely.

A user who has just compiled a version like me, will not know that it loads 
binaries from the system over cwd, and may wonder why zero amount of change has 
happened after compiling a new version, or that a new plugin doesn't work / 
isn't found.

The other option is that the test directory gets a test.sh which sets these 
switches, this will hint at the user that you should use this over running the 
binary directly, and maybe a mention in a FAQ / wiki page about this behaviour.

Original comment by dan...@enemyplanet.geek.nz on 29 Jan 2014 at 11:00