Topic: Odd linker messages

[SteveS]

I have modified my CD ripping software to use BAsS encoding rather than rely on an external encoder (in my case LAME).

However, I have a question.
Previously, I have used the linker command

g++ -o ripper ripper.o -lbasscd -lbass

so that the CD add-in is loaded without me having to do anything in the code.

Can I do the same with the encoding and the MP3 plugin, so it would be

g++ -o ripper ripper.o -lbassenc -lbassenc_mp3 -lbasscd -lbass

I have tried this, but I see the following output by the linker, which suggests I shouldn't be doing this:

/usr/bin/ld: /usr/local/lib/libbassenc_mp3.so: .dynsym local symbol at index 3 (>= sh_info of 3)
/usr/bin/ld: /usr/local/lib/libbassenc_mp3.so: .dynsym local symbol at index 4 (>= sh_info of 3)
/usr/bin/ld: /usr/local/lib/libbassenc_mp3.so: .dynsym local symbol at index 5 (>= sh_info of 3)
/usr/bin/ld: /usr/local/lib/libbassenc_mp3.so: .dynsym local symbol at index 6 (>= sh_info of 3)
/usr/bin/ld: /usr/local/lib/libbassenc_mp3.so: .dynsym local symbol at index 7 (>= sh_info of 3)
/usr/bin/ld: /usr/local/lib/libbassenc_mp3.so: .dynsym local symbol at index 8 (>= sh_info of 3)
/usr/bin/ld: /usr/local/lib/libbassenc_mp3.so: .dynsym local symbol at index 9 (>= sh_info of 3)

[Ian @ un4seen]

That linker command looks fine. Please confirm what GCC version it is and on what platform/architecture (x86_64 Linux?). Also confirm that you're using the latest versions of the BASS libraries, and whether you're only seeing those messages about libbassenc_mp3.so.

[SteveS]

It is bookworm linux (64-bit, aarch64) on a Raspberry Pi 4, with stock gcc (12.2.0)
I only see the messages for libbassenc_mp3.so, not for any other libraries.

(Apologies for the delay; we're packing up to move house, hopefully before Christmas, so some of the things I have been doing have been "re-prioritised", as my wife so tactfully puts it...)

[Ian @ un4seen]

Seems a bit strange that it's only happening with libbassenc_mp3.so. All of the current BASS libraries are built with the same compiler, so I would expect them all to be affected by such an issue. Is it definitely the latest version of libbassenc_mp3.so? Please check the BASS_Encode_MP3_GetVersion return value to confirm, when you have some time

[SteveS]

I was sure it was the latest set of .so files, the version returned is v2.4.1.6 (0x2040106).
If it isn't the right one, I might have a slightly different issue.  I used ldd to determine that it was actually pulling in the .so from where I thought it was, and I also downloaded the zips (again) and did a binary cmp from the one in the zip to the one in the path displayed by ldd.


I also used readelf -a on the .so file to see if that told me anything, and it lists the symbols as below:
l
     3: 0000000000030559     0 NOTYPE  LOCAL  DEFAULT   22 __bss_start__
     4: 0000000000040fc8     0 NOTYPE  LOCAL  DEFAULT   22 _bss_end__
     5: 0000000000030559     0 NOTYPE  LOCAL  DEFAULT   21 _edata
     6: 0000000000040fc8     0 NOTYPE  LOCAL  DEFAULT   22 __bss_end__
     7: 0000000000040fc8     0 NOTYPE  LOCAL  DEFAULT   22 _end
     8: 0000000000040fc8     0 NOTYPE  LOCAL  DEFAULT   22 __end__
     9: 0000000000030559     0 NOTYPE  LOCAL  DEFAULT   22 __bss_start
Don't know it that's any help.
 
I assume that if I want to use the various encoders, (FLAC, Ogg, MP3, OPUS), that I do need to link the relevant .so file, rather than use BASS_PluginLoad, which I would to enable decoding/playback support?
If I didn't, I wouldn't be able to call the appropriate BASS_Encode_XXX_StartFile function.


The resulting executable does work, but it does seem a bit strange...

[SteveS]

On a related issue, I am also converting some m4a files to mp3 for a playback unit that doesn't support m4a.

To do this, I used BASS_Init (0, 44100, 0, NULL, NULL) to set the output frequency to 44.1KHz (same as CD quality, and what I use in my CD ripping software.

I then load the AAC decoder plugin ("libbass_aac.so" in my case), so that I can use BASS_StreamCreateFile (0, filename, 0, 0, BASS_STREAM_DECODE) to open the source.

I call BASS_Encode_MP3_StartFile with the resulting handle, plus my options.
Then, I repeatedly call BASS_Channel_GetData until I reach the end of the stream, then call BASS_Encode_Stop.

This produces a valid MP3 file, but the frequency is 48KHz, not 44.1KHz.
I presume this is because the source is at 48KHz. Is there any way to set the output frequency as I want it, or would I have to use some external process (ffmpeg?) to do this?

[A short time later...]
Ignore that, I am being stupid. If I had taken the time to read the LAME documentation as well, I would have known that "--resample 44.1" will do what I want, while "--resample 44100" is quietly ignored

Apologies, now working as I wanted, and files converted.

[Ian @ un4seen]

I also used readelf -a on the .so file to see if that told me anything, and it lists the symbols as below:
l
     3: 0000000000030559     0 NOTYPE  LOCAL  DEFAULT   22 __bss_start__
     4: 0000000000040fc8     0 NOTYPE  LOCAL  DEFAULT   22 _bss_end__
     5: 0000000000030559     0 NOTYPE  LOCAL  DEFAULT   21 _edata
     6: 0000000000040fc8     0 NOTYPE  LOCAL  DEFAULT   22 __bss_end__
     7: 0000000000040fc8     0 NOTYPE  LOCAL  DEFAULT   22 _end
     8: 0000000000040fc8     0 NOTYPE  LOCAL  DEFAULT   22 __end__
     9: 0000000000030559     0 NOTYPE  LOCAL  DEFAULT   22 __bss_start
Don't know it that's any help.

Yep. I checked a bunch of the BASS libraries myself with readelf just now, and the add-ons (not only libbassenc_mp3.so) all had the "local symbol" warning messages shown but not libbass.so for some reason. They don't seem to prevent anything working, but I'll look into what's the best way to avoid them (it seems to be related to the binutils version that's used in building the libraries). One way you can avoid them right now is to use the "gold" linker, by adding "-fuse-ld=gold" to the command-line.

[SteveS]

Yes, that will do it, although I also had to specify -L/usr/local/lib so that the libraries could be found at link time. Since I'm using a Makefile, I did only have to change my definition for LDFLAGS, so it wasn't exactly difficult...

Thanks.