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.
Related
I have a CUDA project that originates from a C++ project. I will need to add CUDA code to different compilation units over time. Let's say I have two files, kernel.cuh and kernel.cu that contain my kernels' headers and bodies. Then, I change the extension of a module from .cpp to .cu, include kernel.cuh, and call my kernels using the < syntax (myKernel<<<blocksPerGrid, threadsPerBlock>>>). When I do this, I get an error in the module that says syntax error: < . The problem is that this file is still compiled by the C++ compiler instead of nvcc, and I don't know how to change that in Visual Studio manually. I thought the compiler was chosen according to the extension of the files. The problem wouldn't go away until I create a new project from scratch. Does anyone know how to fix this so that I will not need to create a new project?
For the question to get off the unanswered list, I will give a simple solution that solves the problem but does not answer my question about VS. I didn't have to make a new project from scratch. I only had to remove the file from the project and then add it again (Idk why I hadn't tried this before).
Is it possible to compile libexif with Visual Studio 2010? I have been trying to do so and have been running into a whole slew of problems. I cannot find any information about whether anybody has successfully done this before. I know I can use MinGW to compile the library, but I am in a situation where I need it to be compiled with Visual Studio and then need to link to it from a Visual C++ app. Is this possible?
To answer your question: Yes it is possible... but it is a bit of a hack. Libexif uses functions that MSVC has chosen not to implement. See my working example VS2010 project below (if you don't like downloading files then skip to my explanation of what needed changing to get it to work below):
https://www.dropbox.com/s/l6wowl8pouux01a/libexif-0.6.21_CompiledInVS2010%2BExample.7z?dl=0
To elaborate, the issues that needed a "hack" (as hinted in the LibExif readme-win32.txt documentation) are:
Libexif uses inline in several places which is not defined in VS for C, only C++ (see this)
Libexif uses snprintf extensively in the code which is not defined in VS (see here)
You need to create the config.h yourself without a ./configure command to help you. You could read through the script but most of it doesn't make sense for Windows VS2010.
You will need to define GETTEXT_PACKAGE because it's probably setup in the configure file. I just choose UTF-8, whether that is correct or not I'm not sure.
There was a random unsigned static * that needed to be moved from a .c file to the .h file as C in VS doesn't allow you to create new variables inside functions in the particular way they were trying to do.
Read the "readme-win32.txt" file. Advice is:
hack yourself a build system somehow. This seems to be the Windows way of doing things.
Don't get your hopes up. The *nix way of doing things is the configuration script that needs to be run first. It auto-generates source files to marry the library to the specific flavor of *nix. The configuration script is almost half a megabyte. Three times as much code as in the actual .c files :) You cannot reasonably get that working without MinGW so you can execute the script. Once you got that done, you've got a better shot at it with a VS solution. As long as it doesn't use too much C99 specific syntax.
I would like to add a small feature to QuantLib and compile it together with SWIG bindings to use in a C# project in Visual Studio 2010. I am however having problems at almost every turn. What are the steps involved in building QuantLib in Visual Studio 2010, creating the SWIG bindings, and building the C# project?
I downloaded QuantLib from http://sourceforge.net/projects/quantlib/files/
I downloaded Boost from http://sourceforge.net/projects/boost/files/boost/1.49.0/
I downloaded the QuantLib+SWIG bindings from http://sourceforge.net/projects/quantlib/files/QuantLib/1.0/bindings/QuantLib-SWIG-1.0.zip/download
I set an environment variable QL_DIR to "C:\pathToFolder\QuantLib-1.2\lib" (computer > properties > advanced system settings > advanced > environment variables)
I ran the swig.cmd file located in C:\pathToFolder\QuantLib-SWIG-1.0\CSharp
I opened QuantLib_vc9.sln in Visual Studio 2010
For the NQuantLibc project:
I included my Boost and QuantLib directories in the header directories.
I included my QuantLib/lib directory in the library directories.
I successfully built the NQuantLibc project
For the NQuantLib_vc9 project:
I made it dependent on the NQuantLibc project.
I successfully built the NQuantLib_vc9 project.
For the EquityOption_vc9 project:
I made it dependent on the NQuantLib_vc9 project.
I successfully built the EquityOption_vc9 project.
When I try to run the EquityOption_vc9 project, I get a TypeInitializationException, "An attempt was made to load a program with an incorrect format."
Here's the full exception:
System.TypeInitializationException was unhandled
Message=The type initializer for 'QuantLib.NQuantLibcPINVOKE' threw an exception.
Source=NQuantLib
TypeName=QuantLib.NQuantLibcPINVOKE
StackTrace:
at QuantLib.NQuantLibcPINVOKE.new_Date__SWIG_1(Int32 jarg1, Int32 jarg2, Int32 jarg3)
at QuantLib.Date..ctor(Int32 d, Month m, Int32 y) in C:\Users\JRobinson\Desktop\QuantLib-SWIG-1.0\CSharp\csharp\Date.cs:line 48
at EquityOptionTest.EquityOption.Main(String[] args) in C:\Users\JRobinson\Desktop\QuantLib-SWIG-1.0\CSharp\examples\EquityOption.cs:line 43
at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException: System.TypeInitializationException
Message=The type initializer for 'SWIGExceptionHelper' threw an exception.
Source=NQuantLib
TypeName=SWIGExceptionHelper
StackTrace:
at QuantLib.NQuantLibcPINVOKE.SWIGExceptionHelper..ctor()
at QuantLib.NQuantLibcPINVOKE..cctor() in C:\Users\JRobinson\Desktop\QuantLib-SWIG-1.0\CSharp\csharp\NQuantLibcPINVOKE.cs:line 126
InnerException: System.BadImageFormatException
Message=An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
Source=NQuantLib
StackTrace:
at [long string removed]
at QuantLib.NQuantLibcPINVOKE.SWIGExceptionHelper..cctor() in C:\Users\JRobinson\Desktop\QuantLib-SWIG-1.0\CSharp\csharp\NQuantLibcPINVOKE.cs:line 106
InnerException:
Note that I built everything with the Debug configuation. I also tried this using the Release configuration. It didn't work.
I wish I could find a complete set of instructions detailing how to build this type of project. I found some instructions here, Compiling Quantlib via SWIG for C# but i couldn't get it to work.
The QuantLib page contains instructions for building QuantLib in Visual Studio 2010, http://quantlib.org/install/vc10.shtml but I need help creating the SWIG bindings.
Resolver Systems has pre-built C# bindings that work for me. http://www.resolversystems.com/products/quantlib-binary/ I was able to run QuantLib code in C# just fine with this package. My problem is that I need to add a small feature to the QuantLib code for use in my C# project. This is the reason I need to re-build QuantLib and re-create the SWIG bindings.
I know about QLNet, the C# port of QuantLib, http://sourceforge.net/projects/qlnet/, but this project is missing some pieces and I think that it is no longer being actively developed. Specifically, I need to be able to price options that pay discrete dividends. QLNet is missing some of the code for this. I tried porting the necessary code from QuantLib to QLNet, but my C++ must be rusty because I was getting incorrect output.
Note that the small feature I need to add to QuantLib is the ability to handle fractional days. I was able to add this feature to QLNet, and it is a small feature indeed. This tiny edit is delaying my project. I would greatly appreciate help on this issue.
There indeed seems to be a problem with the SWIG wrappers as distributed and .Net 4.0.
I'm not working on that platform, so I can't speak based on personal experience. However, the issue was discussed recently on the QuantLib mailing list, and the solution contributed there by Mark Gillis was reported to work. You can read the relevant thread at http://thread.gmane.org/gmane.comp.finance.quantlib.user/8238. Hope this helps...
I struggled with this exact error message a little while back, and visited this page, as Google search might say, "many times".
In the end, my error was fairly benign, but it took me a while to sort it out.
I was using C# wrappers by SWIG to access QuantLib C++ library. I used Excel DNA Integration to make my Quantlib.xll, and I also built a few .exes that access Quantlib.
Various situations would cause this error to appear for me, most especially
Running the .exes off of my desktop ("sometimes")
Distributing my XLL to other users (always).
In the end, I discovered that the distribution that I was getting from the bin folder of my VS2010 (and 12, 13, 15) projects included NQuantLib (the C# wrapper code) but did not include NQuantLibc (the C++ unmanaged code being called).
The XLL and the exes worked on my machine sometimes because I probably helped them (via changing my path?) to find the missing C++ code, but I did not recall that step in the process.
Once I figured it out (using a StackOverflow hint to check the "inner exception" on the error when running the code on another machine and opening up VS to debug when it bombed), the problem went away.
A bit of ignorance on my part that cost me a bit of time but earned me a bit of experience:
this error, for me, was caused by not putting the unmanaged (C++) library where the managed (C#) library could find it.
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