Mac OS builds for >= 10.9 have no sound playing

Bug #1825925 reported by SirVer
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
widelands
Fix Released
Critical
Unassigned

Bug Description

I recently started building nighlies also for >= 10.9 mac os versions. While testing them I realized that on some computers they do not produce any audio output. The console logs show no errors. I tested the following builds on laptops that never have build widelands before:

1) Old school Nightly builds (>= 10.7) [1]. This works with sounds and no noticable problem.
2) New school nightly builds (>= 10.9) [2]. This works, but without sounds.
3) Toni's build of build 20-rc1 [3]. Same as 2), i.e. no sounds.

My hunch is that this is a problem of the build environment: very likely, SDL mixer is tying to dynamically load ogg & vorbis and does not find the libraries. Why this is not outputting any error on the console I do not know. If my suspicions are correct, sound *will* play on a computer that has build widelands, because those dynamic libraries will be installed in the place that sdl2 expects to find them, but sounds will *not* play on a computer that never built widelands before.

[1] http://www.widelands.org/~sirver/wl/macos_daily/MACOS_10_7_OR_HIGHER/widelands_10.7_r9059.dmg
[2] http://www.widelands.org/~sirver/wl/macos_daily/MACOS_10_9_OR_HIGHER/widelands_10.9_r9059.dmg
[3] https://launchpad.net/widelands/build20/build20-rc1/+download/widelands_10.9_build-20-rc1.dmg

Tags: macos sounds

Related branches

Revision history for this message
SirVer (sirver) wrote :

Setting this to critical, since we should not release with a mac binary without sound.

Stonerl, can you verify if you can reproduce?

Changed in widelands:
milestone: none → build21-rc1
importance: Undecided → Critical
milestone: build21-rc1 → build20
GunChleoc (gunchleoc)
tags: added: macos sounds
Revision history for this message
SirVer (sirver) wrote :

I found an old revision of building widelands on mac: https://wl.widelands.org/wiki/history/Building_Widelands_on_macOS/changeset/11/. It mentioned that I used to have a branch of homebrew that build static libraries for sdl. I assume that this problem is related, following my prior hunch.

Revision history for this message
Ken Cunningham (kencu) wrote :

It looks like the dylibs in the bundle are needing to have their ids properly set:

$ otool -L libSDL2-2.0.0.dylib
libSDL2-2.0.0.dylib:
 /usr/local/opt/sdl2/lib/libSDL2-2.0.0.dylib (compatibility version 8.0.0, current version 8.0.0)
 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
 /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
 /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
 /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
 /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 492.0.0)
 /System/Library/Frameworks/ForceFeedback.framework/Versions/A/ForceFeedback (compatibility version 1.0.0, current version 1.0.2)
 /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.5.0)
 /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 22.0.0)
 /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 158.0.0)
 /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
 /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1561.0.0)
 /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1443.13.0)
 /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1125.1.1)
 /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 822.5.0)
 /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1443.14.0)

Revision history for this message
SirVer (sirver) wrote :

Ken, if you have the libraries installed in your system path, it seems that it prefers that (with Otool -L). Because if you download the < 10.9 nightly ([1] above), the otool output looks similar, but sound is played. Can you confirm?

Revision history for this message
Ken Cunningham (kencu) wrote :
Download full text (51.0 KiB)

Hi -- actually when I download the dmg #2 above and try to run it, I just get a crash that I think is happening because the library name is wrong.

Don't all the dylibs in the macOS bundle need to be install_name_tool -id 'd as @executable_path/myname.dylib ?

Process: widelands [4060]
Path: /Applications/Widelands.app/Contents/MacOS/widelands
Identifier: org.widelands.wl
Version: r9059 (r9059)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: widelands [4060]
User ID: 501

Date/Time: 2019-04-22 22:56:32.914 -0700
OS Version: Mac OS X 10.14.4 (18E226)
Report Version: 12
Anonymous UUID: 634B7103-0C6F-212F-7C32-6CA9B0415D80

