fixing libvlc release mode crash with VC2010 - crash

I am using libVLC in one of my apps which I am compiling with VC2010 (also tried VC2008), the debug mode of my app works great but as soon as I compile to release mode and try to call into libVLC I get a crash. I asked for help on the vlc forums and someone mentioned this usually points to calling convention differences, however I am not sure what to check to see if this is the case or more importantly how to fix it.
some notes:
I am compiling libVLC using Ubuntu and following the how to guides on the libVLC wiki.
I'm using libVLC inside a C++ file.
I've tried compiling libVLC with and without debugging information.
I've tried calling libvlc_get_version and libvlc_new as my first call, both crash.
Even though I do not have symbols in my release version, I can see the call stack and it is definitely getting messed up as it is showing functions in the stack that are never-ever called which seems to indicate the wrong calling convention but again I'm not sure how to check/fix this.
I'm not sure if it is related but another issue I am having with libvlc is that I am trying to delay load the dll (have tried not doing this for the above problem but it didnt make a difference), i'm adding the linker flags: /DELAYLOAD:libvlc.dll /DELAYLOAD:libvlccore.dll
, but when the linking occurs I get these warnings:
LINK : warning LNK4199: /DELAYLOAD:libvlc.dll ignored; no imports found from libvlc.dll
LINK : warning LNK4199: /DELAYLOAD:libvlccore.dll ignored; no imports found from libvlccore.dll
However it is definitely linking to the lib and requiring the dll as seen with Dependency Walker (not to mention I am calling into it).. again not sure if this is related but wanted to throw it out there as well.
I appreciate any advice/help on this one. Thanks!

I just came to the same problem and after some digging up with IDA dissasembler I've found out that linker throws out all libvlc imports. And yes INCREMENTAL flags adds them back in but as you said it's not the explanation of the problem.
Now I had a similar occurrence when designing a driver where Release eliminated function pointers and strings. And the solution was to set Linker\Optimization\References to No (/OPT:NOREF). So then linker leaves in all references even if it thinks they are not used.
And of course that fixes the problem.
So another mystery solved. ,)
Best regards
Waldemar

