#507 When SDL_Sound is not detected, maybe give stronger feedback in configure

[Patryk Obara]

Mounting CUE files with imgmount works in 0.74-2, but it's broken in 0.74-3

Example, Worms (Steam version), Linux, 0.74-2 (official Fedora package):

imgmount D "worms.cue" -t iso -fs iso
MSCDEX installed.
Drive D is mounted as worms.cue

-t iso was probably never supported (according to README file), but it works the same as -t cdrom

Using 0.74-3, SVN:

imgmount D "worms.cue" -t cdrom -fs iso
Could not load image file: worms.cue
MSCDEX: Failure: Invalid file or unable to open.

[Patryk Obara]

Forgot to mention, multiple games are affected: Worms (Steam), Tomb Raider (with software rendering, Steam), Heroes of Might and Magic 2 (GOG)… I presume a lot more.

[Qbix]

That sounds bad. I did test HoMM. Let me see if I can fix it.

[Qbix]

I can't really reproduce it.

I did:
dosbox ~/.wine/drive_c/GOG Games/HoMM 2 Gold

and then in dosbox
imgmount d HOMM2.INS -t cdrom -fs iso
and it seems to work fine..

are you sure that SDL_Sound has been detected ?

[Qbix]

can you give some more details ?
do you have the headers/development packages for SDL_Sound installed ?

[Patryk Obara]

Right, SDL_sound was installed, but SDL_sound-devel was not - configure didn't complain about missing dependency and everything compiled and I saw no warnings (maybe missed compilation time warnings?).

I was reproducing in Linux dosbox, SVN branch 0_74_3, r4249. Using configuration file supplied with GOG Windows HOMM2 with paths translated to Linux paths:

minimal set of steps I used to reproduce (when running in installation directory, in subdirectory DOSBOX):

Z:\>mount C ..
Z:\>C:
C:\>imgmount D "../homm2.ins" -t iso -fs iso

These steps in 0.74-2 result in:

MSCDEX installed.
Drive D is mounted as ../homm2.ins

In 0.74-3 compiled when SDL_sound-devel is missing (both -t iso and -t cdrom):

Could not load image file: ../homm2.ins
MSCDEX: Failure: Invalid file or unable to open

0.74-3 compiled when SDL_sound-devel is installed - works like 0.74-2. So people receiving packages from distributions most likely won't be affected :).

In the process of re-testing I found something surprising though: imgmount works only if invoked while on C:. When invoked on Z: it results in error (same description, happens on 0.74-2 and 0.74-3 with SDL_sound and without SDL_sound) - but it's rather low priority, considering most people will have C: .

Just to be sure I poured through README if I missed list of dependencies when compiling it for the first time and found no reference to SDL_sound... So "fix" for this would updating configure or even simply documentation?

[edit] aha! there is a warning configure: WARNING: Can't find libSDL_sound, libSDL_sound support disabled. Maybe consider making it an error instead?

[edit2] If this should be a warning, then different error message would also be helpful: "MSCDEX: Failure: No support for mounting this type of file" (something like that).

[Patryk Obara]

Seems like I can't edit the bug post-creation. So this is not a regression and should not have priority '2' (assuming it's a high priority). This is not a blocker for Linux packages.

[Qbix]

yeah, the C: is a bit odd, but not a regression. I think it might have to do with the paths specified inside the cue file. (as there is some name translation going on)

I modified the title of the bug report to mention the sdlsound configure not being clear enough.
I agree that the mounting failure message could be improved, but using it with sdl_sound installed has been almost the case, so it slipped through.

the compilation "requirements" are in INSTALL, not README. README is for running DOSBox,
INSTALL for compiling. Maybe that is wrong according to you ?

[Patryk Obara]

No, it's fine - I remember people on forum referring to README as "developer documentation", so that's probably why I didn't even look into INSTALL file, which is obviously my problem :)

Since compressed audio (which triggers this feature on/off) is optional, but presumed to be enabled, maybe it's worthwhile to change configure warning to error and hide it behind ./configure --disable-sdl-sound for builds, that don't need it? This way most people new to compiling DOSBox won't hit this problem.

[Qbix]

Yeah, I am not sure yet which direction I want to change it, but it should be improved.

[Joel Croteau]

Yes, this definitely needs a better error message. It seems like there are several things that can cause this "Invalid file or unable to open" message, from trying to open compressed audio when SDL_Sound is not linked to confusing case-sensitive and case-insensitive file names or just missing files or invalid compressed audio, is there any way at present to actually debug what specific thing is causing this error besides just throwing solutions at the wall to see what sticks?