I tried to make a simple demo program that use zlib to compress & decompress files, but when I link the file, Visual Studio 2010 linker gave me this error:
Error 2 error LNK1313: ijw/native module detected; cannot link with pure modules
When I tried to change /clr:pure to just /clr. the program compiles and runs, but gave me a run time error:
"The application was unable to start correctly(0xc000007b). Click OK to close the application."
This is my code so far for just getting zlib version in balloon tip:
String^ info = gcnew String(reinterpret_cast<const char*>(zlibVersion()));
notify->ShowBalloonTip(20000, "Zlib Version", info, ToolTipIcon::Info );
Can you help me figure out what happened to zlib and what is that error. Thanks
If you're targeting the CLR I strongly recommend using a native (to the CLR) Zipping/Zlib library, such as DotNetZip, rather than trying to shoehorn a native library into doing what you want.
I'm not a C++/CLI expert, so this might be entirely wrong, but I believe
String^ info = gcnew String(reinterpret_cast<const char*>(zlibVersion()));
results in undefined behavior. The reason is that the System::String constructor expects an array of System::Char objects, not C++'s char data type. System::Char is two bytes wide, char is a single byte wide (System::String supports Unicode; zlib does not). (In any case, reinterpret_cast is a major red flag -- why are you using that cast here?)
Also, error 0x7B is
The filename, directory name, or volume label syntax is incorrect.
(The 0xC is there probably because it's an NTSTATUS code) Make sure that if you're using the dynamically linked version of Zlib that the DLL is available for your program to open somewhere.
Related
I am trying to compile some project using visual studio 2015 RC but I am facing issues when it tries to compile perlio.c. From what I have read this error is related to Visual Studio 2015 rather than the application that I am trying to build.
I have the following error:
C:\Program Files (x86)\Windows Kits\10\include\10.0.10056.0\ucrt\errno.h(112): note: see previous definition of 'ENOTSOCK'
perlio.c(2896): error C2039: '_file': is not a member of '_iobuf'
C:\Program Files (x86)\Windows Kits\10\include\10.0.10056.0\ucrt\corecrt_wstdio.h(26): note: see declaration of '_iobuf'
Command errors:
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.22816 for x86
So how to solve this error:
_file' is not a member of '_iobuf'
Just found this while hitting it myself. Presumably you were compiling the official CPAN Perl source. It has many problems while compiling with VS 2015 from its extensive use of the internals of the FILE struct. The new CRT that ships with 2015 (the Win 10 Universal CRT) has changed the FILE struct to an opaque one, as #Michael Burr mentioned in the comment.
typedef struct _iobuf
{
void* _Placeholder;
} FILE;
perlio.c has multiple cases of trying to use FILE::_base and FILE::_ptr. These can be disabled by undefining USE_STDIO_BASE and USE_STDIO_PTR in config.h. (In a clean build config.h is generated by copying config_H.vc)
perlio.c also uses FILE::_file. This one is not controlled by any #define. The only way is to remove the offending line.
win32.c extensively uses internals of the FILE struct, such as in fdupopen where it tries to generate a new FILE* from an existing one for the same filename, open mode and file position. There is no POSIX way to do this, and I don't know if there's any WinAPI to do it either.
win32.c also tries to provide a wrapper around gets(), which has also been removed. (It was removed from the C and C++ standards for being insecure.)
For the last two points, I have not found any workaround either. For now, you have to either use an older VS to compile Perl, or use 2015 but with an older SDK.
Edit: You can follow the progress on this on Perl's bug tracker (ID:125714). For better or worse, their workaround seems to be to simply cast the pointer to the new internal struct and access that one's internals.
I am writing lib files in VS that have to be imported into CVI.
Recently a linker problem occured.
It says that _allmul() is an undefined symbol.
_allmul() and freinds are implemented as calls to the CRT library functions to handle various 64bit operations.
The lib file that i write is static because i want all the code to live inside it.
Linking with VS is no problem and all unittests pass.
Linking with the CVI-IDE leaves the CVI Linkter complaining about an unresolved _allmul().
I thougth that setting the /MT switch in VS is enough to make the CRT link statically, this seems to be wrong.
Why is my assumtion wrong?
How can i link the CRT calls statically?
Edit:
Here is a short demo of a project that i can compile in VS2010 but that i can not link to in CVI
The following is compiled as a LIB project:
HEADER
void print( unsigned A, unsigned B );
CODE
#include "MyprintInterface.h"
#include <stdio.h>
void print( unsigned A, unsigned B ){
long long copyA = ( long long ) A;
long long copyB = ( long long ) B;
printf_s( " %lli * %lli = %lli ", copyA, copyB, copyA * copyB );
// copyA * copyB -> this invokes allmul
// printf_s this is a ms specific function
}
This is a little late, but maybe it will help someone else.
I had very similar experience when using the gSoap toolkit with LabWindows/CVI. The toolkit generates ANSI C bindings used in creating web service clients or servers. However it sometimes generated versions of MS functions (some deprecated) that were prototyped slightly different than those in CVI. Solving this was kind of tedious, but generally followed these steps:
1) install appropriate Microsoft SDK onto your dev box. Here is one option for Microsoft SDKs. (There are others, Google it)
2) search MSDN website for the unresolved symbol to determine what .lib/.h support it. (MSDN list of variations of sprintf, for example)
3) include any required .lib/.h files.
4) make sure msvcr80.dll or msvcr100.dll (or other as appropriate) are visible to your executable. (i.e. place either in the executable run-time directory, or in the system directory.)
In addition to this I had to bring some of the #defines from the header files supporting file write/read functions, just
for example:
#define _O_TEXT 0x4000 /* file mode is text (translated) */
#define _O_BINARY 0x8000 /* file mode is binary (untranslated) */
And: (Requires Microsoft Platform SDK be installed
c:\program files\microsoft platform sdk\include\crt (copied to project dir and included in project))
fcntl.h (definition for file mode etc., _O_BINARY)
float.h (definition for isnan etc.)
io.h (definition for setmode etc.)
Also, there is an example CVI project with source code illustrating what I have described above, (including using crt) here.
[EDIT]
Regarding COFF compatible .libs when using third party libraries with respect to LabWindows/CVI - Read the posts here.
[EDIT 2]
Once you install the Windows SDK, the headers for everything in msvcrxxx.dll will be on your system. But for finding .h dependancies of a specific API call I typically have good luck just searching for it on Google: i.e. for sprintf_s et. al., the first link returned was this. It includes notes on how to use sprintf_s including source code.
As for allmul issues, I have not run into this before, but this guy did.
While trying to run opencv sample matlab call, I am getting an error
Invalid MEX-file 'mypath\displayImage.mexw64': mypath\displayImage.mexw64 is not a valid Win32 application.
There are no errors while compiling. Also there are no errors while compiling and running simple helloworld sample.
What can be a reason for this? Why it expects win32 when even filename says 64?
Matlab is 2013a, VS is 2012, both are 64bit.
UPDATE
I found this "solution" of year 2009 saying that any of called DLLs should be 64 bit.
Is this
(1) true nowadays, and
(2) possible in practice?
How to check if some called library is 32bit?
Ok my PATH was pointing to %OPENCV_DIR%\build\x86\vc11\bin and this was overriding any LIB settings.
This was at runtime.
I.e. when I fixed PATH value, program started to run even without recompiling.
I am currently trying to calculate rigid transformation between two point sets so I tried to use the code given by the tutorial on pointclouds.org:
http://www.pointclouds.org/documentation/tutorials/iterative_closest_point.php#iterative-closest-point
For my case I only changed the part where the data is randomly generated to something that loads the point data I want to analyze. Everything else is exactly like in the tutorial...
(I also tried testing exactly the tutorial code with the random data, in case I had somethign wrong with reading my input data)
Since I work with Qt I integrated the PCL library, Eigen library and FLANN library to my project. It finds all headers and successfully compiles with MSVC 2008...
Unfortunately I always get a runtime error at
icp.setInputTarget(cloud_out);
saying:
Debug Assertion failed! Program:
...MSVC2008_Qt_SDK_Release\release\Project.exe File: c:\Program
Files\Microsoft VIsual Studio 10.0\CV\include\vector Line: 1200
Expression: vector erase iterator outside range
[..] ... check documentation ... [..]
Does anybody know what that means? The input clouds both have the same size and have filled values.
I would be thankful for any help!
UPDATE 1:
The error message shows some file path for MSVC 2010 (10.0) ... So I tried to uninstall Visual Studio 2010 since I don't really need it. But still, if I compile in Debug mode, it shows me an error message, but with Expression: vector iterators incompatible instead... If I now run it in Release mode, it just crashes at runtime (at the same line), but doesn't show that error message.
This seems so be a problem with the library you use. Assuming you have done a clean build, checked your PATH variable and everything and that Visual Studio 2010 is removed, this might be a problem with the library itself. Are you you using the right one?
The current Qt SDK has MSVC2008 in it, so I guess it takes everything from where it needs. But either the compiler in Qt or one of the libraries you use that might want the 2010 version...
Hope it helps!
I have to maintain an old VB 6 ActiveX DLL called by another third-party program for which I have no sources. This DLL works and compiles fine against the API of said program for about 6 years and 3 major versions.
But now when I try to compile the DLL against a new major version the mentioned error occurs. It seems the error occurs before "my" code is called so there´s no use debugging or logging. The only remedy was to compile w/o binary compatibility which is no real option. My Google search turned up quite some people with the same problem but no solution.
Does anybody here know how to fix this issue ?
I finally figure out how to diagnose VB6 error 32801 in a systemic way.
My theory is When the VB6 compiler is creating a project or binary compatible library, the compiler decompiles the type information from the referenced library. Error 32801 occurs the source code's type information is not the same as the referenced library.
There is a tool called OLEView. This tool can decompile the COM type information into an IDL text. What I do is decompile the referenced library in to IDL and take the last good build of the failing library. Most times it is a build server version but the build does not work on a developer workstation. Decompile the last good build. Use a text comparison tool, like WINMerge, and find the differences between the type libraries. The differences make it easy to track down the problem.
Depending on the difference will determine how to correct. Mitigation can be done by either correcting the reference DLL, or by source code correction, or source code references.
It sounds like one of the types in the interfaces defined in your new DLL is different from one in the previous DLL. I'm deducing you use types defined in the third party program in your public interfaces of your DLL. It sounds to me like the third party has changed the definition of one of the types but kept the name and GUIDs the same. You could use something like OLE/COM Object viewer to check whether that's true. If it is true then you can complain to the publisher of the 3rd party program. Do you have enough political power to succeed?
Bruce McKinney, the guru who wrote Hardcore Visual Basic 6, ran into the same issue with a structure in a type library, where he changed some of the member types. The only fix he could find was (essentially) to break binary compatibility - and that's after some correspondence with the VB6 compiler team, who he knew fairly well. I don't think anyone else could do better.
There is a discussion about this error on devx.com that seems to indicate that the problem stemmed from Microsoft's Scripting Runtime (scrrun.dll).
FileSystemObject compatibility Unexpected error (32810)
Does your DLL reference that library? If so, can you remove the reference (e.g., replace FileSystemObject functionality with intrinsic VB file handling functions and/or API calls).
Are any of the files associated with the core project being compiled marked as Read-Only (i.e. not checked out of SourceSafe or similar repository)?
*.exp
*.vbw
*.lib
---------------------------
Microsoft Visual Basic
---------------------------
Unexpected error (32810)
---------------------------
OK Помощ
---------------------------
This the message I was getting trying to reference in VBIDE an old OCX that has been recompiled recently.
After somewhat long research the offending lines of code causing this error appeared to be
Property Get MouseActivate() As BookmarkEnum
Just changed this to
Property Get MouseActivate() As Boolean
. . . and the error was gone.
BookmarkEnum is an enum from ADO. Our build server is Server 2003 and my dev machine is Win10. The project references ADO 2.8 but apparently this typelib has some differences on Server 2003 vs Win10