Actually, adding '/OPT:NOREF' solves the problem as well, at least in my case. and i think the problem may result from an 'issue' with dlltool, as ffmpeg suffers the same problem (http://ffmpeg.org/platform.html#Linking-to-FFmpeg-with-Microsoft-Visual-C_002b_002b), and like ffmpeg, libvlc(i guess) may generate windows 'lib' files with 'dlltool' instead of 'lib.exe' from msvc. the related bug report with dlltool is here: https://sourceware.org/bugzilla/show_bug.cgi?id=12633#c1
as you claimed that you were "compiling libVLC using Ubuntu", i think you probably encountered the same problem. hope it'll help.
btw, the official distribution of ffmpeg provide '.def' files, so i could regenerate the 'correct' lib files with 'lib.exe' from msvc and problem solves. however, as the official windows distribution of vlc does not provide '.def' files, and i failed to reconstruct the lib files via the 'dumpbin and lib' approach(failed when dumpbin, there must be something strange with the dll), i cannot do further verification.

Related

How to use ZeroBrane Studio IDE debugger when lua is compiled as c++

I have compiled Lua 5.3 as a 32 bit c++ DLL and exe. The DLL contains all the lua code except for lua.cpp and luac.cpp. The exe compiles lua.cpp and uses the DLL to run the lua interpreter. This works fine when running on its own from the command line. I wish to be able to run from the IDE using this DLL and exe.
If I replace /ZeroBraneStudio/bin/lua53.dll and lua53.exe with my own versions, I can run scripts (clicking the two green arrows). However, debugging does not work, giving the following error:
The procedure entry point luaL_addlstring could not be located in the dynamic link library lua53.dll.
I can see that this is happening because the debugger is making use of luasocket. \ZeroBraneStudio\bin\clibs53\socket\core.dll is dependent on lua53.dll, and is expecting it to contain lua compiled as c.
So, what is the correct solution to this - is it to compile luasocket as c++ as well?
(And, if so, does anybody have instructions/guidance for doing so? I have been unable to find anything on this.)
Thanks.
I'm not sure how exactly the DLL was compiled, but the error message likely indicates that the luaL_addlstring and other functions are not exported by it. If the symbols are exported correctly, you should be able to load luasocket and get the debugging working. See this thread for the related discussion.
Also, you don't need to replace lua53 library and executable, as you can configure the IDE to use your own copy of it using path.lua53 configuration setting as described in the documentation.
Okay, I was able to get it working. The solution was to compile luasocket as c++. I won't give full instructions on how to do this here, but some points to hopefully help anybody else with the same issue:
Got luasocket from here: https://github.com/diegonehab/luasocket
Renamed all *.c files to *.cpp
Renamed Lua52.props to Lua.props (I am using lua 5.3 but seems like it is compatible?)
Placed lua headers and lib in appropriate folders
Opened solution in Visual Studio 2012
Fixed up minor issues with project files, like the renaming of the files.
Added 'extern "C"' to declaration of luaopen_socket_core and luaopen_mime_core functions (necessary for lua to be able to load libraries).
Built solution
Copied new dlls into clibs53/socket and clibs53/mime folders.
I used Dependency Walker to help with this. If anybody wants further details in the future please leave a comment.

Where does bazel look for OSX SDKs (and what to do if it's not finding them)?

I have an objc_library rule that tells me that it can't find any SDK framework header (this problem is not specific to IOKit, I can't find any frameworks at all).
#import <IOKit/IOKitLib.h>
fatal error: 'IOKit/IOKitLib.h' file not found
I already have "IOKit" in my sdk_frameworks. If I take a peek in /System/Library/Frameworks/IOKit.framework, I find that there is no directory Headers which would contain this file. Perhaps no surprise if that's where Bazel is looking.
If I look a little harder, I find more results for the SDK.
$ find /Applications/Xcode.app/ -name IOKit.framework
/Applications/Xcode.app//Contents/Developer/Platforms/AppleTVSimulator.platform/Developer/SDKs/AppleTVSimulator.sdk/System/Library/Frameworks/IOKit.framework
/Applications/Xcode.app//Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/System/Library/Frameworks/IOKit.framework
/Applications/Xcode.app//Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/Frameworks/IOKit.framework
/Applications/Xcode.app//Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/IOKit.framework
/Applications/Xcode.app//Contents/Developer/Platforms/WatchSimulator.platform/Developer/SDKs/WatchSimulator.sdk/System/Library/Frameworks/IOKit.framework
/Applications/Xcode.app//Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift-migrator/sdk/MacOSX.sdk/System/Library/Frameworks/IOKit.framework
I would think that this is the one I want, since I'm developing for MacOSX.
/Applications/Xcode.app//Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/IOKit.framework
Can I tell Bazel to use that SDK? Should I have to? How can I figure out where Bazel is looking for these things? I'm pretty familiar with using Bazel, but I'm really not sure how to debug when the most basic of things is failing.
Here is the simplest example that fails.
BUILD:
objc_library(
name = "test",
srcs = ["test.cpp"],
copts = ["-ObjC++"],
sdk_frameworks = ["IOKit"],
)
// test.cpp
#import <IOKit/IOKitLib.h>
I posted this on bazel-discuss, but it isn't getting much traction. I'm using Bazel 0.5.2.
https://groups.google.com/forum/#!topic/bazel-discuss/HhAjKblwHwk
Resolved in the bazel-discuss thread, but I'll summarize here:
The issue you are finding here is most likely because IOKIt is a MacOS-only SDK, and you're building this library for iPhoneSimulator.
(I think the former is the case, anyway. It looks like there is indeed an IOKit.framework directory under iPhoneSimulator9.3.sdk, but it doesn't include headers -- I'm not sure what the point of that is)
Correctly building the library for MacOS is key here and should fix your issues. You can either do that by depending on this library via an apple_binary with platform_type="macos", or you can tailor command line flags to this end. I believe --apple_platform_type=macos --cpu=darwin_x86_64 should do the trick

CMake- Difficulties building static library

So I have been trying to build libarchive for a couple of days now, following this guide and many other threads: https://github.com/libarchive/libarchive/wiki/BuildInstructions
I want a static library with LZMA, zlib and bzip2 support. I got static versions of these too (lib's)
I just cant get it to work properly. Ive used CMAKE to generate the make files for VS2010 and NMAKE. With both of these options the thing compiles just fine, but when i try to use the archive_static.lib generated, in my project I get plenty of unresolved externals. Compiling the .dll version of the library works without unresolved externals, but then it starts asking for zlib.dll, bzip2.dll etc, which i dont have and dont want to use.
I think i need to set some flags with cmake, but im not sure how to do that.
Any help is greatly appreciated.
http://www.libarchive.org/
I can't be sure if that's what happening here, but please bear in mind, that when linking binaries into a static library, its external dependencies do not necessarily get embedded into it, that means you might need to provide thet static libraries on which your program indirectly depends through libarchive, namely LZMA, zlib and bzip2 in your case, explicitly.
Furthermore there's some confusion on windows when it comes to linking static vs dynamic, for in both cases you provide a .lib file, so it is very easy to mix things up and provide the dynamicaly linked .lib, instead of the static version. If you do that, the linker may refuse to link your program (that notably happens with boost), or may link just fine and then, at the time of execution, the OS will require the respective .dll's.

Unqualified-id in file included from ZXBinarizer.mm

I have created an iPhone project that uses uses the ZXing bar code scanning library. I added ZXing using CocoaPods and it works perfectly when I compile it on my system (Mountain Lion with Xcode 4.5 (4G182)). But when I passed it on to the person in charge of producing the signed ipa for enterprise distribution, who from what I understand is also using the same version of Xcode, he is seeing the following parse error when compiling:
Parse Issue
Expected unqualified-id in file included from /The/Absolute/Path/to/Pods/ZXing/objc/src/ZXing/ZXBinarizer.mm
The line that is highlighted is:
#import <ZXing/ZXBinarizer.h>
^
I was able to look at his system via WebEx and I checked the header search paths and the values that were apparently configured via CocoaPods do resolve to the actual location of the files.
When I clicked on the "Parse Issue" line in the issue navigator, it showed only:
../../ZXing/objc/src/ZXing/ZXBinarizer.h
^
I've searched the web quite a bit for a solution and I see plenty references to 'Expected unqualified-id', but most of them are due to malformed code.
There are still quite a few things about Xcode that I do not understand, so I'm hoping that someone will tell me that I've overlooked something simple here.
Posting links to the exact code being compiled would help.
You can use clang -E to see what the code looks like after preprocessing (with all the #imports expanded), and then diff the preprocessed output on your system against the output of the same command on your colleague's system.
I do see in
http://code.google.com/p/zxing/source/browse/trunk/objc/src/ZXing/ZXBinarizer.h
that they're referring to NSObject without #importing <Foundation/Foundation.h> first. This is a bad idea, but it's probably not your actual problem. (I would expect a different error message if it were the culprit.)
Are you 100% sure that your colleague is compiling ZXBinarizer.mm as Objective-C++, not as regular C++?
Are you 100% sure that Xcode doesn't give you any specific file and line information for the error? If Xcode really is just pointing to an #import line, then can you post the 10 lines before and after that line, and also the first 10 lines of the file being #imported?
I ended up having to revert out of using CocoaPods for dependency management and just include the project manually. Since the problem was on someone else's machine, but worked fine on my own, I was unable to determine the real cause. After I just included ZXing directly in my project, he was able to compile it.
smcmahon, I've had a very similar issue with building an iOS project with CocoaPods and seeing those weird errors, and was able to figure out the problem. Make sure that the symlinks that CocoaPods has created (like ZXing/ZXBinarizer.h) are indeed symlinks, and not just regular text files with a filepath in them.
A bit more detailed explanation is in my blog: http://www.egeek.me/2013/01/26/note-about-building-cocoapods-powered-ios-projects/
Hope this will help.

GCC 4.5.0..linking error during compilation?

Well I've recently come out of the dark ages and upgraded my GCC from 3.4.4 to 4.5.0 with Cygwin (I use Netbeans 6.8 on Windows for future reference). I tried testing the new compiler by attempting to run a simple program through it. The run failed however, citing that NetBeans "cannot find -lstdc++".
Interesting.
I look in ...
C:\cygwin\lib\gcc\i686-pc-cygwin\4.5.0
...where libstdc++.a, libstdc++.dll.a, libstdc++.la, libsupc++.a, and libsupc++.la are supposed to be (they're in that spot in the 3.4.4 folder), and they're not there. I also notice something else: there's a 4.3.4 folder in...
C:\cygwin\lib\gcc\i686-pc-cygwin
which contains these exact files! Good. So I copy them in to the 4.5.0 folder and try to run the program again. This time i'm getting two other errors:
build/Debug/Cygwin-Windows/extract_fail_operations.o:/usr/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/bits/stl_list.h:1435: undefined reference to `std::_List_node_base::_M_hook(std::_List_node_base*)'
and:
build/Debug/Cygwin-Windows/extract_fail_operations.o:/usr/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/bits/stl_list.h:1451: undefined reference to `std::_List_node_base::_M_unhook()'
At this point I figured that I was way over my head and decided to come for help before copying and pasting any more files. If anyone could tell me how to get this working, i'd be really appreciative.
(If any solutions involve the command line, please be warned that i'm not well versed in it... you may have to provide extra details that you wouldn't need to to other SO users!)
EDIT: The PATH variables are as follows:
C:\Program Files\SSH Communications Security\SSH Secure Shell;C:\Program Files\CVSNT\;C:\cygwin\bin
And yes, the Cygwin installed is the latest from the site.
You need to install version 4.5.0 of libstdc++6-devel.