SFML community forums
Help => Audio => Topic started by: orm on May 30, 2010, 08:49:07 pm
-
Don't know what it is. I have checked the headers myself and everything liooks good as far as I can tell.
In file included from /usr/include/SFML/Audio/SoundStream.hpp:31:0,
from /usr/include/SFML/Audio/Music.hpp:31,
from /usr/include/SFML/Audio.hpp:34,
from /home/orm/Engine-CL/theengine/../osound/OSoundCommon.h:18,
from /home/orm/Engine-CL/theengine/../osound/OSound.h:13,
from /home/orm/Engine-CL/theengine/Engine2DCommon.h:16,
from /home/orm/Engine-CL/theengine/Application.h:5,
from /home/orm/Engine-CL/theengine/Application.cpp:1:
/usr/include/SFML/Audio/Sound.hpp:52:10: error: expected identifier before ‘int’
/usr/include/SFML/Audio/Sound.hpp:53:5: error: expected unqualified-id before ‘{’ token
In file included from /usr/include/SFML/Audio/Music.hpp:31:0,
from /usr/include/SFML/Audio.hpp:34,
from /home/orm/Engine-CL/theengine/../osound/OSoundCommon.h:18,
from /home/orm/Engine-CL/theengine/../osound/OSound.h:13,
from /home/orm/Engine-CL/theengine/Engine2DCommon.h:16,
from /home/orm/Engine-CL/theengine/Application.h:5,
from /home/orm/Engine-CL/theengine/Application.cpp:1:
/usr/include/SFML/Audio/SoundStream.hpp:48:18: error: expected unqualified-id before ‘int’
/usr/include/SFML/Audio/SoundStream.hpp:48:18: error: expected ‘;’ before ‘int’
/usr/include/SFML/Audio/SoundStream.hpp:48:18: error: declaration does not declare anything
/usr/include/SFML/Audio/SoundStream.hpp:49:18: error: no members matching ‘sf::Sound::Stopped’ in ‘class sf::Sound’
/usr/include/SFML/Audio/SoundStream.hpp:50:18: error: no members matching ‘sf::Sound::Paused’ in ‘class sf::Sound’
/usr/include/SFML/Audio/SoundStream.hpp:51:18: error: no members matching ‘sf::Sound::Playing’ in ‘class sf::Sound’
make[2]: *** [CMakeFiles/Engine2D.dir/theengine/Application.o] Error 1
make[1]: *** [CMakeFiles/Engine2D.dir/all] Error 2
make: *** [all] Error 2
I am using the current package available in the ArchLinux repositories and am linking with sfml-system and sfml-audio in that order.
-
Which version of SFML is it?
-
1.6-1 is the version in the AUR (Archlinux User Repository)
-
Weird, in SoundStream.hpp at line 48 I have
using Sound::Status;
And in Sound.hpp at line 52, I have
enum Status
Which seems completely unrelated to your error messages.
Do you do something special in your own headers before including SFML? Have you tried compiling a very simple application using sfml-audio, outside your engine?
-
I would think that Status was put into the sound namespace, so it's just calling on the Status enum.
Strange though. And no, I am just including the sfml headers in a separate module of the engine. Everything is very compotenized in my framework, so the sound headers and sources only include what they need.
-
What is your version of gcc?
Have you tried recompiling the SFML "sound" sample?
-
g++ is 4.5+. Latest.
Don't tell me, sfml is incompatible with latest g++?
-
Don't tell me, sfml is incompatible with latest g++?
I don't think so. At least it works with gcc 4.4 on Windows, and so far you're the only one to report such an error. And there's really nothing complicated in these headers.
-
I'm getting the exact same error on the same line when compiling the sound header.
I'm using gcc 4.4.3.
Did anyone find a solution for this? I've never even seen this compiler error before and a glance at the code doesn't suggest that anything should be wrong with it. Indeed, the same file has compiled for me with Visual Studio.
-
I've been messing with this compile error for the past three hours and I'm at my wits end here.
I think it may be a corrupted file encoding or something. Oddly, when I remove only the comments from the file, the line error jumps around from the enum Status to various functions near the end of the class definition. But apart from being on a different line, the error is always the same:
error: expected identifier before ‘int’
error: expected unqualified-id before ‘{’ token
Suspecting a missing brace in one of the header files, I commented them out completely but the error remains.
Oddly enough, changed the file encoding in Code::Blocks also cause the error line to jump around. This suggests to me that the .cpp files have been corrupted in some way. My next move is to rewrite the code into a new .cpp file but this is a LAST resort and may not even work if my theory is wrong.
Any help is greatly appreciated. My whole project compiles in linux now, it's just this silly bug that is holding up the whole project.
-
What you can do is to copy and rename the class (so that the rest still compiles), and then remove code from it line by line until the error disappears.
-
SFML is in Arch Linux official repo now so you can easily get it from there (thanks to yours truly, I am just that awesome).
-
Svenstaro - I tried SFML from the Arch linux repo. But I'm still getting the same compile error.
Laurent- I'm going try doing some surgery on the files.
This really sucks.
-
What exactly did you do? The SFML in Arch repos is binary already so what did you try to compile?
-
I'm no expert linux programmer, but I've done a bit in the past. Maybe I'm setting things up incorrectly.
1. I include the SFML audio header into my own Audio sub-system.
2. I add the SFML/include directory to the compiler search path.
3. I place the .so libraries in my project root folder.
Compiling fails at the Sound.hpp header file.
After some experimentation, I was able to get it to compile, but only by chaning all references to the 'Status' enum and renaming it 'SoundState'. But since I only changed the headers this is giving me linker errors. It seems like a naming conflict, but I don't see how that is possible since it's inside a namespace.
So I'm still stuck here. Am setting up the build environment correctly?
-
You are doing it like on Windows. On Linux you won't have to set up all that stuff manually. I'm going to assume that you have installed the SFML package from community.
Do this in a terminal:
wget http://sfml-dev.org/tutorials/1.6/sources/audio-sound.cpp
g++ -lsfml-audio -lsfml-system audio-sound.cpp
That's all you have to do to generate a working sfml binary! Run the resulting a.out file (it will require a sound.wav to actually work).
-
Svenstaro- Thanks for you help. This linux stuff is daunting.
I eventually managed to get that compile error to disappear. Its been a really frustrating experience, because I still have no idea what the exact problem was. But through much trial and error I determined that the NAME of the Status enum defined in Sound.hpp was simply not going to work.
In the end, all I did was rename the enum variable from "Status" to "Stat:. I know it sounds ridiculous, but that let everything compile and run.
I HAVE NO CLUE WHY. I hate 'mystery' crap like this so any insight would be appreciated. Heck, I'd even take a wild theory at this point because I have no idea why this name change would have this affect.
-
Hey, thanks for your help :)
Maybe now I'll be able to figure out what's wrong.
-
By the way, do you include any other header before <SFML/Audio.hpp>? Does this error happen when you compile this simple example?
#include <SFML/Audio.hpp>
int main()
{
return 0;
}
-
I'm not including anything before Audio.hpp.
I'll try to compile that minimal test. Right now I'm under the gun to get this linux build finished.
-
kiaran, did my minimal example work out of the box for you?
-
Svenstaro - I manually installed the SFML package and pointed my binary to local versions of the libraries. I'm hoping this makes it easier to distribute my application this way since it's more self-contained it should be less error prone.
I looked into installing the public package from the gcc tutorial but it doens't make any sense to me. From the tutorial:
Once you have downloaded and extracted the files to your hard drive, you must install the SFML headers and library files to the appropriate location. To do so, you just have to go to the SFML-x.y directory and type "sudo make install".
Where is the SFML-x.y directory in the download? I don't see it.
Edit: So no, I wasn't able to get your minimal example working because I haven't installed SFML in a system-wide way.
-
Why do not install SFML system wide? Any users wanting to play your game will only have to get SFML from your their repos and be able to play it. In Linux land you won't have to provide all deps yourself, that's the nice thing.
EDIT: If you really want SFML to be statically linked, why not do that?
-
Yeah, I think I will take a stab at statically linking it. I know not all open source software licenses (SDL) let you do that. I was being cautious by dynamically linking.
The reason I don't want to rely on system-level libraries is because I really don't want the headache of supporting less technically inclined users with questions about missing dependencies. When you buy a game it should 'just work'.
I was looking at how World of Goo does it. They basically run the game from a shell script which points the binary to a local directory to search for needed libraries before looking to the global usr/lib folder.
export LD_LIBRARY_PATH="./libs":"$LD_LIBRARY_PATH"
I'm not crazy about using a shell script to launch the game, but I can't statically link everything my game uses... so lesser of two evils I guess.
-
Indeed, I usually do it with the LD_LIBRARY_PATH thing but only if the dependencies are outdated on the usual distributions. The problem is that it blows up your game package's size almost to Windows levels and you will have to provide two architectures too.
I usually try to keep the headache small for myself and let packagers of other distributions package my games. Why not safe yourself the trouble as well?
What license are you using that you would get trouble with statically linking, by the way? If you choose GPL for your application, you will get no problems, no matter what license they are.
-
Well, this a commercial product so it's not going to be available in any repo anywhere or anything.
I was planning on just having a download .tar with a shell script that checks for the 32/64bit and points to the correct binary/libraries.
Regarding statically linking: I'm using SDL and I think I read somewhere that you can only statically link it into an open source program, which mine is definitely not.
I'm only using SFML for it's nice interface with OpenAL. On a completely unrelated note, I tried porting my project to SFML for window management and input a while ago but ran into too many issues so I just had to abandon. But I'm happy with the mix of components I'm using now. I wrote an article about it if you care to see exactly what I'm doing:
http://www.bigfatalien.com/?p=110
-
You can still get around it and make everyone happy (and yourself too!) by opensourcing the engine and making the game commercial. That should work nicely to your advantage as well.
-
Open sourcing the engine is something I'm looking into. B
But I'm using commercial 3d software for level design which I don't think would be very useful to many people. Still, if someone really wanted to they could build their own content pipeline without my toolset...
-
If you can use a common output format for the levels (which is a good idea in any case) you can also use other software for that.