Time Awake Since Boot: 210000 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Illegal instruction: 4
Termination Reason: Namespace SIGNAL, Code 0x4
Terminating Process: exc handler [4060]

Application Specific Information:
/Applications/Widelands.app/Contents/MacOS/widelands

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libSDL2-2.0.0.dylib 0x000000010120a3ea SDL_DYNAPI_entry + 67
1 libSDL2-2.0.0.dylib 0x0000000101211e6b SDL_InitDynamicAPI + 144
2 libSDL2-2.0.0.dylib 0x000000010120e37b SDL_LogSetOutputFunction_DEFAULT + 18
3 org.widelands.wl 0x0000000100fcf503 0x100acc000 + 5256451
4 dyld 0x000000010e095592 ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 506
5 dyld 0x000000010e095798 ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40
6 dyld 0x000000010e090bea ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 362
7 dyld 0x000000010e08fd73 ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 133
8 dyld 0x000000010e08fe05 ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 73
9 dyld 0x000000010e07f765 dyld::initializeMainExecutable() + 199
10 dyld 0x000000010e084709 dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 6213
11 dyld 0x000000010e07e503 dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) + 1167
12 dyld 0x000000010e07e036 _dyld_start + 54

Thread 1:
0 libsystem_pthread.dylib 0x00007fff75cf03f0 start_wqthread + 0

Thread 2:
0 libsystem_pthread.dylib 0x00007fff75cf03f0 start_wqthread ...

Revision history for this message
Toni Förster (stonerl) wrote :

Ken & SirVer: Could you try this build please?

https://fosuta.org/widelands_10.9_build-20-rc1.zip

Revision history for this message
Ken Cunningham (kencu) wrote :

One more to fix:

Application Specific Information:
dyld: launch, loading dependent libraries

