After building with CMAKE for visual studio 2015, I found that there were some build errors that required me to edit the code. I feel that this should not be necessary and would like to know if I might have done something wrong in build process to make these errors surface
Firstly I had to correct the compiler name from vc130 to vc140 in the files include/CGAL/auto-link/auto-link.h and cmake/module/CGAL_GeneratorSpecificSettings.cmake. I assume that this is simply because it has not been tested VS2015 and someone just assumed that vc130 would follow vc120.
The other issue I ran into was that eight functions that did not compile. These were the functions
Segment_2<R_>::min
Segment_2<R_>::max
Segment_2<R_>::vertex
Segment_2<R_>::point
Segment_2<R_>::operator[]
Segment_3<R_>::min
Segment_3<R_>::max
The issue seemed to be that the type signature of the implementation did not match that of the declaration. I tried fixing the type signature, but was unable to get it to match exactly. To fix this I ended up moving the implementation of these functions into the declaration. I would like why this is apparently necessary as presumably it compiles for other people. Sloriot commented that it was because the VS2015 compiler was more recent than the one CGAL is tested with. It is however my understanding that the visual studio compilers are backwards compatible, an thus it should not break the code to update the compiler.
The first version of CGAL officially compatible with VS2015 will be CGAL 4.7.
It seems that the new version of the Microsoft has some issues compiling valid C++ code it was accepting before. This explains why the release 4.6 of CGAL (or prior versions) has some compilation issues with that new compiler.
Related
I am working on making a pretty trivial change to an old existing pascal source file. I have the source code, but need to generate a new hex file with my changes.
First, I tried compiling with "Embedded Pascal", which is the program used by my predecessor. Unfortunately, it is an unregistered copy and gives the message that the file is too large for the unregistered version. Support for and even the homepage for the project has disappeared (old), so I have no idea how I would register.
I tried a couple other compilers, "Free Pascal" and "Turbo51", and they are both giving similar errors:
Filename.pas (79): Error 36: BEGIN expected.
Linkcode $2E
^
The source code begins with
Linkcode $2E
LinkData $0A // normally 8 - make room for capacitance data
Program Main; Vector LongJmp Startup_Vector; //This inserts the start to the main routine.
uses IntLib;
I'm not well-versed in Pascal or embedded programming, but as I understand it, the Linkcode and LinkData lines are required to set up the RAM as needed. Following the "Const" and "var" declarations are subroutines that indeed start with procedure... begin... end.
I realize that Pascal is a bit out of date, but we are stuck with it and our old micro. Any ideas why previously working source code with trivial changes cannot be compiled? I am willing to consider other compilers, including paid options, if any are available with decent support. I am using Windows 10 x64 processor to compile, and flashing to an Atmel 89C51RC2.
If more source code is needed for diagnosis, please let me know what in particular, as I'll need to change some proprietary information before posting. Thanks!
Statements like linkcode and linkdata are not general, but target and compiler specific. Unless you have the know-how to reengineer to a different compiler, getting the original one is best.
Thanks to all for the information. While I didn't find an exact solution here, your comments were helpful for me to understand just how compiler-specific the Pascal code was.
In the end, I was able to get into my predecessors files and transfer registration, solving the issue for now. As suggested, I think I will port to C in the future to avoid fighting all the unsupported compiler nonsense.
I develop and maintain a very large opengl application, written using qt library. I'm switching from qt 4 to qt 5. I downloaded the qt 5.0.0 Windows (8) Visual Studio 2010 precompiled package. Unfortunately I discovered that I get millions of OpenGL errors caused by the OpenGL ES 2 support provided by the precompiled package. So, I downloaded the source code and I recompiled qt using the -opengl desktop flag on the configure step (for further details on the problem please refer here). The opengl compiler errors disappear but I still have hundreds compiler errors everytime inside the Qt library itself there is a reference to two macros Q_STATIC_ASSERT and Q_STATIC_ASSERT_X.
The typical kind of errors i get are:
- error C2062: type 'void' unexpected
- error C2238: unexpected token(s) preceding ';'
Some suggestions?
Thanks
As described in the comment to the question I solved the issue by looking for redefinition of static_assert and commenting it.
In particular my code was using the VCGLib library wich was redefining the assert in base.h
I have an application which relies on several libraries built by other people in my organization, one of which has stopped working. I get this error in the command-line:
Unhandled Exception: System.IO.FileLoadException: A procedure imported by 'XXX.dll' could not be loaded.
I opened up Dependency Walker to try and track down the source of the problem, although I should say that I am brand-new to Dependency Walker and I don't really know what I'm doing. Here's what I see in the log window:
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Which seems straightforward, except:
Due to my unfamiliarity with DW, I can't seem to find what module this error is actually referring to
The same DLL that ships with old version of the application, which still works, shows the same thing in Dependency Walker
The only difference I can find between the old and new DLL is that KERNEL32.DLL shows up as red in the newer one, and the function K32EnumProcessModules appears as red (not exported). This same function does not appear at all (green or otherwise) for the old DLL.
To summarize so far: one DLL works and the other doesn't; both show up as 'bad' in Dependency Walker, but in only one does the function K32EnumProcessModules appear as no good. I do not know if this function is what is causing the "unresolved import" error and would like to find out.
The only change in the application I have made that I think could've caused this is upgrading the runtime from .NET 2.5 to .NET 4. This upgrade was made for reasons unrelated to this DLL, and should not affect it: the DLL does not make any calls to .NET components higher than 2.5, and other people in my organization using the same library have reported that it works fine with .NET 4.
I realize I'm providing sparse information, mostly because I'm not sure what information will help troubleshoot this problem. Please let me know if there are tests you'd like me to perform to find out more.
Probably releated to this https://blogs.msdn.microsoft.com/vcblog/2009/08/27/windows-sdk-v7-0v7-0a-incompatibility-workaround/
Defining PSAPI_VERSION=1 might help.
I'm getting a "Compilation exited with code 134" when attempting to use the "LLVM Optimizing Compiler" switch for release iPhone builds, using MonoTouch 4.0.1.
I don't get much information from build output window at all - just:
"Compilation exited with code 134, command:"
MONO_PATH=(snip)/bin/iPhone/Release/LSiOS.app /Developer/MonoTouch/usr/bin/arm-darwin-mono --llvm --aot=mtriple=armv7-darwin,nimt-trampolines=2048,full,static,asmonly,nodebug,llvm-path=/Developer/MonoTouch/LLVM/bin/,outfile=/var/folders/03/033pAAGuHgGkIy4CorbVV++++TI/-Tmp-/tmp38107451.tmp/Newtonsoft.Json.MonoTouch.dll.7.s "(snip)/bin/iPhone/Release/LSiOS.app/Newtonsoft.Json.MonoTouch.dll"
Mono Ahead of Time compiler - compiling assembly (snip)/mscorlib.dll
What is odd is that in earlier command lines, there is a correlation between the DLL mentioned in the arm-darwin-mono command line and what is the compiling, but in this case it says "mscorlib.dll".
Any thoughts?
I have found a few cases (googling and from bugzilla.xamarin.com) where the error code 134 is related to Mono.Linker being too aggressive (removing something that's needed).
This is easy to confirm by turning off the linker, i.e. "Don't link" in Linker Options. If the build works then you can try isolating the assembly where the linker makes a mistake.
E.g. add a "--linkskip=mscorlib" to the mtouch extra parameters and re-enable linking. This will link everything (Link All) or all SDK (Link SDK assemblies) except the assembly you selected (mscorlib in the example). That's only a workaround and a bug report should be filled so the issue can be fixed properly (and get you all the linker advantages).
However be warned that there are other issues sharing the same error code, like:
http://ios.xamarin.com/Documentation/Troubleshoot#Error_134.3a_mtouch_failed_with_the_following_message.3a
YMMV
mtouch does its native builds in parallel so the logs can be confusing, e.g. you can see a bit of assembly X output followed by some assembly Y output.
Reading the full log might help you (or us) to pinpoint the issue.
I was having the exact same problem Scolestock. My app would build fine until I enabled llvm, then it was "Compilation exited with code 134, command" when trying to build the 7s for the app itself.
I'm elated to say that after 2 days of painstakingly whittling my app down to the core problem, I was able to isolate the issue to the usage of embedded dictionaries such as:
Dictionary<enum, Dictionary<enum, value>>
I was able to fix this by defining a class for the embedded dictionary and using that instead:
public class MyDefinition : Dictionary<enum, value>
{
}
...
public Dictionary<enum, MyDefinition>
Not sure if this will help you, but hopefully it'll help some poor soul who decides to use embedded dictionaries and runs into my same problem.
I have a VB.Net solution that another developer created and I'm trying to compile it on our build machine (it compiles on their machine) but with one of the projects I get an error saying something along the lines of:
Imyinterface is ambiguous in the namespace anamespaceassembly.
I have tried with no success:
examined the references to see any obvious errors
removed and re-added the assembly in question
searched the system for the same dll
attempted to compile the original deve's src (.v the source control version)
examined the assembly with ildasm.exe
I usually code in C# and have not seen this error before (in this form at least), not that it is VB.Net specific but the UI for adding/viewing references is slightly different so I thought maybe VB.Net might do something different with references.
I also tried to compile on another machine, and it compiles ok. So I assume it is something with the build machine but I'm not sure what. Other conflicting assemblies somehow not referenced by the project, is that possible??
Any ideas?
Check your references if you have two versions of the same reference (eg. Microsoft.ReportViewer.Webforms version 10.0.0.0 and Microsoft.ReportViewer.Webforms 8.0.0.0) You will get this error. Delete the oldest and you should be good. I do this to myself all of the time.
There can be a few causes for this error. In VB, you should be aware that more names then you're used to from C# are available without class specification. Also, case does not matter in VB, which can further liken the chances on collisions.
Even in the event that you don't find the actual conflicting issue, you can resolve this in the same way you would in C#: rename it in the Imports statement:
Imports IM = yourAssembly.Imyinterface
Then change the code such that uses of Imyinterface are replace with IM.
NOTE: If the error does not point to a particular line, the conflict may be out of your hand. Normally, a full Clean Solution and Rebuild helps a lot, but occasionally a misbehaving file (i.e., another error) causes this error to popup first without clear source. Try to rollback recent changes to the place where it did work.
You also say it worked on another machine. Chances are that your machine is having a different version of MS Visual Studio or .NET. Check and compare the exact versions.
I was facing same issue. I upgraded my application from vb6 to vb.net and when i change the build configuration from DEBUG to RELEASE then i got AMBIGUOUS errors.
I found dulicate references folder in solution Explorer. I removed those duplicate referecnces and Build sucessfully. I Hope it may help others.
Thanks for the responses! I tried each but still was having issues.
One point of info I left out of the original question was that the VB.net projects are upgrades from VB6 projects. At the time I did not think that was relevant.
After investigating further the build machine was used to build the VB6 projects also. So I ran 'reg32 /u' on the vb6 dlls and that seemed to fix the VB.net issue.
Not exactly sure why this fixed it since I was not referencing the VB6 dlls, I'm guessing something to do with ambiguous entries in the registry confusing the vb.net project.