#125 mpg123 is broken with libtool 2.2.6b

mpg123 (104)

With libtool 2.2.6b mpg123 cannot find its modules. The output of --list-modules looks like this:

Available modules
[module.c:138] error: Failed to open module alsa: file not found
[module.c:138] error: Failed to open module dummy: file not found
[module.c:138] error: Failed to open module oss: file not found

Tested with mpg123 1.9.1 and 1.9.2, both versions are working with libtool 2.2.6a. Might be related to bug #2899770.


  • Peter O'Gorman

    Peter O'Gorman - 2009-11-22

    Libtool-2.2.6b made changes to libltdl so that it no longer searches the current working directory for modules to load. If you need to load modules from cwd, use lt_dlopen("./module_name.extension"); which should work for all libltdl versions.

  • Thomas Orgis

    Thomas Orgis - 2009-11-22

    Why such a change in such a minor version bump? I'm also not sure if the documentation really mandates that the current directory is not searched:

    "If libltdl cannot find the library and the file name filename does not have a directory component it will additionally look in the following search paths for the module (in the following order):"

    WIth normal POSIX open in mind, "cannot find the file" translates for "a file of this name is not found in the current working directory". I'd rather have the documentation clarified that files are looked for in the current directory if they don't have an absolute path. That's what I assumed, obviously, when doing the current mechanism for mpg123 to find modules.

    Well, the change is there and won't be taken back... so I'll have to add that ./ and kindly ask to clarify the documentation to make it crystal that the current working directory is _not_ searched on opening a module.

    Btw, pogma: Do you have a word on my issue with .la files always containting the full path to a library? P.ex. on Windows (built with MinGW/MSYS), we have to do

    sed -e 's/libdir=.*$/libdir='"'.'/"

    on all .la files so that modules work at all. And on systems I work on, the .la always ends up in the same directory as the real library. This hack on libdir also helps me testing a mpg123 build out of the source directory, without installing to the real prefix.
    It makes dynamic modules a good deal less dynamic when the modules insist on a specific directory to be placed in. Especially on windows, one expects a (well-written) application to still work when it's install directory is moved/renamed.

    I wonder if I should complain about this issue officially or if it is really imperative to have the absolute path in the libdir and I need to live with this inconvenience.

  • Thomas Orgis

    Thomas Orgis - 2009-11-22

    Oh, and I'd be thankful for any enlightment on #2899770 ... I don't see a relation to this issue here, though... module files are not installed at all there... more feedback from the poster there would be nice.

  • Peter O'Gorman

    Peter O'Gorman - 2009-11-24

    I don't really know anything about libltdl on windows. Please bring this issue up on bug-libtool@gnu.org, or libtool@gnu.org (where someone who does know something about it will likely answer).

  • Nobody/Anonymous

    This is fixed in mpg123 trunk (using the simplest patch, './' prepended to the module file name) and will be part of the 1.10 release, which is overdue because of some portability issues.

    Just in case people wonder why there wasn't a quick 1.9.3 release with the fix: The Sourceforge.net process for adding a release sucks so bad, adding to the normal release work of prepping tarball and writing up NEWS, that I humbly try to minimize the number of times I need to do that, and 1.10 was about to be released soon anyway... Pathetic, isn't it? Sorry :-/

    Expect the fixed release in a few days...

  • Thomas Orgis

    Thomas Orgis - 2009-12-03

    The last comment was me... I was logged in just a minute ago, then sf.net decided to drop me. Thank you.

  • Thomas Orgis

    Thomas Orgis - 2009-12-03
    • status: open --> open-fixed
  • Thomas Orgis

    Thomas Orgis - 2009-12-05
    • status: open-fixed --> closed-fixed

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks