Experimental Branch: Unresolved symbols dsfml-audio

[jebbs]

Experimental Branch: Unresolved symbols dsfml-audio

[Jebbs]

Thanks for trying this stuff out!

I wouldn't exactly call the Experimental version "stable" but I was able to compile everything before I uploaded so that is pretty strange. It probably has something to do with the difference between compiling on Windows and compiling on Linux.

undefined references usually mean that a function was prototyped, but the implementation isn't being linked in properly

This is my guess for what is happening(though I'm not sure why it decides to compile for me and not you) as I was still experimenting with a few things. I should be able to fix this sometime today.

[Jebbs]

Just to follow up on this, I'm not sure why you were having these issues with SoundFile since the cpp file was included. Not that it matters too much since in the process of working out the best way of laying out the code I decided to do SoundBuffer in the CSFML way again which will remove SoundFile dependency.

It'll probably be a little bit before I make a commit that fixes this since I am in the middle of getting the sound recording working(been having some array related issues), but I'll try to get it done soon.

[Jebbs]

Another follow up!

I should be able to do another commit tomorrow/Tuesday which will remove the dependency on libsndfile as well as finish off the Audio module. Eventually I'll write a D file for OpenAL and remove that dependency in the C build system as well, but that's a project for the future.

For some reason I couldn't get recording to work like how I got sound/music playing, but I'm not sure why. I don't know how you feel about this, but I will only be including SoundBufferRecorder without any SoundRecorder base class. If I ever get around to working on porting that OpenAL header I'll try to see if I can get it working, but for now I don't care. :)

Did you get any undefined references other than SoundFile?

[aubade]

As far as I know, no other undefined references. I think ld will print all the unresolved symbols and not just stop after the first file with them, but those were the only ones reported when I tried to link this.

It's worth noting that the symbols it complained about not being there were listed in libsfml-audio.so when I ran nm(the program that will list all the symbols in a library), which was why the error was so puzzling to me.

This is what nm -C /usr/lib/libsfml-audio.so | grep SoundFile produces: (Listing all the symbols in that file, showing only ones containing the string SoundFile--forgive me if the clarification seems patronizing, but I've known the gnu tools to be kind of arcane to those not used to 'em.)

0000000000008510 T sf::SoundBuffer::initialize(sf::priv::SoundFile&)
0000000000009560 t sf::priv::SoundFile::initialize(SF_INFO)
0000000000009580 t sf::priv::SoundFile::getFormatFromFilename(std::string const&)
00000000000094a0 t sf::priv::SoundFile::read(short*, unsigned long)
0000000000009520 t sf::priv::SoundFile::seek(sf::Time)
00000000000094c0 t sf::priv::SoundFile::write(short const*, unsigned long)
0000000000008fa0 t sf::priv::SoundFile::Memory::read(void*, long, void*)
0000000000008db0 t sf::priv::SoundFile::Memory::seek(long, int, void*)
0000000000008e20 t sf::priv::SoundFile::Memory::tell(void*)
0000000000008da0 t sf::priv::SoundFile::Memory::getLength(void*)
0000000000008e40 t sf::priv::SoundFile::Stream::read(void*, long, void*)
0000000000008e90 t sf::priv::SoundFile::Stream::seek(long, int, void*)
0000000000008f10 t sf::priv::SoundFile::Stream::tell(void*)
0000000000008e30 t sf::priv::SoundFile::Stream::getLength(void*)
00000000000091b0 t sf::priv::SoundFile::openRead(void const*, unsigned long)
0000000000009060 t sf::priv::SoundFile::openRead(std::string const&)
0000000000009320 t sf::priv::SoundFile::openRead(sf::InputStream&)
000000000000aa20 t sf::priv::SoundFile::openWrite(std::string const&, unsigned int, unsigned int)
0000000000008ff0 t sf::priv::SoundFile::SoundFile()
0000000000008ff0 t sf::priv::SoundFile::SoundFile()
0000000000009010 t sf::priv::SoundFile::~SoundFile()
0000000000009010 t sf::priv::SoundFile::~SoundFile()
0000000000009050 t sf::priv::SoundFile::getSampleRate() const
0000000000009030 t sf::priv::SoundFile::getSampleCount() const
0000000000009040 t sf::priv::SoundFile::getChannelCount() const

[Jebbs]

Personally, I'd rather not rewrite SoundFile in D, but in order to remove the dependency on sndfile in CMake and keep things working how they are, I think it's what I am going to have to do.

For the time being, I need to rely on SFML's SoundFile class, but I want you to be able to build it as well. If possible, could you try to clear your cache in CMake and see if that corrects the problem? I had a similar problem that wouldn't let me build the other day.

[aubade]

I've actually been removing the Cmake build dir entirely every time I try rebuilding, and it always builds without errors, and afterwards, always the same error. :/ I've literally never seen an issue like this and it's really hard to google for a solution, so I'm having trouble finding someone to turn to for support.

[aubade]

Okay, after.. a lot of reading through GCC's manpages, I found a band-aid. Passing -Xlinker --unresolved-symbols=ignore-in-shared-libs makes ld stop complaining, and the resulting binary for my sfMod port plays music. (So SoundStream and its dependencies are definitely working! If you've got some test code that touches the SoundFile part of the API, I'll try that too, and see if that part's actually working. EDIT: It's not. :( I tried making a Music and playing it, and I get the unresolved symbols again.)

It's really weird that I'm having to do this, since I never do with the CSFML version.

[Jebbs]

I'm curious as to why you didn't get the same build errors with AudioDevice since it is added to the project in basically the same way.

You don't get these errors with CSFML is because everything is done internally rather than the new way that I am putting the API together. Maybe I'm crazy for reworking everything like this, but I for one like that C callbacks are no longer needed, and it'll make code separation 100% possible which will clean up the source code a lot.

My end goal is to make the C DSFML shared libs build as easily as CSFML does though. Thankfully it can be rewritten in D, but it just takes time.

I don't think you know how glad I am to hear that it's working! I'll go ahead and mark this as closed and open some new issues for making sure SoundFile and the openAL code get translated into DSFML to ultimately remove needing both of these when compiling DSFML's C code.

[aubade]

Truthfully, I am very excited for this, and look forward to migrating my project to it. Would you like help with the translation? sfMod and sfMidi were my first real projects with it, but as long as it's not too weirdly idiomatic, it doesn't seem hard to do the translating, just tedious, and that sort of thing I can help with!

[Jebbs]

It's really the Audio Module that's the most annoying. Everything else is going to be easy in comparison.

[Jebbs]

So I am currently in the process of cleaning up the code in the new audio module before I commit everything, and I think I actually managed to track this build error down.

The SoundFile.cpp associated with the SoundFile.hpp from SFML wasn't actually included. It was a different SoundFile.cpp that was included in the system. I'll just do a little renaming and you shouldn't encounter this anymore.

[Jebbs]

I just committed a bunch of code that should have finished the Audio Module. Please let me know if you still get these unresolved references when you go to build it!

[aubade]

That did it! :D Both Music, and my own dsfMod work great :D

[aubade]

Although, I do get the following message when I run it. I don't know if it's a cause for concern, or if it's upstream SFML's fault:

AL lib: alcOpenDevice: Option 'format' is deprecated, please use 'channels' and 'sample-type'

(My OpenAL is OpenAL Soft v 1.14)

[Jebbs]

I don't know if there's anything I can really do about that. Looks like you just happen to have a newer version than the one that's used for Mac and Windows, and SFML is using a now deprecated feature.

You only get the warning when you build the library, right? Not every time you run an application based on it? That would be super annoying.

[aubade]

Unfortunately, it is every time I run the application. But if it's a call being made from upstream SFML, I'll file a bug with them and not here. :)