build trouble on os x 10.8, Xcode 5.0.1 about vimpc

[boysetsfrog]

What version of g++/gcc do you have there? Did ./autogen.sh and ./configure work?

[boysetsfrog]

Also, if reverting just that one commit makes it work. I will happily take it back out.

[nilsbecker]

g++ --version
Configured with: --prefix=/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix

both ./autogen.sh and configure seemed to work and passed without errors.
resetting to 9045114 doesn't change anything. i think it may be related to the new version of apple's compilers that comes with xcode 5. unfortunately i'm no expert on apple's tools.

[nilsbecker]

this is possibly related:

http://stackoverflow.com/questions/14177018/how-do-i-get-the-new-c-threading-support-on-mac-os-x-with-clang

but it's weird that problems arise after updating, which should give newer versions of the tools?

[nilsbecker]

following hints on SO, specifically

http://stackoverflow.com/questions/14149835/on-os-x-simple-c-program-gives-incorrect-results-which-are-a-result-of-comma?lq=1

i tried the following:

CXXFLAGS="-stdlib=libc++ -std=c++0x" ./configure

this did have an effect: the compilation fails much later, with

g++ -DHAVE_CONFIG_H -I. -I./src   -I/usr/local/include -DHELP_DIRECTORY='"/usr/local/share/doc/vimpc"'  -I/usr/local/Cellar/pcre/8.33/include     -D_THREAD_SAFE -pthread -stdlib=libc++ -std=c++0x -D__STRICT_ANSI__ -MT src/vimpc-song.o -MD -MP -MF src/.deps/vimpc-song.Tpo -c -o src/vimpc-song.o `test -f 'src/song.cpp' || echo './'`src/song.cpp
src/song.cpp:355:8: error: calling a protected constructor of class
      'Main::Settings'
   if (Main::Settings().Instance().Get(Setting::AlbumArtist) == true)
       ^
./src/settings.hpp:175:10: note: declared protected here
         Settings();
         ^
src/song.cpp:355:8: error: temporary of type 'Main::Settings' has protected
      destructor
   if (Main::Settings().Instance().Get(Setting::AlbumArtist) == true)
       ^
./src/settings.hpp:176:10: note: declared protected here
         ~Settings();
         ^
2 errors generated.

[nilsbecker]

