[SoundPlay] is broken since r39571

[diver]

SoundPlay doesn't work since hrev39571 and shows:

runtime_loader: /data/SoundPlay/lib/liblayout.so: Could not resolve symbol '__ti5BFont'
resolve symbol "__ti5BFont" returned: -2147478780
runtime_loader: /data/SoundPlay/lib/liblayout.so: Troubles relocating: Symbol not found

In hrev39617 error message has changed to:

KERN: runtime loader: /data/SoundPlay/SoundPlay: Could not resolve symbol 'aakzzzzzzz'
KERN: runtime loader: /data/SoundPlay/SoundPlay: Troubles relocating: Symbol not found

[bonefish]

The problem with SoundPlay is that the file is broken. Obviously the obfuscater did not fix the symbol hash table after renaming the symbols. hrev40211 works around the issue.

SoundPlay still doesn't load though, due to missing symbol next_chunk__13BMediaDecoderPvPPvPUlP12media_header. BMediaDecoder::next_chunk() is private in BeOS R5, so SoundPlay shouldn't use it. Changing component to Media Kit and leaving the decision what to do about it to whoever feels responsible.

[stippi]

Since SoundPlay is so popular, we should support it. I would have to look at BMediaDecoder again to see how complicated it is to export the symbol properly.

[diver]

With hrev40211 I now get:

runtime_loader: /boot/system/lib/libsupc++.so: Could not resolve symbol '_Unwind_GetIPInfo'
resolve symbol "_Unwind_GetIPInfo" returned: -2147478780
runtime_loader: /boot/system/lib/libsupc++.so: Troubles relocating: Symbol not found

[anevilyak]

That's somewhat odd, libsupc++ shouldn't be getting loaded at all as SP is a gcc2 app. What kind of hybrid are you on diver?

[diver]

I've just jam clean'ed and recompiled everything, still same error. It's gcc4hybrid.

[diver]

Ah, it was caused by libnetwork.so link, which I created earlier when I forgot to enable HAIKU_ADD_ALTERNATIVE_GCC_LIBS after binary search. I've removed it and now SoundPlayer crashes on start:

Thread 560 caused an exception: Segment violation
[...]
[Switching to team /data/SoundPlay/SoundPlay (560) thread SoundPlay (560)]
0x00002030 in ?? ()
(gdb) bt
#0  0x00002030 in ?? ()
#1  0x00908ad1 in __class_type_info::dcast () from /boot/system/lib/gcc2/libroot.so
#2  0x0090971f in __dynamic_cast () from /boot/system/lib/gcc2/libroot.so
#3  0x005a8e3a in MBorder::MBorder () from /data/SoundPlay/lib/liblayout.so
#4  0x00237889 in aaez ()
#5  0x00236dd4 in aahzzz ()
#6  0x00105607 in runtime_loader () from /boot/system/runtime_loader
#7  0x7ffeefec in ?? ()
(gdb)

[bonefish]

I tested with a gcc 2 hybrid build, which resulted in the aforementioned loader error due to the missing BMediaDecoder::next_chunk(). The obfuscation doesn't really help, but since the only program function called directly from runtime_loader() is the program entry, aahzzz() and aaez() in the stack trace must be _start() and main() respectively, which means that the program has been fully loaded already. I don't quite see why it wouldn't run into the missing symbol error, as the symbol really isn't there. Need to set up a gcc 4 hybrid build to check this...

BTW, what is the last known revision SoundPlay did work with? At least I seem to recall that it did work years ago.

[diver]

Last known revision is hrev39570.

[diver]

BTW, I get the same crash in in both gcc4hybrid and gcc2hybrid.

[axeld]

Replying to bonefish:

BTW, what is the last known revision SoundPlay did work with? At least I seem to recall that it did work years ago.

It did, but only version 4.7.3 - newer releases use some private media API that we don't duplicate. I don't recall when BMediaDecorder::next_chunk() has been renamed, but it shouldn't be that long ago.

[bonefish]

Replying to axeld:

Replying to bonefish:

BTW, what is the last known revision SoundPlay did work with? At least I seem to recall that it did work years ago.

It did, but only version 4.7.3 - newer releases use some private media API that we don't duplicate.

OK, that explains it, since I tested with 4.9.3. I can reproduce the crash with 4.7.3.

[ttcoder]

For what it's worth -- the builds I've made for TuneTracker Systems (including the latest one, 4.9.15) did away with the "secret API" hack... Or more accurately, usage of this hack has been moved to an external plugin, so that the linkage failure only prevents that one plugin from loading on Haiku, but the SoundPay core itself (and other plugins) successfully load and run. I don't know when/if these builds will be released as shareware to the public again like they were in the days of yore.. That's a decision Marco will have to make; for now he licensed the source code to us for inclusion in the TTS suite, not for public/shareware use AFAICT. Anyhow, if there is a way such that SoundPlay 4.9.3 can resolve all symbols and load on Haiku, even if just to fall back to "MediaKit" mp3 replay, then that'd be the fast-track solution to the problems you guys see, probably. Another option is just sticking to 4.7.3 to skip all the trouble I guess.. EDIT -- Also an info that is more relevant to the ticket at hand: the haiku nightly I'm working with is more recent than the ones mentioned (namely, hrev39648) and the latest/unreleased 4.9.x builds run fine on it, never seen the kind of error mentioned above; the "dynamic cast" error looks suspiciously like the issue I had with the KissLib preventing TuneStacker from loading though (#6963, #1259).

[bonefish]

Fixed the crash while starting in hrev40228. Now SoundPlay starts, but when quitting it crashes. Will have a look.

[bonefish]

Replying to bonefish:

Fixed the crash while starting in hrev40228. Now SoundPlay starts, but when quitting it crashes. Will have a look.

Happens only with gcc 4 hybrid. Apparently the media kit tries to load gcc 4 add-ons which seems to cause trouble. Not investigating any further. The runtime loader problem is resolved. Feel free to open new tickets for the remaining issues.