Messages

1

General / Re: window.draw() hangs in GDB

« on: May 30, 2017, 02:49:36 am »

Sorry send post button too soon.  In another post that you replied to me.  You mentioned Fedora 25 having SFML.  I checked and was overjoyed for a while.  So I reformatted my hard drive and re-installed Fedora 25 and installed SFML.  However, the repository only have release versions of SFML.  No debug versions.  I did try GDB on it, but it would continually cause "blah, blah, blah is not responding ... (Force quit or Wait)".  So I'm going to take a break for a bit.  I'll come back later, unless you think I should go to a Code Blocks, or GDB, or gcc type forum.

2

General / Re: window.draw() hangs in GDB

« on: May 30, 2017, 02:38:26 am »

I thought it was weird too.  As stated before, I am a newb.

The output I sent you started from window.draw().  The GDB overran the text clipboard.

When I first started debugging.  I was using a GUI front end (Code Blocks) to GDB.  When I used the step-into button, I was repeatedly (visually) sent to the following file.  /usr/include/c++/6.3.1/bits/basic_string.h.  So I figured I should run GDB by itself and step through window.draw().  After stepping through the SFML files, the following output (or similar output) pops up, repeatedly.

After stepping through the SFML files, folllowing (or similar) happens:
[debug]> step
[debug]std::__cxx11::basic_string<unsigned int, std::char_traits<unsigned int>, std::allocator<unsigned int> >::_M_local_data (this=0x7fffffffe480) at /usr/include/c++/6.3.1/bits/basic_string.h:142
[debug]/usr/include/c++/6.3.1/bits/basic_string.h:142:4747:beg:0x7ffff76f6404
[debug]>>>>>>cb_gdb:

The text file I sent is the output GDB gives me as I repeatedly input the step command.

Was just thinking.  I probably don't have debug versions of the standard c++ library/STL.  Judging from your last reply, do you think this is a GDB error or my own?

3

General / Re: window.draw() hangs in GDB

« on: May 29, 2017, 04:38:58 pm »

if use the run command in GDB, it runs fine.  If I put a break point at anywhere except on the line with window.draw().  The GDB command continue functions as I would expect.  If the break point is at window.draw(), the continue command instigates  the OS into popping a message saying "SFML works!" is not responding.

If I input the next command on window.draw().  The program "seemingly" hangs.  Program execution seems to halt.  However, nothing on the screen is locked.  Using the Code Blocks Debug menu, I can stop the debugger and even call up a watch window, stack window, and memory dump window.  However, these windows are blank.

If I am using just plain old GDB. Nothing execpt Cntrl^Z does anything. After Cntrl^Z, the executable has been stopped and I can input any GDB command.

If i input the step command on window.draw().  I step into it seemly well, but I never get out.  The attachment is the debugger output of me stepping.  basic_string.h seems to be the favorite file that keeps getting cycled back to.

Let me know if I can give you more info.

4

General / window.draw() hangs in GDB

« on: May 29, 2017, 01:45:31 pm »

Well here's what I have.

Fedora 25 (uses wayland emulating X)
build from source (debug and release), SFML 2.4.2 (using CMake, Code::Blocks, and gcc version 6.3 ) (afraid to update gcc)
using gdb version 7.12 (the latest update)
have updated Intel graphics driver (i915)
compiled test file using the C++14 standard
updated the lib path
applied the Git patch (the one that makes changes to CMake)

I'm compiling and running one of the tutorial codes found in the Learning Section of this web site.  I compile with 0 errors 0 warnings. I can run both debug and release versions with no problems.

However, when trying to use GDB (on the debug version), the program hangs at window.draw().  I'm not sure if it actually hangs or if I haven't waited long enough for GDB to come out of window.draw().  The longest I've waited was probably 3 minutes.  I've stepped into the function and I seem to go into an endless loop of the same called functions that make up window.draw().

I was getting the segmentation fault until I did the Git patch. I don't know what else to do. I checked the web, the answer was to update gdb or my graphics driver. both are up to date.  I want to be able to use GDB.  I haven't tried another debugger yet.

The following is the test code I used.

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(200, 200), "SFML works!");
    sf::CircleShape shape(100.f);
    shape.setFillColor(sf::Color::Green);

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }

        window.clear();
        window.draw(shape);
        window.display();
    }

    return 0;
}

5

General / Re: Getting undefined reference LIBJPEG_8