also, since the original report, i have uninstalled xcode 5, and have instead installed the command line tools that come with xcode 5 as a separate package (available here https://developer.apple.com/downloads/index.action). this did not change my results.

[boysetsfrog]

That settings compilation failure is an entirely separate issue. Being that I legitimately broke the build two days ago when compiling without test enabled. I fixed this but am not sure on the commit number. I will look it up when I can. But since everything else is working for you now. If you go to the most recent commit you might be okay.

[boysetsfrog]

Settings compilation fix is this commit 0eb7d50

[nilsbecker]

ok, next try. i pulled the most recent master branch, set the apple provided stdlib and configured like this:

CXXFLAGS="-stdlib=libc++" ./configure --prefix=$HOME --program-prefix=my

it now compiles a long way until:

g++  -I/usr/local/Cellar/pcre/8.33/include     -D_THREAD_SAFE -pthread -stdlib=libc++ -D__STRICT_ANSI__ -std=c++11  -L/opt/local/lib -o vimpc src/vimpc-algorithm.o src/vimpc-buffers.o src/vimpc-clientstate.o src/vimpc-colours.o src/vimpc-errorcodes.o src/vimpc-mpdclient.o src/vimpc-output.o src/vimpc-player.o src/vimpc-screen.o src/vimpc-settings.o src/vimpc-song.o src/vimpc-vimpc.o src/buffer/vimpc-browse.o src/buffer/vimpc-library.o src/buffer/vimpc-directory.o src/mode/vimpc-command.o src/mode/vimpc-inputmode.o src/mode/vimpc-normal.o src/mode/vimpc-search.o src/window/vimpc-browsewindow.o src/window/vimpc-console.o src/window/vimpc-debug.o src/window/vimpc-directorywindow.o src/window/vimpc-error.o src/window/vimpc-help.o src/window/vimpc-infowindow.o src/window/vimpc-librarywindow.o src/window/vimpc-listwindow.o src/window/vimpc-modewindow.o src/window/vimpc-outputwindow.o src/window/vimpc-pagerwindow.o src/window/vimpc-playlistwindow.o src/window/vimpc-scrollwindow.o src/window/vimpc-selectwindow.o src/window/vimpc-songwindow.o src/window/vimpc-window.o src/window/vimpc-windowselector.o src/vimpc-main.o  -L/usr/local/Cellar/taglib/1.9.1/lib -ltag  -L/usr/local/Cellar/pcre/8.33/lib -lpcre -lpcrecpp  -L/usr/local/Cellar/libmpdclient/2.7/lib -lmpdclient   -lncurses
clang: warning: argument unused during compilation: '-pthread'
ld: warning: directory not found for option '-L/opt/local/lib'
Undefined symbols for architecture x86_64:
  "pcrecpp::RE::Init(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, pcrecpp::RE_Options const*)", referenced from:
      pcrecpp::RE::RE(char const*) in vimpc-algorithm.o
      pcrecpp::RE::RE(char const*) in vimpc-screen.o
      pcrecpp::RE::RE(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) in vimpc-settings.o
      pcrecpp::RE::RE(char const*) in vimpc-settings.o
      pcrecpp::RE::RE(char const*) in vimpc-song.o
      pcrecpp::RE::RE(char const*) in vimpc-vimpc.o
      pcrecpp::RE::RE(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) in vimpc-command.o
      ...
  "pcrecpp::RE::Replace(pcrecpp::StringPiece const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*) const", referenced from:
      PrepString(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool) in vimpc-algorithm.o
      Mpc::Song::SwapThe(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) in vimpc-song.o
      Ui::Command::Substitute(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) in vimpc-command.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

some troubles with a regular expression library not being found? i tried to reinstall pcre using homebrew but to no avail...

[boysetsfrog]

You may also need to install another library. Something like pcrecpp, pcrecxx or pcre++ something of that nature. It looks as though it can't find that library to link against.

[nilsbecker]

ok, sounds good. indeed there is a package pcre++ on homebrew which i now installed. unfortunately nothing changes. do i need to set the environment variable prce_LIB ? i tried that but so far without success.

what i find weird is that the compilation used to work with the previoux xcode, without any extra pcre and without specifying a different stdlib...

[boysetsfrog]

Well the addition of C++11 (std::function, std::thread, etc) to vimpc is a relatively recent merge, so I can understand why you may have had trouble initially and in this case found that changing stdlib has helped. Particularly with a platform like OSX that I don't have access to myself and so don't properly test with.

The pcre problem, I am not sure why that would pop up if things were working fine previously. It looks as though in what you pasted, when you link there is a specified -L"librarylocation" for most of your libraries save for pcrecpp and ncurses. Has that changed since you installed pcrecpp? You may be able to override the LDFLAGS environment variable to include the pcrecpp location. Something like LDFLAGS="$LDFLAGS -L/path/to/library" but I am not sure why this would be necessary. I will take a look at my configure.ac when I get a chance.

[nilsbecker]

no that has not changed. neither -I flags nor -L flags for the pcre++ location. only pcre.

[boysetsfrog]

As far as I can tell everything looks okay in the configure.ac it actually uses pkg-config for pcrecpp and it seems as though that is actually provided just by pcre alone, provided it was compiled with c++ support which appears to tbe the norm for anyone with a c++ compiler. I am not sure if it has something to do with the fact that pcrecpp is also a c++ library and you are specifying a different std library for vimpc to what pcre was probably compiled with. I just don't know.

I am trying to source some form of OSX to try and have a look myself and help you out, but I am not sure if that will happen, and since I have never used it, I might just end up even more lost than you are. Sorry for the annoyance.

[nilsbecker]

no problem. i have some more bits of information: i can go back and reset to v0.09.0-prethread; then everything builds fine when i remove the env variable for the alternative std library. with v0.09.0-prethread, the build fails again at pcrecpp etc. when CXXFLAGS="-stdlib=libc++" is set. so: everything builds fine with the gcc provided std library except for the fact that apparently some new features are not supported (at least in the version shipped with the latest xcode) while the apple-provided stdlib does include these missing features, it fails at locating pcre somehow. this latter problem is not related to anything introduced after v0.09.0-prethread

[boysetsfrog]

So I have had a look and I am quite certain the problem is what I suggested and that pcrecpp would be built with the usual gnu stdlibc++ and since you're building vimpc with libc++ linking them just isn't going to work. Realistically the only way to get it to work would be to make vimpc compile with stdlibc++, (which won't happen on a BSD unless you install g++ 4.7 or above and use that), to recompile a version of pcrecpp using libc++ instead to link against, or for me to remove the dependency on pcrecpp entirely. Or I suppose to wait until libc++ is the standard, which may be a while.

I am considering removing pcrecpp and switching to straight pcre just to make this simpler for people, as well as trying to possibly remove the dependency on the C++11 libaries by allowing people to use boost as an alternative. But that may take some time.

[nilsbecker]

ok, if i understand correctly, it's this problem: http://stackoverflow.com/questions/14128298/homebrew-gcc-llvm-and-c11
from that SO thread it seems that there is no easy way to use homebrew to fix the situation. apparently there is no way to switch all of homebrew to use clang and libc++, and while gcc 4.7 can be installed it will not be used for compiling libraries. so for now: no C++11 support with homebrew-installed libraries. the only way right now would be to compile pcre++ myself using libc++, manually.

[boysetsfrog]

If you install g++4-7 you should only need to use to compile vimpc only. Nothing else. Just by overriding the compiler using CXX=/path/to/g++-4.7 when you configure. You will probably also need to override LDFLAGS too, to point it to the stdlibc++ that is with g++4-7. something like LDFLAGS="-L/path/to/g++4-7/lib" . I don't deny that it is a pain, but it should work, and i have built vimpc on FreeBSD 9 this way.

I think I will go with the drop pcrecpp option when I get a chance and then you should be okay anyway since it is the only C++ library that i use and it is just some nice wrapper functions.

[boysetsfrog]

Okay. So I have made a first cut attempt at porting the libraries over to optionally use boost instead.

If you try: ./configure --enable-boost=yes

Plus any other options or settings you want, but without the libc++ stuff and compile that. Hopefully that will work okay for you. You will need to install the boost libraries though. Not quite sure what versions you will need yet, but just try whatever is in homebrew. I will try figure the exact versions shortly.

[nilsbecker]

ok, great! tried it: brew install boost; pulled HEAD, make distclean, ./autogen.sh, and

./configure --prefix=$HOME --program-prefix=my --enable-boost=yes

i get an error about boost_thread not being found:

g++  -I/usr/local/Cellar/pcre/8.33/include     -D_THREAD_SAFE -pthread -g -O2 -D__STRICT_ANSI__ -std=c++11  -L/usr/local/lib -L/opt/local/lib -lboost_thread -lboost_system -o vimpc src/vimpc-algorithm.o src/vimpc-buffers.o src/vimpc-clientstate.o src/vimpc-colours.o src/vimpc-errorcodes.o src/vimpc-mpdclient.o src/vimpc-output.o src/vimpc-player.o src/vimpc-screen.o src/vimpc-settings.o src/vimpc-song.o src/vimpc-vimpc.o src/buffer/vimpc-browse.o src/buffer/vimpc-library.o src/buffer/vimpc-directory.o src/mode/vimpc-command.o src/mode/vimpc-inputmode.o src/mode/vimpc-normal.o src/mode/vimpc-search.o src/window/vimpc-browsewindow.o src/window/vimpc-console.o src/window/vimpc-debug.o src/window/vimpc-directorywindow.o src/window/vimpc-error.o src/window/vimpc-help.o src/window/vimpc-infowindow.o src/window/vimpc-librarywindow.o src/window/vimpc-listwindow.o src/window/vimpc-modewindow.o src/window/vimpc-outputwindow.o src/window/vimpc-pagerwindow.o src/window/vimpc-playlistwindow.o src/window/vimpc-scrollwindow.o src/window/vimpc-selectwindow.o src/window/vimpc-songwindow.o src/window/vimpc-window.o src/window/vimpc-windowselector.o src/vimpc-main.o  -L/usr/local/Cellar/taglib/1.9.1/lib -ltag  -L/usr/local/Cellar/pcre/8.33/lib -lpcre -lpcrecpp  -L/usr/local/Cellar/libmpdclient/2.9/lib -lmpdclient   -lncurses
clang: warning: argument unused during compilation: '-pthread'
ld: warning: directory not found for option '-L/opt/local/lib'
ld: library not found for -lboost_thread
clang: error: linker command failed with exit code 1 (use -v to see invocation)

then i tried

find /usr/local -name *boost_thread*

which gives

/usr/local/Cellar/boost/1.54.0/lib/libboost_thread-mt.a
/usr/local/Cellar/boost/1.54.0/lib/libboost_thread-mt.dylib
/usr/local/lib/libboost_thread-mt.a
/usr/local/lib/libboost_thread-mt.dylib

also, i tried setting LDFLAGS="-L/usr/local/lib" which did not change anything.

so, it's 'almost' working?!

[boysetsfrog]

Okay. I added in the boost m4 files and modified the configure script to use those instead rather than just hacking it in myself, so hopefully they should identify the correct library.

[nilsbecker]

yay! builds successfully now! (not tested in action yet) although i must say, boost builds in 32 min and is 568MB, so it's not exactly a lighweight dependency....
thanks anyway for the fix!

[boysetsfrog]

No problem. And I know boost can be hefty, I too am not the biggest fan of that, which is why I didn't use it in the first place. But it is the easiest way for me to fix this issue. And I am only using boost thread and boost system so if homebrew let's you pick each one individually, that's all you really need.

Also, it is only a dependency in the case where the compiler supports C++11 but the std c++ library being used doesn't include c++11 features (like threads and functions). This is the case on the BSDs (including OSX) because they don't want to use GPL3 software. Once libc++ becomes the norm on these systems and replaces libstdc++, you won't need to use boost to compile vimpc anymore. Or you can use g++ 4.7 instead or use libc++ to compile pcrecpp. And once I drop pcrecpp for pcre, you will be able to just use libc++ anyway and again won't need boost. I have started doing this, but there is still more work.

I also believe that ncmpcpp uses parts of C++11 and it definitely uses boost thread so the dependencies should be about the same as what you already had. But i am not 100% sure.

Let me know how the album artist support goes!

Thanks.

[boysetsfrog]

I've commit the changes to drop pcrecpp as well now, so you can give libc++ another go if you are interested in trying that. I have also changed the configure script to automatically detect the conditions under which boost is necessary and enable it itself, so you won't need to provide the "--enable-boost=yes" anymore either.

[nilsbecker]

ok, i did some tests. with the newest HEAD,
./configure --prefix=$HOME --program-prefix=my
seems to find the boost libraries (from the configure output), compiles and runs. however, not stably:

libc++abi.dylib: terminate called throwing an exception─────────────────────────
                                                       Abort trap: 6

this is odd since i did not give any libc++ configure options? i then tried with
CXXFLAGS="-stdlib=libc++ -std=c++11" ./configure --prefix=$HOME --program-prefix=my
which complies but when running immediately gives
Segmentation fault: 11─

i then installed gcc 4.7 with homebrew, and tried
CXX="/usr/local/bin/g++-4.7" ./configure --prefix=$HOME --program-prefix=my
which on compilation, fails:

/usr/local/bin/g++-4.7 -DHAVE_CONFIG_H -I. -I./src   -I/usr/local/include -I/opt/local/include -DHELP_DIRECTORY='"/Users/nbecker/share/doc/vimpc"'  -I/usr/local/Cellar/pcre/8.33/include     -D_THREAD_SAFE -pthread -g -O2 -D__STRICT_ANSI__ -std=c++11 -MT src/vimpc-clientstate.o -MD -MP -MF src/.deps/vimpc-clientstate.Tpo -c -o src/vimpc-clientstate.o `test -f 'src/clientstate.cpp' || echo './'`src/clientstate.cpp
src/clientstate.cpp: In member function 'void Mpc::ClientState::DisplaySongInformation()':
src/clientstate.cpp:326:73: error: 'strlen' was not declared in this scope
make: *** [src/vimpc-clientstate.o] Error 1

[boysetsfrog]

Ergh, sorry about that. That's twice I have broken the build whilst making it work in another configuration. Think I might write a test script for that. Either way I've add the missing include for g++ 4.7

In regards to the stability issues, if you could get me a backtrace from gdb that would be really handy, both boost/libc++ are working okay for me, but with all the different vimpc settings, mpd library whatever there is a lot of variance.

To do that run vimpc in gdb as "gdb ./vimpc" then type run... when it crashes type "thread apply all bt" to get a backtrace for every running thread.

[nilsbecker]

ok, i made a gist with the gdb output from the gcc4.7 version: https://gist.github.com/nilsbecker/7419237

[nilsbecker]

i have not been able to crash the boost version configured with
CXXFLAGS="-stdlib=libc++ -std=c++11" ./configure --prefix=$HOME --program-prefix=my
-- damn! ;)

[boysetsfrog]

If you are using libc++ it shouldn't need to use boost at all. Are you sure that boost was enabled in that configuration? It shouldn't use boost when you use gcc4.7 either so long as you point the LDFLAGS at the librayr directory for gcc4.7. Only in the clang++/xcode/whatever but old libstdc++ case is boost required.

Anyway, thanks. I appreciate the commitment to this. Unfortunately that stack dump doesn't look like it is going to be overly useful, but I will have a look around. I might try and use valgrind (you can try this too if you want and try make them crash) I will see if I can find anything though. I probably also should have told you to use "--enable-debug=yes" when using gdb, but that's okay, since there isn't much in the trace anyway.

valgrind --log-file=valoutput ./vimpc
valgrind --tool=helgrind --log-file=heloutput ./vimpc

for reference, if you are interested.

[boysetsfrog]

Also in regards to your comments "stdout was redirected to a file, so the curses output somewhat degrades the readability. surely there is a better way..." which i just noticed, you can use the gdb command "tty" to specify and redirect the output to a different terminal, this allows you to debug vimpc from one terminal but have the curses interface show up in a different one, which works quite well.

[nilsbecker]

about boost vs libc: i will check again when i get to it. could be a little while.

[nilsbecker]

ok, so configuring with ./configure --prefix=$HOME --program-prefix=my generates make output with -DUSE_BOOST_THREAD and the like. it compiles but crashes when running with libc++abi.dylib: terminate called throwing an exception.

configuring with CXXFLAGS="-stdlib=libc++ -std=c++11" ./configure --prefix=$HOME --program-prefix=my does not generate any boost related compile time output. it compiles and segfaults soon after starting it.

[boysetsfrog]

That is strange because when using the boost configuration it should not be using libc++ at all, are you sure you you haven't overridden some linker flags as well? Maybe you could make sure are doing a "make clean" between builds as well? If you do a ldd ./myvimpc when you do the boost one, does it list libc++ and libstdc++ ?

[nilsbecker]

yes it is strange. i tried again with the newest HEAD. make clean, make distclean, ./autogen.sh, ./configure --prefix=$HOME --program-prefix=my. this outputs some checks for boost related stuff. then make. again boost related output. make install. run.

now, there was no crash for a while. (a segfault occurrs reproducibly after mouse-resize of the terminal window but without any libc++ related output).

so for all i know, it might be that i did not clean the build environment properly (although i certainly meant to) at the moment, all is running ok with the boost version (except for the resize)

[nilsbecker]

i also built the libc version again CXXFLAGS="-stdlib=libc++ -std=c++11" ./configure --prefix=$HOME --program-prefix=my. this is also working rather nicely now. again, segfault on resize, this time with: myvimpc(4727,0x7fff7a498180) malloc: *** error for object 0x1028522a0: pointer being freed was not allocated [2:24/5:17] [State: Playing] *** set a breakpoint in malloc_error_break to debug Abort trap: 6

another side note: when skipping a song with <>, the coloring indicating the playing song does not get updated immediately, only after moving the cursor-highlighted over it. this is not ideal.

[boysetsfrog]

I haven't been able to replicate the crashing on resize so you might need to provide me with a backtrace from gdb again. I have tried it on a few platforms and with a range of different sizes and from a lot of different tabs etc , but haven't hit anything.

Also I have fixed the colour change when skipping with <> but it still needs some work as currently the autoscroll feature is broken and it selects the wrong song. Need to find myself some time though unfortunately.

[nilsbecker]

i think now i must be doing something wrong during build and install. last i tried i got immediate segfaults again, and again the boost version shows something about libc++.abi, which does not make sense to me. is this sequence of commands ok? (from the source directory)

make uninstall
make clean
make distclean
git pull
./autogen.sh
./configure [options]
make
make install

if yes i'll do it again carefully when i get the time.

[boysetsfrog]

That should be fine. Overkill if anything. But shouldn't be a problem. After you compile if you run ldd on vimpc does it list the libc++ library?

[kax4]

CXX="clang++" CXXFLAGS="-stdlib=libc++ -std=c++11" ./configure --disable-debug --disable-dependency-tracking --prefix=/usr/local/Cellar/vimpc/HEAD --enable-taglib=no

I don't have macport install but compile complain
clang: warning: argument unused during compilation: '-pthread'
ld: warning: directory not found for option '-L/opt/local/lib'

otool -L $(which vimpc)
/usr/local/Cellar/vimpc/HEAD/bin/vimpc:
    /usr/local/opt/pcre/lib/libpcre.1.dylib (compatibility version 4.0.0, current version 4.1.0)
    /usr/local/lib/libmpdclient.2.dylib (compatibility version 3.0.0, current version 3.9.0)
    /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 65.1.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)

