1

I'm trying to use log4cplus in conjunction with SDL to make a little graphic application.
I'm using minGW and Eclipse CDT on windows.

My problem is that whenever I use the library, my SDL window is not shown. Instead I get this on the console [New Thread 2624.0x1270] and that is it. No error message, no compilation/linking problem, nothing (see edit for precisions).
If I don't use the library, a similar message appears on the console and then disappears, and my SDL window is shown properly.

Below is an example of this behavior. If I comment the two lines starting with "Logger ", then everything is fine. If I do not, SDL window is not shown.

Edit: I've tried using just the logging library and commenting all the other code but this fails as well somehow. I cannot put a breakpoint on the logger code, eclipse tells me: Breakpoint attribute problem: installation failed and the code don't seem to be executed.

*Edit2:*I was on the wrong track, see my post below. Problem kind of solved.

Any Idea?

#include <stdlib.h>
#include <SDL/SDL.h>
#include <SDL/SDL_endian.h> /* Used for the endian-dependent 24 bpp mode */
#include "Screen.h"

#include <log4cplus/logger.h>
#include <iomanip>

using namespace log4cplus;

int main(int argc, char **argv) {

         if ( SDL_Init(SDL_INIT_VIDEO) < 0 ) {
            fprintf(stderr, "Impossible d'initialiser SDL: %s\n", SDL_GetError());
            exit(1);
        }

      SDL_Surface *screen;

         screen = SDL_SetVideoMode(640, 480, 32, SDL_SWSURFACE);
         if ( screen == NULL ) {
             fprintf(stderr, "Impossible de passer en 640x480 en 16 bpp: %s\n", SDL_GetError());
             exit(1);
         }

    Logger root = Logger::getRoot();
    Logger log_1 =  Logger::getInstance(LOG4CPLUS_TEXT("test.log_1"));

         while(true)
         {
             SDL_Event event;
             SDL_WaitEvent(&event);

                        switch (event.type) {
                            case SDL_KEYDOWN:
                                printf("La touche %s a été préssée!\n",
                                       SDL_GetKeyName(event.key.keysym.sym));
                                    //SDL_Quit();
                                break;
                            case SDL_QUIT:
                                exit(0);
                        }

                        Screen::DrawPixel(screen,20,20,200,10,10);
         }
}
David R.
  • 11
  • 3
  • I see that you have found your problem, so just a note about the code above. You need to initialize log4cplus before you try to use it. Add `#include ` and call `BasicConfigurator::doConfigure();` to get minimal setup with logging to `std::cout`. – wilx Feb 05 '11 at 09:09

2 Answers2

0

I have no experience with log4cplus, but I do know that you should be aware that SDL does some obnoxious rewiring of stdout and stderr.

I was going to say that you should move your Logger setup to after your SDL_Init call, but I just noticed that you don't even have one. Try calling SDL_Init before setting up your display.

TheBuzzSaw
  • 8,648
  • 5
  • 39
  • 58
  • Thanks for your input. I corrected the code to reflect the changes I've made. Alas, this does not solve the issue. I tried to declare the logger before and just after the SDL_Init call also but the problem stays the same. How do people work when they want to log something using SDL?? – David R. Feb 04 '11 at 20:17
  • @David: Write your own logger or try a different library if log4cplus makes problems? :) – Xeo Feb 04 '11 at 22:33
0

I found the problem. I hadn't noticed the error gdb gave me when running the program: " gdb: unknown target exception 0xc0000135". In fact the program didn't start at all.

This means it could not load a dll because of some path problems. I tried putting the dll I use for log4cplus in the system path, tried other workarounds like starting eclipse from but to no avail. One way I found to make it work is simply to put the dll in the Debug folder.

The problem with this gdb error is quite widespread (see google). This is not a proper fix, but I will live with it for the time being, so I consider the problem solved.

David R.
  • 11
  • 3
  • 1
    Why isn't that a proper fix? Most of the win32 deployments I've seen just bundle any needed DLLs right next to the executable. Strange that sticking it in the system directory didn't work though. – genpfault Feb 04 '11 at 23:02