Full path of app couldn't be used
Brought to you by:
sobukus
Menu
▾
▴
#277 Full path of app couldn't be used
Version 1.25.1 tested in fatdog64 linux version 800
and I found that the full path of app couldn't be used.
Here is an example....
/usr/bin/mpg123 /mnt/sdc1/Zeitumstellung.mp3
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3
version 1.25.10; written and copyright by Michael Hipp and others
free software (LGPL) without any warranty but with best wishes
[src/libout123/module.c:133] error: Failed to open module alsa.
[src/libout123/module.c:133] error: Failed to open module oss.
[src/libout123/module.c:133] error: Failed to open module jack.
[src/libout123/module.c:133] error: Failed to open module portaudio.
[src/libout123/module.c:133] error: Failed to open module sdl.
[src/libout123/libout123.c:455] error: Found no driver out of [alsa,oss,jack,portaudio,sdl] working with device <default>.
main: [src/mpg123.c:309] error: out123 error 3: failure loading driver module</default>
I checked with others on puppy linux forum and I found that 32 bit wine package
has the 32 bit mpg123 app installed . This causes confusion as to where
where the correct 64 bit libraries of mpg123 are located.
So the problem seems to be how 32 bit wine is implemented in a 64 bit operating system.
OK, I need to remember that replying to bugs via mail does not work on sf.net. This I wrote some time ago:
WTF? Eh … I mean … interesting.
I reckon that this must be something specific to fatdog64. Hm, but
then, there is something broken in how the module directory is searched.
First: The normal installation in a Linux system should find the
modules via the fixed installation path defined at build time.
Second: Before resorting to the built-in module directory, mpg123
searches relative to the binary. I just see that we only use argv[0]
without ensuring that it is an absolute path. I think I remember
argv[0] being either an absolute path (when calling explicitly or
finding the binary via the $PATH) or a relative path that
works from the current directory. But that is a wild assumption that is
not correct on current Debian, at least. We need to be smarter about
finding the binary path, maybe even resorting to /proc/self/exe.
But first things first: How was it installed that /usr/lib/mpg123 is
not recorded as the fixed module path? Or is
it /usr/lib/something/mpg123? Does it work with
?
So the issue now is that /usr/bin/mpg123 looks for modules in /usr/bin/../lib/mpg123 and indeed does find some, but those are 32 bit modules not belonging to /usr/bin/mpg123, which is a 64 bit binary? I did not plan for that. I could add some smartness that tries to resort to other paths if a module file is not loadable … At least if the 32 bit stuff would be installed in /usr/lib32, the loader would fall back to the path fixed at build time.
Does this issue persist? Or you got a workaround?