Home

Chris

OpenAL Soft is a software implementation of the OpenAL 3D audio API. It provides capabilities for playing audio in a virtual 3d environment. Distance attenuation, doppler shift, and directional sound emitters are among the features handled by the API.


Project Admins:


  • fastrgv
    fastrgv
    2014-07-16

    I recently built both static & dynamic libraries from these sources. No problem with dynamic, but the static lib (libopenal.a) does not seem to produce a valid executable on my ubuntu system even though there are no link errors. Any hints or suggestions would be appreciated. fastrgv@gmail.com

     
    • Chris
      Chris
      2014-07-17

      On 07/16/2014 04:28 PM, fastrgv wrote:

      I recently built both static & dynamic libraries from these sources.
      No problem with dynamic, but the static lib (libopenal.a) does not
      seem to produce a valid executable on my ubuntu system even though
      there are no link errors. Any hints or suggestions would be
      appreciated.

      What's the problem when you try to run the app? How did you build OpenAL
      Soft, and your app?

       
      • fastrgv
        fastrgv
        2014-07-17

        I downloaded the latest (1.15.1) on 15jul14 and built as usual. Did not
        get static lib so in another build directory, after changing CMakeLists.txt
        line 81 to
        SET(LIBTYPE STATIC)
        I went thru same process and got libopenal.a and manually put all libs into
        /usr/local/lib/OpenAL/.

        So, for my app, here is the build script:

        g++ $1.cc -o $1 \ lodepng.cpp \ shader.cpp \ text2d.cpp \ loadpng.cpp \ -DSFML_STATIC \ -fpermissive \ -W -Wall -Wextra -pedantic -Wno-unused-variable \ -Wno-literal-suffix \ -std=c++11 \ -I. \ -I/usr/local/include/SDL2 \ -I/usr/local/include \ -I/usr/include/X11 \ -I/usr/include/X11/extensions \ -I/usr/include/GL \ -L/usr/lib/x86_64-linux-gnu \ -lGL -lGLU \ /usr/lib/x86_64-linux-gnu/libsfml-audio-s.a \ /usr/lib/x86_64-linux-gnu/libsfml-system-s.a \ /usr/local/lib/OpenAL/libopenal.so \ /usr/lib/x86_64-linux-gnu/libsndfile.a \ /usr/lib/x86_64-linux-gnu/libvorbis.a \ /usr/lib/x86_64-linux-gnu/libvorbisenc.a \ /usr/lib/x86_64-linux-gnu/libogg.a \ /usr/lib/x86_64-linux-gnu/libFLAC.a \ /usr/local/lib/libSDL2.a -ldl \ /usr/local/lib/libGLEW.a \ /usr/local/lib/libGLEWmx.a \ -pthread
        =========================================================
        The above script works fine. But when I replace one line with:
        /usr/local/lib/OpenAL/libopenal.a \ ( I replaced ".so" with ".a") the build succeeds with no errors, but the executable simply hangs...and I have to ^c to kill the command.

        I suppose there are system diagnostics possible but I'm not very good at that kind of thing.

        This is on ubuntu 14.04 and I had months ago downloaded thru the system the approved ubuntu version of openal-dev and I noticed it had no static lib which makes me suspicious.

        Rod fastrgv@gmail.com

        On Wed, Jul 16, 2014 at 5:37 PM, Chris chris-kcat@users.sf.net wrote:

        On 07/16/2014 04:28 PM, fastrgv wrote:

        I recently built both static & dynamic libraries from these sources.
        No problem with dynamic, but the static lib (libopenal.a) does not
        seem to produce a valid executable on my ubuntu system even though
        there are no link errors. Any hints or suggestions would be
        appreciated.

        What's the problem when you try to run the app? How did you build OpenAL
        Soft, and your app?


        Sent from sourceforge.net because you indicated interest in
        https://sourceforge.net/p/openal-soft/wiki/Home/

        To unsubscribe from further messages, please visit
        https://sourceforge.net/auth/subscriptions/

         
        Last edit: fastrgv 2014-07-18
  • fastrgv
    fastrgv
    2014-07-17

    I downloaded the latest (1.15.1) on 15jul14 and built as usual. Went into the build directory and typed "cmake .." followed by "make".

    That did not produce a static lib so in another build directory, after changing CMakeLists.txt line 81 to
    SET(LIBTYPE STATIC)
    I went thru same process and got libopenal.a and manually put all libs into /usr/local/lib/OpenAL/. The openal build seemed to go smoothly.

    So, for my app, here is the build script:

    g++ $1.cc -o $1 \ lodepng.cpp \ shader.cpp \ text2d.cpp \ loadpng.cpp \ -DSFML_STATIC \ -fpermissive \ -W -Wall -Wextra -pedantic -Wno-unused-variable \ -Wno-literal-suffix \ -std=c++11 \ -I. \ -I/usr/local/include/SDL2 \ -I/usr/local/include \ -I/usr/include/X11 \ -I/usr/include/X11/extensions \ -I/usr/include/GL \ -L/usr/lib/x86_64-linux-gnu \ -lGL -lGLU \ /usr/lib/x86_64-linux-gnu/libsfml-audio-s.a \ /usr/lib/x86_64-linux-gnu/libsfml-system-s.a \ /usr/local/lib/OpenAL/libopenal.so \ /usr/lib/x86_64-linux-gnu/libsndfile.a \ /usr/lib/x86_64-linux-gnu/libvorbis.a \ /usr/lib/x86_64-linux-gnu/libvorbisenc.a \ /usr/lib/x86_64-linux-gnu/libogg.a \ /usr/lib/x86_64-linux-gnu/libFLAC.a \ /usr/local/lib/libSDL2.a -ldl \ /usr/local/lib/libGLEW.a \ /usr/local/lib/libGLEWmx.a \ -pthread

    The above script works fine. But when I replace one line with:
    /usr/local/lib/OpenAL/libopenal.a \ ( I replaced ".so" with ".a") the build also succeeds with no errors, but the command line executable simply hangs...and I have to ^c to kill it.

    I suppose there are system diagnostics possible but I'm not very good at that kind of thing.

    This is on ubuntu 14.04 and I had months ago downloaded thru the system the approved ubuntu version of openal-dev and I noticed it had no static lib which makes me suspicious.

    I am building (free) games and I'd like to maximize portability by not forcing the end users to install a bunch of libraries that they might not normally have on their system. EG, not many have GLEW installed.

    Sorry for the duplicate responses (in case my gmail response worked also) but this one is slightly more complete.

    Rod fastrgv@gmail.com

     
    Last edit: fastrgv 2014-07-18
    • Chris
      Chris
      2014-07-17

      On 07/16/2014 07:10 PM, fastrgv wrote:

      I downloaded the latest (1.15.1) on 15jul14 and built as usual. Went
      into the build directory and typed "cmake .." followed by "make".

      That did not produce a static lib so in another build directory,
      after changing CMakeLists.txt line 81 to SET(LIBTYPE STATIC) I went
      thru same process and got libopenal.a and manually put all libs into
      /usr/local/lib/OpenAL/. The openal build seemed to go smoothly.

      So, for my app, here is the build script:
      [...]
      The above
      script works fine. But when I replace one line with:
      /usr/lib/x86_64-linux-gnu/libopenal.a \ ( I replaced ".so" with
      ".a") the build also succeeds with no errors, but the command line
      executable simply hangs...and I have to ^c to kill it.

      Hmm, do you know how to use gdb to get a backtrace? Run gdb with your
      app from the terminal:

      $ gdb ./myapp

      Then at the gdb prompt, run the app:

      (gdb) run

      When the program hangs, press ctrl-c to cause a SIGINT and drop back to
      a gdb prompt. Then you can do this to get a backtrace on all threads:

      (gdb) thread apply all backtrace

      There could be quite a bit of output depending on how many threads are
      currently running on the app, but it would be good to have them in case
      the main thread isn't the culprit.

      This is on ubuntu 14.04 and I had months ago downloaded thru the
      system the approved ubuntu version of openal-dev and I noticed it had
      no static lib which makes me suspicious.

      Generally speaking, it's not recommended to use OpenAL as a static lib.
      Like OpenGL, users could have different implementations for their
      system. This isn't as much of an issue on Linux where there aren't any
      hardware-specific OpenAL drivers, but it's still a good idea to leave
      OpenAL as a dynamic lib so users can easily update to newer versions
      that may have more features, better performance, or just generally work
      better.

      You can, of course, still provide a version of the dynamic libs you use
      if you don't want to require the end user to install any prerequisites.
      You can do this easily using the linker's $ORIGIN rpath feature.

      https://www.technovelty.org/linux/exploring-origin.html

      Essentially, if your app is in /some/path (such that the executable is
      /some/path/myapp), you can use the $ORIGIN rpath to make the app look in
      /some/path (or some place relative to it) for dynamic libraries at
      run-time. If you then move myapp to /some/other/path, it will then look
      relative to /some/other/path automatically.

      It's as simple as adding -Wl,-rpath='$$ORIGIN' to the Makefile's link
      command (the double $$ is so make passes $ORIGIN to the command line,
      otherwise it would try to expand an ORIGIN variable, and the '' quotes
      so the shell won't expand it either) and placing libopenal.so.1 with the
      executable. Alternatively, you can do -Wl,-rpath='$$ORIGIN/lib' and have
      your program's hierarchy like this:

      ./myapp (the executable)
      ./lib/libopenal.so.1
      ./lib/libSomethingElse.so.0
      etc

      Then so long as myapp and the lib folder stay relative to each other,
      it'll pick up the dynamic lib there. Just make sure libopenal.so.1 is
      the actual lib, not a symlink (or if it is a symlink, make sure it's
      pointing to the actual lib which is provided too).

       
      • fastrgv
        fastrgv
        2014-07-17

        Thanks, Chris. That will gives me all kinds of alternatives and I'm
        certain one or more will work for me.
        Incidentally, check out "RufasGate" and "RufasCube", which are 2 of my
        games on sourceforge.
        Rod

        On Wed, Jul 16, 2014 at 8:57 PM, Chris chris-kcat@users.sf.net wrote:

        On 07/16/2014 07:10 PM, fastrgv wrote:

        I downloaded the latest (1.15.1) on 15jul14 and built as usual. Went
        into the build directory and typed "cmake .." followed by "make".

        That did not produce a static lib so in another build directory,
        after changing CMakeLists.txt line 81 to SET(LIBTYPE STATIC) I went
        thru same process and got libopenal.a and manually put all libs into
        /usr/local/lib/OpenAL/. The openal build seemed to go smoothly.

        So, for my app, here is the build script:
        [...]

        The above
        script works fine. But when I replace one line with:
        /usr/lib/x86_64-linux-gnu/libopenal.a \ ( I replaced ".so" with
        ".a") the build also succeeds with no errors, but the command line
        executable simply hangs...and I have to ^c to kill it.

        Hmm, do you know how to use gdb to get a backtrace? Run gdb with your
        app from the terminal:

        $ gdb ./myapp

        Then at the gdb prompt, run the app:

        (gdb) run

        When the program hangs, press ctrl-c to cause a SIGINT and drop back to
        a gdb prompt. Then you can do this to get a backtrace on all threads:

        (gdb) thread apply all backtrace

        There could be quite a bit of output depending on how many threads are
        currently running on the app, but it would be good to have them in case
        the main thread isn't the culprit.

        This is on ubuntu 14.04 and I had months ago downloaded thru the
        system the approved ubuntu version of openal-dev and I noticed it had
        no static lib which makes me suspicious.

        Generally speaking, it's not recommended to use OpenAL as a static lib.
        Like OpenGL, users could have different implementations for their
        system. This isn't as much of an issue on Linux where there aren't any
        hardware-specific OpenAL drivers, but it's still a good idea to leave
        OpenAL as a dynamic lib so users can easily update to newer versions
        that may have more features, better performance, or just generally work
        better.

        You can, of course, still provide a version of the dynamic libs you use
        if you don't want to require the end user to install any prerequisites.
        You can do this easily using the linker's $ORIGIN rpath feature.

        https://www.technovelty.org/linux/exploring-origin.html

        Essentially, if your app is in /some/path (such that the executable is
        /some/path/myapp), you can use the $ORIGIN rpath to make the app look in
        /some/path (or some place relative to it) for dynamic libraries at
        run-time. If you then move myapp to /some/other/path, it will then look
        relative to /some/other/path automatically.

        It's as simple as adding -Wl,-rpath='$$ORIGIN' to the Makefile's link
        command (the double $$ is so make passes $ORIGIN to the command line,
        otherwise it would try to expand an ORIGIN variable, and the '' quotes
        so the shell won't expand it either) and placing libopenal.so.1 with the
        executable. Alternatively, you can do -Wl,-rpath='$$ORIGIN/lib' and have
        your program's hierarchy like this:

        ./myapp (the executable)
        ./lib/libopenal.so.1
        ./lib/libSomethingElse.so.0
        etc

        Then so long as myapp and the lib folder stay relative to each other,
        it'll pick up the dynamic lib there. Just make sure libopenal.so.1 is
        the actual lib, not a symlink (or if it is a symlink, make sure it's
        pointing to the actual lib which is provided too).


        Sent from sourceforge.net because you indicated interest in
        https://sourceforge.net/p/openal-soft/wiki/Home/

        To unsubscribe from further messages, please visit
        https://sourceforge.net/auth/subscriptions/