libstdc++-6.dll

nesta · 12th October 2010, 22:52

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 · 12th October 2010, 22:53

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

Midzuki · 12th October 2010, 23:05

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"

r1745 build from his site.

However I'm still using r1713.

LoRd_MuldeR · 12th October 2010, 23:18

Just in case anybody is interested, here is my x264 r1745 build:
http://www.mediafire.com/file/9a6536...6-fprofiled.7z

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

simps · 12th October 2010, 23:44

Quote:

Originally Posted by Dark Shikari

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 · 12th October 2010, 23:47

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 · 12th October 2010, 23:50

Quote:

Originally Posted by 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

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...

Quote:

Originally Posted by 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

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 · 12th October 2010, 23:54

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

simps · 12th October 2010, 23:58

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 · 13th October 2010, 00:00

Quote:

Originally Posted by simps

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/libr...86(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 · 13th October 2010, 00:04

Quote:

Originally Posted by LoRd_MuldeR

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/libr...86(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 · 13th October 2010, 00:06

Quote:

Originally Posted by simps

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 · 13th October 2010, 00:11

Quote:

Originally Posted by LoRd_MuldeR

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 · 13th October 2010, 17:51

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:

Code:

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):

Code:

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:

Code:

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 · 18th October 2010, 10:37

Quote:

Originally Posted by Dark Shikari

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.ph...89#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 · 18th October 2010, 16:09

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

12th October 2010, 22:52	#1 \| Link
nesta Registered User Join Date: Apr 2009 Posts: 3	libstdc++-6.dll 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.

12th October 2010, 22:53	#2 \| Link
Dark Shikari x264 developer Join Date: Sep 2005 Posts: 8,666	jarod screwed up his builds again. Use builds made by someone less incompetent. __________________ Follow x264 development progress \| akupenguin quotes \| x264 git status ffmpeg and x264-related consulting/coding contracts \| Doom10

12th October 2010, 23:18	#4 \| Link
LoRd_MuldeR Software Developer Join Date: Jun 2005 Location: Last House on Slunk Street Posts: 13,249	Just in case anybody is interested, here is my x264 r1745 build: http://www.mediafire.com/file/9a6536...6-fprofiled.7z (You can ignore the 'libx264-106.dll' and simply use the EXE file as usual) __________________ Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

12th October 2010, 23:05	#3 \| Link
Midzuki Unavailable Join Date: Mar 2009 Location: offline Posts: 1,480	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" r1745 build from his site. However I'm still using r1713.

12th October 2010, 23:47	#6 \| Link
Taiken Registered User Join Date: Sep 2010 Posts: 2	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

12th October 2010, 23:54	#8 \| Link
Taiken Registered User Join Date: Sep 2010 Posts: 2	oh, that is great, thanks. (Y) if only I had known before u.u

12th October 2010, 23:58	#9 \| Link
simps Registered User Join Date: Feb 2005 Posts: 149	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?

18th October 2010, 16:09	#16 \| Link
bob0r Pain and suffering Join Date: Jul 2002 Posts: 1,337	That's just how Dark shows his love to me.