[boysetsfrog]

@kax4 Are you also having problems with seg faults when resizing or running vimpc when you compile it in this manner or just the compilation warnings?

[nilsbecker]

ok, another try, with the build sequence above, and with

CXXFLAGS="-stdlib=libc++ -std=c++11" ./configure --prefix=$HOME --program-prefix=my

this time, without connecting to mpd (the mpd host is down right now). the program starts but segfaults on resizing, with

myvimpc(12626,0x7fff7a498180) malloc: *** error for object 0x109049e20: pointer being freed was not allocated                                                   Abort trap: 6                      *** set a breakpoint in malloc_error_break to debug

also (no ldd available on my os x ),

/Users/nbecker/bin/myvimpc:
    /usr/local/lib/libtag.1.14.0.dylib (compatibility version 1.0.0, current version 1.14.0)
    /usr/local/lib/libpcre.1.dylib (compatibility version 4.0.0, current version 4.1.0)
    /usr/local/lib/libmpdclient.2.dylib (compatibility version 3.0.0, current version 3.9.0)
    /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 65.1.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)

[kax4]

@boysetsfrog On my system it also crash when resizing

[nilsbecker]

other than the resize bug, vimpc seems to run stably for me now with the options above, also when actually controlling mpd. the previous non-resizing segfaults may have been a mix-up of different built versions.