« on: May 29, 2017, 01:16:29 pm »

Still a newb at this.  libjpeg-turbo just doesn't have libjpeg.so.8, so I don't think pointing to its lib directory would do any good.  As for a symbolic link, if i understand correctly that would be the same as a reference (in C++).  So would I type the following, for a symbolic link?

ln -s /file/path/<file that emulates libjpeg.so.8> libjpeg.so.8

Then I could build from source just like normal?

6

General / Getting undefined reference LIBJPEG_8

« on: May 26, 2017, 05:36:01 pm »

Not sure if I got the error message correct.  Please correct me if I am wrong.

This isn't a asking for help post.  Its an answer post, for other newbies like me, so that they don't have to go through the nightmare I went through of searching and failing.

I'm using Linux/Fedora 25 and Code::Blocks IDE.

I've been having problems compiling anything that calls SFML.  I'm getting undefined reference errors. So I decided to compile SFML from source.

I found most everything I needed within a few minutes with the commands:

dnf whatprovides <the file I need or symbol I need> 
dnf install <the package I need>

(Have to run the above commands as root)

The big bear of a problem to find was LIBJPEG_8.  Fedora 25 uses a package called libjpeg-turbo to implement the libjpeg library.  This library emulates libjpeg v8.  So it doesn't have the libjpeg libraries SFML needs.  Also, it seems that libjpeg v8 is emulated in a lot of other distros.  So the file libjpeg.so.8 that SFML needs was seeminly nowhere to be found.  After days of searching, I found it in

https://rpmfind.net/linux/RPM/mageia/1/x86_64/media/core/updates/lib64jpeg8-8b-5.1.mga1.x86_64.html

When you want to find a file SFML needs;

https://www.rpmfind.net/

is your friend.

I hope this post helps many others.

7

General / Re: Procedure entry point in xxxxxx not located in the libstdc++-6.dll

« on: May 01, 2017, 10:18:49 pm »

I know this is very late.

Thank you, so very much, eXpl0it3r for replying.  I probably would have spent another week trying different configurations and not getting anywhere.

8

General / Re: Procedure entry point in xxxxxx not located in the libstdc++-6.dll

« on: April 24, 2017, 07:59:25 am »

I deleted  and then re-installed Code::Blocks and the fork, Mingw32-64.  Then deleted the Mingw that came with Code::Blocks.  Using CMake; built the Release and Debug Versions of SFML (32-bit, SJLJ).  Tested it. Worked.

Less than a minute after i ran the test program, I figured out what I did wrong.

What I did wrong was I downloaded SFML (Dwarf), but my Code::Blocks compiler was (SJLJ).  Codeblocks uses the TDM version of MinGW.

For those of you having installation problems, I found out there are two different compilers for the gcc family that aren't labeled as such. Dwarf and SJLJ.  The difference between them is the way each one handles exceptions.  You can't mix (Dwarf and SJLJ) compilers, executables, object code, and DLL's .  They all have to be the same type; one or the other. 

One weekend. Down the drain.

9

General / Re: Procedure entry point in xxxxxx not located in the libstdc++-6.dll

« on: April 23, 2017, 03:40:57 am »

Thanks.  After I did a rebuild, I got ... I'll try your suggestion and and bulid SFML with the MinGW64. Going to let my brain rest first. Went to the MinGW64 forum and there was a jumbled mess on what to do about migrating from MinGW32 to MinGW64.

10

General / Re: Procedure entry point in xxxxxx not located in the libstdc++-6.dll

« on: April 23, 2017, 12:41:48 am »

Sorry,

I clicked the "Build" button vs. the "Re-Build" button after pointing to the correct version of Mingw. Now I'm getting compiler errors.

I'm guessing I still have incorrect dll's like you said. I'll keep looking.

11

General / Procedure entry point in xxxxxx not located in the libstdc++-6.dll

« on: April 23, 2017, 12:17:38 am »

Hi,

I've just installed SFML and went through the"Getting Started SFML and Code::Blocks (MinGW)" tutorial.  I compiled the tutorial code provide and got 0 errors, 0 warning, 0 etc ...

When I run it, I get the following error message:

The procedure entry point _ZNKSt7 __cxx1112basic_stringIcSt11char_traitsIcEsaIcEE3endEv cound not be located in the dynamic link library libstdc++-6.dll.

I've set Mingw compiler to point to the forked Mingw64.

Can anyone help?