gst-inspect complains about not found entry point "strlen" in msvcrt.dll

[GoogleCodeExporter]

This began since the revision about 832.

When I run gst-inspect, it shows several error windows stating that entry point 
strlen in the msvcrt.dll is not found.
After pressing ok, it writes in the console:

** (gst-inspect-0.10:2308): WARNING **: Failed to load plugin 
c:\Gstreamer\lib\gstreamer-0.10\libgstneonhttpsrc.dll
Same thing about libgstsouphttpsrc.dll

And then:

** (gst-inspect-0.10:2308): WARNING **: Failed to load plugin 
c:\Gstreamer\bin\libgmp-10.dll
with the same error - "entry point strlen not found"

And also for the following DLLs: libgnutls-26.dll, libgnutls-extra-26.dll, 
libgnutls-openssl-26.dll, libhogweed-2-0.dll, libneon-27.dll, libsoup-2.4-1.dll.

And several more same messages about libgstsouphttpsrc.dll and 
libgstneonhttpsrc.dll

Original issue reported on code.google.com by wl2776@gmail.com on 27 Sep 2010 at 4:39

[GoogleCodeExporter]

That's odd, I'm not able to reproduce it. Make sure you delete your old 
registry and that you're not accidentally mixing dll's.

I'll try it out on another machine just in case, though.

Original comment by david.g.hoyt on 27 Sep 2010 at 10:42

[GoogleCodeExporter]

The other machine showed a clean install and everything's working.

ylatuya: can you reproduce it?

Original comment by david.g.hoyt on 27 Sep 2010 at 10:49

[GoogleCodeExporter]

Sorry, my mistake, not strlen, but strnlen. Please, note letter 'n' after 'str'

libgnutls-26.dll wants this function in msvcrt.dll DependencyWalker clearly 
shows this.
My version of msvcrt.dll doesn't have one.

You cannot reproduce the error, probably, because I use somewhat newer code - 
I've pulled gstreamer from git. But the bug is still there, you'll find it 
sooner or later.

Again, please, run DependencyWalker and load libgnutls-26.dll into it, this 
will show the error.

Original comment by wl2776@gmail.com on 28 Sep 2010 at 2:59

[GoogleCodeExporter]

Which OS are you using? Is there something perhaps wrong w/ your msvcrt.dll? 
MSDN shows that strnlen() should be available from windows 95 and above 
(http://msdn.microsoft.com/en-us/library/z50ty2zh(VS.80).aspx). I'm not 100% 
certain of that and I seem to recall some issue w/ strnlen() in the mingw-w64 
mailing list. But I don't recall what the issue was and what its impact would 
be.

See the attached picture to see that strnlen() was resolving alright for me.

Original comment by david.g.hoyt on 28 Sep 2010 at 5:20

Attachments:

• strnlen.png

[GoogleCodeExporter]

Okay, this might be an issue w/ windows xp and earlier. i'll do a rebuild 
watching out for this asap.

Original comment by david.g.hoyt on 29 Sep 2010 at 5:55

[GoogleCodeExporter]

Windows XP, SP3, 32-bit.

I tried building gnutls by myself, configure showed that there's no strnlen.

Original comment by wl2776@gmail.com on 29 Sep 2010 at 6:19

[GoogleCodeExporter]

Successfully rebuilt gnutls, no complains and no dependencies on strnlen.

Original comment by wl2776@gmail.com on 29 Sep 2010 at 11:36

[GoogleCodeExporter]

Same complaints on the libgmp-10.dll and libhogweed-2-0.dll

Original comment by wl2776@gmail.com on 29 Sep 2010 at 11:36

[GoogleCodeExporter]

Sorry, only libgmp-10.dll, hogweed is clear. :)

Original comment by wl2776@gmail.com on 29 Sep 2010 at 1:38

[GoogleCodeExporter]

Can you show us a screenshot of DependencyWalker loading libgmp-10.dll?

Original comment by ylatuya on 3 Oct 2010 at 1:32

[GoogleCodeExporter]

Sure.

Original comment by wl2776@gmail.com on 4 Oct 2010 at 7:13

Attachments:

• ossbuild-libgmp-depwalker.dll.jpg

[GoogleCodeExporter]

That's weird. Can you attach a copy of your msvcrt.dll? Is __strnlen defined in 
it?

Original comment by ylatuya on 4 Oct 2010 at 8:40

[GoogleCodeExporter]

here it is.

Original comment by wl2776@gmail.com on 4 Oct 2010 at 9:00

Attachments:

• msvcrt.dll

[GoogleCodeExporter]

I can confirm that my msvcrt.dll in winxp doesn't have strnlen(). It might have 
been a macro in <= winxp. mingw-w64 added support (in libmingwex.a) in a newer 
version than the one I originally used to compile the latest dependencies. The 
new build should fix the problem.

Original comment by david.g.hoyt on 4 Oct 2010 at 6:48

• Changed state: Started

[GoogleCodeExporter]

I believe this is fixed. Please see r847.

Original comment by david.g.hoyt on 5 Oct 2010 at 12:38

[GoogleCodeExporter]

Fixed unless I hear otherwise...

Original comment by david.g.hoyt on 6 Oct 2010 at 7:13

• Changed state: Fixed