[boysetsfrog]

If you could get me a backtrace from gdb of the crash that occurs when you resize vimpc i would really appreciate it.

[kax4]

Affter vimpc crash it mess terminal a little
(gdb) bt
#0 0x00007fff850f3212 in __pthread_kill ()
#1 0x00007fff8bc21b24 in pthread_kill ()
#2 0x00007fff8bc65f61 in abort ()
#3 0x00007fff8bc39989 in free ()
#4 0x00000001001906ce in std::__1::list<std::__1::pair<int, EventData>, std::__1::allocator<std::__1::pair<int, EventData> > >::pop_front ()
#5 0x00000001001858b4 in Main::Vimpc::Run ()
#6 0x000000010028faa9 in main ()
(gdb)

[boysetsfrog]

Hi guys based on the stacktrace from @kax4 I have made a small change in the handling of this, but i am not entirely sure if it is the problem, but if you want to try it out it would help me a lot. Thanks.

[kax4]

Thanks, no more crash with e45e3da.

[nilsbecker]

for me too; no crash on resize with the libc compiled version. nice!

[kax4]

Uhm seem like it not complete fix the problem resize then return to vimpc window it flash once then other text become a mess.

[nilsbecker]

hmm. for me its working. i can resize, switch focus away and back, quit, restart, no problems.

[kax4]

Now i can't reproduce it like the one from the screenshot too so it rarely happen still it have some kind of flashing effect after resize vimpc then switch back focus with mouse.

[connermcd]

Can this be closed now?

[nilsbecker]

yes, the original issue is resolved and the resize bug is squashed at least for me.

also, on os x 10.9, with current HEAD, no special build flags are needed for me. it compiles and runs fine with plain ./configure