# SFML How are Symbols Loaded?

## Recommended Posts

I am getting the message : <information not available, no symbols loaded for  sfml-graphics-d-2.dll> when hovering over the sf::Text object name for Visual C++ using Visual Studio (SFML).  I am wondering how do I load the symbols so I can view the text object's text for example?

Thank you,

Josheir

##### Share on other sites

You need a .pdb file in your working directory. You should check your library for a debug symbol download or if you compiled it yourself, locate the .pdb and copy to your working dir.

##### Share on other sites
Just now, h8CplusplusGuru said:

if you compiled it yourself, locate the .pdb and copy to your working dir.

Well I am using someone else's library and dll (SFML's,) so I don't know if this applies to me.  I did look for evidence for what you said and located the following pdbs that were created by the IDE upon my build.  They are :  textbox.pdb and vc141.db.  These are for my textbox project and they seem to already be in the correct debug library with the executable and the dlls.

When I put the pdb called sfml-graphics-d.lib into this directory there is a change in the sf:text's  'readout in the IDE when debugging.'  No more pesky "symbols haven't been loaded,"  However there is still no readable display of the length or actual text.

The dll is numbered 2 and the pdb I am using is apparently for the first dll.  So, is there a solution?,  I have had to display to the screen in a separate rendering window to see the values and debug things.  I have found no specific pdbs/downloads for the library I am mentioning.

Sincerely and thankfully,

Josheir

Edited by Josheir

##### Share on other sites
On 10/7/2017 at 4:23 PM, Josheir said:

Well I am using someone else's library and dll (SFML's,) so I don't know if this applies to me.

It does. You need the .pdb files for the SFML binaries you are using. You either need to get them from the same place you got the binaries, or you need to recompile SFML yourself in order to generate them.

On 10/7/2017 at 4:23 PM, Josheir said:

I did look for evidence for what you said and located the following pdbs that were created by the IDE upon my build.  They are :  textbox.pdb and vc141.db.  These are for my textbox project and they seem to already be in the correct debug library with the executable and the dlls.

On 10/7/2017 at 4:23 PM, Josheir said:

When I put the pdb called sfml-graphics-d.lib

A PDB file should have a .pdb extension. That doesn't look like it's actually a PDB file. It also has to match the binary of the SFML library; you can't neccessarily just grab some other random SFML .pdb, say, from a game that uses SFML and shipped it for some reason, and drop it in to your project. They won't match.

Get the PDBs from the source you got the SFML library from. If they aren't supplied, build the library yourself.

## Create an account

Register a new account

• 11
• 9
• 11
• 9
• 12
• ### Similar Content

• Hi guys, so I have about 200 files isolated in their own folder [physics code] in my Visual Studio project that I never touch. They might as well be a separate library, I just keep em as source files in case I need to look at them or step through them, but I will never actually edit them, so there's no need to ever build them.
However, when I need to rebuild the entire solution because I changed the other files, all of these 200 files get rebuilt too and it takes a really long time.
If I click on their properties -> exclude from build, then rebuild, it's no good because then all the previous built objects get deleted automatically, so the build will fail.
So how do I make the built versions of the 200+ files in the physics directory stay where they are so I never have to rebuild them, but
do a normal rebuild for everything else? Any easy answers to this? The simpler the better, as I am a noob at Visual Studio settings. Thanks.
• By jonwil
I am writing a level editor using Visual C++ and the win32 API. I have the game engine going working fine with Direct3D 11 (its not an off-the-shelf engine, its custom)
The plan for the editor is to have something like this:

The blue bit is going to be a standard win32 menu bar, the yellow bit will be a standard win32 status bar, the red bit will contain things like a list of objects to insert into the level (its contents will change depending on what the user is doing) and the purple bit will be a window that will be rendered into by the rendering code. I know how to do Direct3D11 rendering into a window that is the parent window and is the only thing the app is drawing (the engine runs a loop that lets the windows message loop run and process its messages before running the engine code and doing rendering) but I can't find anything out there on how you do Direct3D graphics (11 or otherwise) into a child window and how you handle things like resizing and painting and things. Its definitely possible since so many level editors and things do it but I dont know how they pull it off. (and Google isn't showing anything useful either)
Are there any examples out there of how you can create a win32 custom control/child window, set up a IDirect3D11Device to draw onto that window and then have that window play nice with all the other windows (the main parent window and the other child windows) whilst still triggering a once-per-frame render call to allow me to draw my stuff in there.
• By Jules W
Hey guys...I found a great channel on youtube. I was always a Unity guy and got pretty good in it. But finally I ended up with doing stuff on my own without a specific engine. I love the freedom of it
I found monogame and I found this guy...he is a professional programmer in AAA games studio and shows really cool stuff for 2d MMORPG and server-client stuff!! Defenitly check it out...!

Have fun

• By Dr.Gonzo
This article discusses how to debug native Android applications using Microsoft Visual Studio Code, which can be useful for game developers implementing background services, prototyping, or other native processes on the Android platform.
Of course, Android Studio and Visual Studio 2017/2015 also offer Android debugging capabilities, but they're more restrictive with the configuration environment and only allow debugging of applications packaged in an APK - so we are unable to debug any native processes we might be using to prototype, develop services, or other native processes on Android.
Speaking of APKs, note that VSCode also supports debugging APKs via the Android extension.

