libstdc++-6.dll

[nesta]

getting an error anytime I try and start the latest build 1745 x264.exe 32bit 8bit-depth from cli, "libstdc++-6.dll is missing from system".
previous versions give no problems.

[Dark Shikari]

jarod screwed up his builds again. Use builds made by someone less incompetent.

[Midzuki]

I've noticed the homepage of x264.nl has been modified several times during this day. :) So it seems I was lucky enough to download a "non-b0rked" :D r1745 build from his site.

However I'm still using r1713. :o

[LoRd_MuldeR]

Just in case anybody is interested, here is my x264 r1745 build:
http://www.mediafire.com/file/9a6536ou067566m/libx264-106-r1745M-gcc451-i686-fprofiled.7z

(You can ignore the 'libx264-106.dll' and simply use the EXE file as usual)

[simps]

jarod screwed up his builds again. Use builds made by someone less incompetent.

I thought x264.nl had the dark shikari approval seal. Am I missing something?

[Taiken]

thanks LoRd_MuldeR, why you have not returned to update the simplex264? I like the option pause to put the computer in suspension so when my parents get anger about leaving the computer on overnight xD

[LoRd_MuldeR]

thanks LoRd_MuldeR, why you have not returned to update the simplex264? I like the option pause to put the computer in suspension so when my parents get anger about leaving the computer on overnight xD

Because the GUI doesn't need to be updated for every x264 reversion ;)

You can just replace the 'x264.exe' or 'x264_64.exe' with the desired build/revision and that's it...

thanks LoRd_MuldeR, why you have not returned to update the simplex264? I like the option pause to put the computer in suspension so when my parents get anger about leaving the computer on overnight xD

Please let's avoid a pointless discussion about the "quality" of x264.nl builds!

The latest builds on x264.nl obviously were linked against the shared C++ run-time. This isn't necessarily a bad thing, only 'libstdc++-6.dll' will be needed at run-time.

Anyway, I assume it happened by mistake and will be "fixed" soon. So simply be patient or use another build in the meantime...

[Taiken]

oh, that is great, thanks. (Y) if only I had known before u.u

[simps]

I don't get it, I downloaded r1745 (32bit 8bit) from x264.nl, yesterday, the minute the site was updated from r1732... So I believe I got it before the OP of this thread.

I can run x264.exe without any problems... Is it possible that this .dll error happens only with some systems, and not with others?

As I write, I am encoding with this r1745 from x264.nl, downloaded yesterday. 5 hours to finish. Will my encode be messed up? :(

[LoRd_MuldeR]

I can run x264.exe without any problems... Is it possible that this .dll error happens only with some systems, and not with others?

The error happens if, and only if, you use a binary that was linked 'libstdc++-6.dll' and that DLL isn't available from any of the directories that the Windows loader will search:
http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx

So you either are using a statically linked build of x264 -or- the required DLL is available on your system. For more information please use the Dependency Walker:
http://www.dependencywalker.com/

[simps]

The error happens if, and only if, you use a binary that was linked 'libstdc++-6.dll' -and- that DLL isn't available from any of the directories that the Windows loader will search:
http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx

For more information please use the Dependency Walker. It will give you the answer, so you don't have to speculate ;)
http://www.dependencywalker.com/

Ok, so if I am not getting the error, looks like I have this .dll (for some reason) at some default diretory.

So, what about this encoding I am doing here... 5 hours left, and it has been running for another 8 hours or so (and this is fisrt pass, I will need to do a 2nd pass too).

Shoud I continue encoding, or should I cancel it now, and use your build? I don't wanna waste another 5 hours to discover my video is messed up because of x264 bad builds.
What should I do?

[LoRd_MuldeR]

Shoud I continue encoding, or should I cancel it now, and use your build? I don't wanna waste another 5 hours to discover my video is messed up because of x264 bad builds.

As said before, there is absolutely nothing wrong with having the C++ run-time linked as a shared library. It only means the 'libstdc++-6.dll' is needed at runtime.

(BTW: x264 itself shouldn't need the C++ run-time at all, as it's pure C. So I guess it's GPAC or FFMS2 or libavcodec/libavformat that adds the dependency)

[simps]

As said before, there is absolutely nothing wrong with having the C++ run-time linked as a shared library. It only means the 'libstdc++-6.dll' is needed at runtime.

(BTW: x264 itself shouldn't need the C++ run-time at all, as it's pure C. So I guess it's GPAC or FFMS2 or libavcodec/libavformat that adds the dependency)

Ok, so from your post, I am understanding that my r1745 build downloaded from x264.nl is perfect, and I won't end up with a messed up video.

I won't cancel the encode.

[bob0r]

I figured i'd update gcc, because the past few years no real issues occured, until now:

gcc 4.5.1 now compiles dynamicly by default, which made you require the .dll file.

I now compile gcc 4.5.1 this way:


1. cd gcc-4.5.1/
2. mkdir obj
3: cd obj
4: ../configure --enable-static --disable-shared
5: make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap
6: make install


But unless the last time, i'll first test it this weekend.

I also compiled gcc 4.4.5 as i always do (did, see above):


1. cd gcc-4.4.5/
2. mkdir obj
3: cd obj
4: ../configure
5: make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap
6: make install


But when i try to run the 10bit-depth build from my script i get:


gcc -Wshadow -O3 -ffast-math -Wall -I. -march=i686 -mfpmath=sse -msse -std=gnu99 -IF:/msys/1.0/local/include
o encoder/encoder.c
encoder/encoder.c: In function 'x264_slice_write':
encoder/encoder.c:1820: warning: 'bs_bak.p_start' may be used uninitialized in this function
encoder/encoder.c:1820: warning: 'bs_bak.p' may be used uninitialized in this function
encoder/encoder.c:1820: warning: 'bs_bak.p_end' may be used uninitialized in this function
encoder/encoder.c:1820: warning: 'bs_bak.cur_bits' may be used uninitialized in this function
encoder/encoder.c:1820: warning: 'bs_bak.i_left' may be used uninitialized in this function
encoder/encoder.c:1820: warning: 'bs_bak.i_bits_encoded' may be used uninitialized in this function
encoder/encoder.c: In function 'x264_encoder_encode':
encoder/encoder.c:2282: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[1]: *** [encoder/encoder.o] Error 1
make[1]: Leaving directory `/home/xuser/x264_32bit_10bit_depth'
make: *** [fprofiled] Error 2


So we are back to gcc 4.4.4, which should work again!
Thanks for the report!
Sorry for the trouble!

Note to self: next time test x264.exe again before and after updating gcc!

[hydra3333]

jarod screwed up his builds again. Use builds made by someone less incompetent.Hmm, suggestions on what people find to be a very reliable source ?

Lots of advice
http://forum.doom9.org/showthread.php?t=89979
http://forum.doom9.org/showthread.php?p=1432889#post1432889
http://doom10.org/index.php?topic=3.0
but I don't know what an unpatched build is. Edit, looks like it's "more reliable" without experimental type patching.

[bob0r]

That's just how Dark shows his love to me.