▲

[Howard]

BASS_StreamCreateFile fails with BASS_ERROR_INIT(8) for FLAC/AAC on Linux standalone build - plugins confirmed correctly registered, works fine under IDE debugger

Environment:
- BASS core 2.4.18.3 (Linux, libbass.so)
- BASSFLAC 2.4.6.1, BASS_AAC 2.4.7.2 (current versions per your own download page)
- Fedora Linux, x86-64
- App written in PureBASIC 6.40, compiled to a standalone executable

Symptom:
BASS_StreamCreateFile() fails with error code 8 (BASS_ERROR_INIT) for both FLAC and M4A/AAC files, consistently, in a standalone compiled build. MP3 (no plugin required) always plays correctly. The exact same code, same files, same plugins work correctly when run under the PureBASIC IDE's debugger - it's specifically the standalone executable that fails.

What I've ruled out so far, each with direct evidence:

1. BASS_Init() succeeds (confirmed via BASS_GetVersion() returning the correct value immediately after, and again immediately before the failing BASS_StreamCreateFile call).

2. Plugins load with valid, non-null handles from BASS_PluginLoad(), and BASS_PluginGetInfo() reports genuinely correct data - not just a plausible-looking formatc count, but the actual BASS_PLUGINFORM entries decode to real, correct strings:
   - libbass_aac.so: "Advanced Audio Coding" (*.aac), "Advanced Audio Coding MPEG-4" (*.m4a;*.m4b;*.mp4)
   - libbassflac.so: "Free Lossless Audio Codec" (*.flac;*.fla), "Free Lossless Audio Codec (Ogg)" (*.oga;*.ogg)
   (This took some digging - PureBASIC's default struct packing doesn't match C alignment rules, so BASS_PLUGINFORM needed Align #PB_Structure_AlignC to read correctly. Worth flagging in case anyone else hits this with PureBASIC bindings.)

3. Plugin load order relative to BASS_Init() - confirmed correct (plugins load only after BASS_Init succeeds).

4. Working directory / path resolution for both the core library and the plugins - confirmed consistent and correct via strace, matching what ldd reports for each library's own dependencies.

5. libbass.so getting loaded more than once in the same process (confirmed via pmap) - real, but confirmed via testing to be normal/harmless BASS behavior, not connected to this failure (same duplication occurs on runs where MP3 plays successfully).

6. RTLD_GLOBAL vs RTLD_LOCAL when loading libbass.so via dlopen() - added RTLD_GLOBAL explicitly (bypassing PureBASIC's OpenLibrary(), which only uses RTLD_LAZY, and calling the system dlopen() directly) based on a very similar-sounding thread here (topic 15847) where Ian confirmed this exact fix for a plugin registration issue. No change in behavior.

7. #BASS_UNICODE flag - removing it changes the failure to error 41 (BASS_ERROR_FILEFORM) and breaks MP3 playback too, so it's confirmed necessary and not the cause.

8. strace confirms the actual file is read completely and correctly at the OS level - full header parse, seek to the moov/metadata atom near the end of the file, sample-size table read sequentially in 4096-byte chunks, clean read() returning 0 at exactly the file's total size, clean close(). No I/O error anywhere in the sequence.

Given the plugins are provably, correctly registered, and BASS_Init()'s state is provably intact right up to the failing call, and the identical code/files/plugins work correctly under the IDE debugger - I'm out of ideas for what's specific to the standalone-vs-debugger environment that could cause this. Has anyone seen anything like this, or is there additional diagnostic output I could enable to see what's actually happening inside BASS_StreamCreateFile's internal format-matching logic?

Happy to provide a minimal reproduction case or any further diagnostics.

[Howard]

Follow-up, in case it helps anyone else who hits this.

Isolated it further with a direct comparison: same source, same BASS core, same plugin files, same PureBASIC version, same target Fedora machine to run on - the only thing that changed was which machine actually compiled the executable.

Executable compiled on Fedora, run on Fedora: fails (error 8) as described above.
Executable compiled on Linux Mint, copied over and run on that same Fedora machine: works perfectly, FLAC and AAC both.

So this was never a BASS or plugin issue at all - it's specific to something about how the executable itself gets built on Fedora versus Mint/Ubuntu. My leading theory was Fedora's default full RELRO/BIND_NOW linker hardening (Fedora has shipped full RELRO by default since F23) versus Debian/Ubuntu's default of partial RELRO only, since eager vs lazy symbol binding seemed like a plausible fit for a plugin failing to properly resolve back into the core library's symbols. I tried overriding it via PureBASIC's linker options file (-Wl,-z,lazy -Wl,-z,norelro) but that alone didn't resolve it, so that theory is unconfirmed - there may be some other Fedora-specific toolchain default at play, or it may be a combination of things.

Given I have a clean, reliable workaround (compile on Mint, deploy anywhere), I'm not going to keep chasing the exact mechanism for now. Posting this mainly so the Fedora-vs-Mint compile-host distinction is documented here in case someone else runs into the same thing and searches for it.

Thanks again for the earlier pointer on the RTLD_GLOBAL issue - genuinely useful even though it turned out not to be the culprit this time.

[Ian @ un4seen]

That sounds strange. Please upload the working (Mint) and non-working (Fedora) executables to have a look at here:

    ftp://ftp.un4seen.com/incoming/

Please also try building the PLUGINS example included in the BASS package on the Fedora system (open the example's folder in Terminal and enter "make") and see if that works.