Prerequisites
The following components are required to enable debugging:
Visual Studio Code with the C/C++ extension installed.
GNU Debugger (GDB) from the Android NDK.
OS Path Windows <NDK_ROOT>\prebuilt\windows-x86_64\bin Linux <NDK_ROOT>\prebuilt\linux-x86_64\bin macOS <NDK_ROOT>\prebuilt\darwin-x86_64\bin
A build of the target project with debugging enabled. This can be achieved by passing NDK_DEBUG=1 on the ndk-build command line, or by adding it to the project's Application.mk file. Enabling NDK_DEBUG also causes ndk-build to copy the correct version of gdbserver to the project's output directory. This will need to be copied to the target device to enable the debugger connection. Also, if the project's Application.mk file specifies the APP_OPTIM setting, it must be set to debug to disable compiler optimizations. While debugging optimized code it possible, it will be a more limited and difficult debugging experience. Optimization can be disabled by passing APP_OPTIM=debug on the ndk-build command line, or by modifying it in the project's Application.mk file.
If the project does not specify the APP_OPTIM setting, setting NDK_DEBUG as described above will automatically disable optimizations.
Debugging Setup
Before debugging the first time, open the project workspace in VSCode and perform the following steps:
Open the Debug menu and click Add Configuration... Choose C/C++ (gdb) Launch as the configuration type. If this option is not available the C/C++ extension is not installed and none of this is going to work.
Configure the debugger settings for the project. The required attributes are described below.
Attribute Description name The name of the debugging task. This is the name that will be displayed in the UI. type Should be set to cppdebug. request Should be set to launch. program The program to debug. This should point to the local version of the executable with debug symbols (the non-stripped version), which is normally in obj/local/armeabi-v7a under the project's build directory (or obj/local/arm64-v8a for 64 bit builds). cwd Doesn't really have any effect, but is required. Can just be set to ${workspaceFolder}. MIMode Should be set to gdb. miDebuggerPath The path to the gdb executable. This should point to the directory in the Android NDK as indicated above. miDebuggerServerAddress The target address to connect to. Since the device is connected via USB, this should be set to localhost:<port>, where <port> is the TCP port chosen for the debugger connection. This same port must be used when starting gdbserver on the device. additionalSOLibSearchPath Any additional local paths to search for debug symbols. The directory specified for the program attribute will automatically be searched first. This should point to the directories of the non-stripped versions of any additional shared libraries to be debugged (if they are not in the same directory as the main executable). Separate multiple paths with a colon. setupCommands An array of additional gdb commands to be executed during setup of the debugger. This needs to be used to execute the set solib-absolute-prefix command to set the local path to the stripped version of all binaries being debugged. preLaunchTask A task to execute before starting the debugger. See the section below about defining tasks in VSCode. The other attributes created for the default configuration can be deleted. Example launch.json file { "version": "0.2.0", "configurations": [ { "name": "Remote GDB", "type": "cppdbg", "request": "launch", "preLaunchTask": "Forward debug port", "cwd": "${workspaceRoot}", "program": "${workspaceRoot}/app/Intermediate/android/myapp/local/armeabi-v7a/myapp", "additionalSOLibSearchPath": "${workspaceRoot}/app/Intermediate/android/mylib/local/armeabi-v7a", "miDebuggerServerAddress": "localhost:5039", "setupCommands": [ { "text": "set solib-absolute-prefix ${workspaceRoot}/app/path/android", "ignoreFailures": false } ], "windows": { "miDebuggerPath": "C:/Tools/android-ndk-r13b/prebuilt/windows-x86_64/bin/gdb.exe", "MIMode": "gdb" } } ] } Refer to the C/C++ debugging documentation for additional information. In particular, the logging attribute can be used to enable additional logging output, which can be useful for troubleshooting if the debugger is not working as expected. Preparing to Debug With the debugger configuration set, there are some additional steps required to debug the project: Copy the target binaries to the target device. Copy gdbserver to the target device. Starting the Debugger With all preparations complete, it's time to start debugging. Use the same port number in these steps as was used in the debugger configuration above. Execute gdbserver on the target device (execute permissions may need to be enabled). The server can be run in two modes: execute or attach. Execute mode will load the target executable and then wait for a client to attach. When the client attaches it will begin execution of the program. This mode is necessary to debug an application's initialization. Attach mode will attach to an already running process. It will not interrupt the process. Mode Command Run mode gdbserver :<port> <exe> Attach mode gdbserver :<port> --attach <pid> Forward the debugger port from the device with ADB: adb forward tcp:<port> tcp:<port> Start the debugger in VSCode. Enable the Debug panel by clicking the bug icon on the left side of the VSCode window. Select the debug configuration from the list at the top of the panel. Click the go button to launch the debugger. Once the debugger starts to connect, the VSCode debug console will display messages from the debugger and allow manual debugger commands to be executed if necessary (the program must be stopped to execute debug commands). The debug panels will display debugging information (variable watches, callstacks, breakpoints, etc.), and a debugger toolbar will provide access to common debug commands. Mouse cursor based display of variables is also supported. Tasks VSCode also supports the definition of tasks, which can be used to execute any command line process, typcially as part of building and/or testing code. These tasks can also be used to support debugging. For instance, a task could be defined to forward the debugger port. This could then be incorporated in the debugger configuration using the preLaunchTask attribute to ensure the port is forwarded before attempting to connect the debugger. Tasks can be configured by selecting Configure Tasks... from the Tasks menu. See the VSCode documentation for more information about task configuration. Example tasks.json file { "version": "2.0.0", "tasks": [ { "label": "Forward debug port", "type": "shell", "command": "adb", "args": [ "forward", "tcp:5039", "tcp:5039" ], "presentation": { "reveal": "never" }, "problemMatcher": [] } ] } • By Mr_Mauve Im trying to wrap my head around Entity Component Systems and was implementing my own based on others examples. I have a very basic stripped down version working without systems but as ive started to implement the systems im getting a linker error complaining about unresolved externals. 1>InputSystem.obj : error LNK2019: unresolved external symbol "public: class VelocityComponent * __thiscall Entity::getComponent<class VelocityComponent>(void)const " (??$getComponent@VVelocityComponent@@@Entity@@QBEPAVVelocityComponent@@XZ) referenced in function "public: virtual void __thiscall InputSystem::update(float)" (?update@InputSystem@@UAEXM@Z) As i understand its complaining that in InputSystem::update() it cannot find the implementation of Entity::getComponent<T>(). InputSystem inherits from system which includes Entity.h.
If i move the implementation of getComponent<T>() from Entity.cpp into Entity.h then everything compiles fine. I thought when including a .h the associated .cpp is compiled along with it into an object file then the linker grabs all that to generate the final executable.