Dyld Error Message:
  Library not loaded: /usr/local/Cellar/libvorbis/1.3.6/lib/libvorbis.0.dylib
  Referenced from: /private/var/folders/*/Widelands.app/Contents/MacOS/libvorbisfile.3.dylib
  Reason: image not found

running this:

sudo install_name_tool -change /usr/local/Cellar/libvorbis/1.3.6/lib/libvorbis.0.dylib @executable_path/libvorbis.0.dylib libvorbisfile.3.dylib

and it works for me here, with sound!

Revision history for this message
Ken Cunningham (kencu) wrote :

I'm not sure if every dylib is exercised on opening. maybe there could be another reference or two to be discovered.

I haven't used http://macdylibbundler.sourceforge.net/ a lot, tried it a few times. I thought it was supposed to make this automagical!

Revision history for this message
Ken Cunningham (kencu) wrote :

btw -- to test this yourself, you should be able to just temporarily move /usr/local to /usr/local-back and then run the widelands application.

AFAIK, everything in /usr/local is optional stuff that homebrew has added, and it can be moved out of the way any time for testing what an end-user without homebrew might see.

Revision history for this message
Toni Förster (stonerl) wrote :

I used macdylibbundler for the zip-file. For the DMG we use the python script.

Revision history for this message
Toni Förster (stonerl) wrote :

Ken did you test the zip file? You can't move /usr/local without disabling System Integrity Protection.

Revision history for this message
Ken Cunningham (kencu) wrote :

Yes, that error in comment #7 above was with the zip file.

Revision history for this message
Ken Cunningham (kencu) wrote :

Mmm. If homebrew is adding stuff to /usr/local, it must be getting around SIP. Perhaps the subfolders of /usr/local can be stored.

I will admit I don't use homebrew, as MacPorts works nicely on my older systems and on every system since then, so I haven't played around in /usr/local much.

Revision history for this message
Toni Förster (stonerl) wrote :

Ken would you try this one please?

https://fosuta.org/widelands_10.9_build-20-rc1.dmg

Revision history for this message
Ken Cunningham (kencu) wrote :
Download full text (5.7 KiB)

I wrote up a little script -- run it from the directory in the bundle where all the executables and dylibs are:
-----
for file in *; do
    echo ${file}
    otool -L ${file} | grep local
done
------

I named it dyliblocalchecker, but call it whatever you want.

If all is well, you should see only the file names, with no other printout.

Your *.zip file was pretty close, looks like there were only a few more dylib paths left to fix:

$ ~/bin/dyliblocalcheckerdata
/opt/local/libexec/llvm-3.9/bin/llvm-objdump: 'data': Is a directory
libGLEW.2.1.dylib
libSDL2-2.0.0.dylib
libSDL2_image-2.0.0.dylib
libSDL2_mixer-2.0.0.dylib
libSDL2_ttf-2.0.0.dylib
libboost_chrono-mt.dylib
libboost_regex-mt.dylib
libboost_system-mt.dylib
libboost_timer-mt.dylib
libboost_unit_test_framework-mt.dylib
libfreetype.6.dylib
libicudata.64.dylib
libicui18n.64.dylib
libicuuc.64.dylib
libintl.8.dylib
libjpeg.9.dylib
libjpeg.dylib
 /usr/local/opt/jpeg/lib/libjpeg.9.dylib (compatibility version 13.0.0, current version 13.0.0)
libmodplug.1.dylib
libogg.0.dylib
libogg.dylib
 /usr/local/opt/libogg/lib/libogg.0.dylib (compatibility version 9.0.0, current version 9.3.0)
libpng.dylib
 /usr/local/opt/libpng/lib/libpng16.16.dylib (compatibility version 54.0.0, current version 54.0.0)
libpng16.16.dylib
libtiff.5.dylib
libvorbis.0.dylib
libvorbis.dylib
 /usr/local/opt/libvorbis/lib/libvorbis.0.dylib (compatibility version 5.0.0, current version 5.8.0)
 /usr/local/opt/libogg/lib/libogg.0.dylib (compatibility version 9.0.0, current version 9.3.0)
libvorbisfile.3.dylib
 /usr/local/Cellar/libvorbis/1.3.6/lib/libvorbis.0.dylib (compatibility version 5.0.0, current version 5.8.0)
libvorbisfile.dylib
 /usr/local/opt/libvorbis/lib/libvorbisfile.3.dylib (compatibility version 7.0.0, current version 7.7.0)
 /usr/local/Cellar/libvorbis/1.3.6/lib/libvorbis.0.dylib (compatibility version 5.0.0, current version 5.8.0)
 /usr/local/opt/libogg/lib/libogg.0.dylib (compatibility version 9.0.0, current version 9.3.0)
libwebp.7.dylib
libz.1.dylib
widelands

unfortunately the dmg you just sent has all the dylib ids wrong again. They need to be id'd as @executable_path/myname.dylib.

$ ~/bin/dyliblocalchecker

data
/opt/local/libexec/llvm-3.9/bin/llvm-objdump: 'data': Is a directory
libGLEW.2.1.0.dylib
 /usr/local/opt/glew/lib/libGLEW.2.1.dylib (compatibility version 2.1.0, current version 2.1.0)
libSDL2-2.0.0.dylib
 /usr/local/opt/sdl2/lib/libSDL2-2.0.0.dylib (compatibility version 10.0.0, current version 10.0.0)
libSDL2_image-2.0.0.dylib
 /usr/local/opt/sdl2_image/lib/libSDL2_image-2.0.0.dylib (compatibility version 3.0.0, current version 3.2.0)
libSDL2_mixer-2.0.0.dylib
 /usr/local/opt/sdl2_mixer/lib/libSDL2_mixer-2.0.0.dylib (compatibility version 3.0.0, current version 3.2.0)
libSDL2_ttf-2.0.0.dylib
 /usr/local/opt/sdl2_ttf/lib/libSDL2_ttf-2.0.0.dylib (compatibility version 15.0.0, current version 15.0.0)
libboost_chrono-mt.dylib
 /usr/local/opt/boost/lib/libboost_chrono-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
libboost_regex-mt.dylib
 /usr/local/opt/boost/lib/libboost_regex-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
libboost_system-mt.dylib
 /usr/local/opt/boo...

Read more...

Revision history for this message
SirVer (sirver) wrote :
Download full text (4.5 KiB)

Ken, Toni, thanks for all your activity here! A few rebuddles:

> Don't all the dylibs in the macOS bundle need to be install_name_tool -id 'd as @executable_path/myname.dylib ?

It was my understanding that the IDs do not matter (since they are only a textual identifier without meaning to the dynamic linker), only the dependencies (i.e. lines 2 and later in otool -L <>), but having the IDs not changed makes the output of otool -L harder to read.

> I haven't used http://macdylibbundler.sourceforge.net/ a lot, tried it a few times. I thought it was supposed to make this automagical!

Actually, the python tool we use in Widelands was made out of frustration of macdylibbundler, which did not properly recurse. It's source was very hard to understand and it seemed abandoned, so I did not try to fix the upstream, replacing it with our Python script. Toni, the bugs are probably the reason why it did not work for the ZIP file either.

I modified the Python script to change the IDs and to not confuse the IDs with dependencies (this was a bug in the script, changes attached in the merge request attached to this bug), after this change I created a new build. After which running this I get:

otool -L WidelandsRelease/Widelands.app/Contents/MacOS/*.dylib WidelandsRelease/Widelands.app/Contents/MacOS/widelands | grep -v ':$' | grep -v @executable_path | sort -u
 /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1671.10.106)
 /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 492.0.0)
 /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)
 /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 158.0.0)
 /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 23.0.0)
 /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
 /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1443.13.0)
 /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1560.12.0)
 /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1247.4.1)
 /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 934.0.0)
 /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.5.0)
 /System/Library/Frameworks/ForceFeedback.framework/Versions/A/ForceFeedback (compatibility version 1.0.0, current version 1.0.2)
 /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1560.12.0)
 /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
 /System/Library/Frameworks/Metal.framework/Versions/A/Metal (...

Read more...

Revision history for this message
Toni Förster (stonerl) wrote :

Thanks allot for the script. I do have a solution.

This is my out put now:

data
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/objdump: 'data': Is a directory
libGLEW.2.1.0.dylib
libSDL2-2.0.0.dylib
libSDL2_image-2.0.0.dylib
libSDL2_mixer-2.0.0.dylib
libSDL2_ttf-2.0.0.dylib
libboost_chrono-mt.dylib
libboost_regex-mt.dylib
libboost_system-mt.dylib
libboost_timer-mt.dylib
libboost_unit_test_framework-mt.dylib
libfreetype.6.dylib
libicudata.64.2.dylib
libicui18n.64.2.dylib
libicuuc.64.2.dylib
libintl.8.dylib
libjpeg.9.dylib
libjpeg.dylib
libmodplug.1.dylib
libogg.0.dylib
libogg.dylib
libpng.dylib
libpng16.16.dylib
libtiff.5.dylib
libvorbis.0.dylib
libvorbis.dylib
libvorbisfile.3.dylib
libvorbisfile.dylib
libwebp.7.dylib
libz.1.2.11.dylib
widelands

Revision history for this message
Toni Förster (stonerl) wrote :

Ken, just to double-check, would you please test the DMG again? The link is the same, I just changed the file.

https://fosuta.org/widelands_10.9_build-20-rc1.dmg

Revision history for this message
Toni Förster (stonerl) wrote :

Ups, it seems we overlapped...

Revision history for this message
GunChleoc (gunchleoc) wrote :

I'll leave it up to you guys which solution you prefer. Thank you all for looking into this!

Revision history for this message
Ken Cunningham (kencu) wrote :

Both of the new versions from SirVir and from Toni work flawlessly for me on Mojave (I have no libs in /usr/local on this system). I get sound, and no crashes or hiccups. Haven't dug in to any detail, but I think we've answered / solve the sound & crash issues.

GunChleoc (gunchleoc)
Changed in widelands:
status: New → Fix Committed
Revision history for this message
SirVer (sirver) wrote :

Late reply: Thanks for the help with testing, Ken!

Thanks for the fast turn around Toni!

Revision history for this message
GunChleoc (gunchleoc) wrote :

Fixed in build20

Changed in widelands:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.