I did some looking up on that const thing. Apparently that const is 'supposed' to be there, but it is not strictly required. However there is a bug in VS2k3 (VS7) through VS2k8 (VS9) (no clue if it has been fixed yet) that requires it to be there when the functor is being called through a const qualified interface, such as through stl containers. They state that a bug report has been filed, but regardless of if it is filled or not, in such functors you are 'supposed' to have a const there anyway. No clue what the standard actually says on this, but what they said makes sense...
Okay, I got here and cleaned out every trace of LLVM. I then got the latest from SVN (at the time: 60621). CMaked it, built it. Changed nothing, no defaults, no anything and the build result is file BuildLog_2008_12_05_22_19.txt (as a 7z file). It has lots of errors, all still seem to relate to the const qualification, but I still changed nothing. I compiled again, just to get a build log that contained basically nothing but the errors since everything else was built: BuildLog_2008_12_05_22_19.txt (as a 7z file) I then made that const change I mentioned earlier and built again, all the errors disappeared except for the basic_string linking in debug mode as before: BuildLog_2008_12_06_01_21.txt (as a 7z file) I then compiled it as-is once more, just to get a build log of basically nothing but the errors as is: BuildLog_2008_12_06_01_24.txt (as a 7z file) I then cleaned everything out again, made a new cmake and all. This time I made the const change from the get-go, pretty much same as excepted, everything worked except some of the debug linkings for basic_string: BuildLog_2008_12_06_03_12.txt (as a 7z file) I then just built it once more to get a build log of just the errors, basically the same as before. So it seems that the const qualifier *really* needs to be on here for VS2k5, and as it is 'correct' anyway, it should work everywhere. As for the basic_string linking errors, no clue, have not looked at it yet, might be a cmake thing. -------------- next part -------------- A non-text attachment was scrubbed... Name: BuildLog_2008_12_05_22_19.7z Type: application/octet-stream Size: 12854 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081206/0d9915d7/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: BuildLog_2008_12_05_22_25.7z Type: application/octet-stream Size: 6932 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081206/0d9915d7/attachment-0001.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: BuildLog_2008_12_06_01_21.7z Type: application/octet-stream Size: 8511 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081206/0d9915d7/attachment-0002.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: BuildLog_2008_12_06_01_24.7z Type: application/octet-stream Size: 4422 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081206/0d9915d7/attachment-0003.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: BuildLog_2008_12_06_03_12.7z Type: application/octet-stream Size: 13762 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081206/0d9915d7/attachment-0004.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: BuildLog_2008_12_06_03_28.7z Type: application/octet-stream Size: 4430 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081206/0d9915d7/attachment-0005.obj>
OvermindDL1 <overminddl1 at gmail.com> writes: [snip] tblgen.exe builds fine on my vs2005 install with the Debug configuration. You are simultaneously building all the configurations (Relase, Debug, RelWithDebInfo, etc). What happens if you do a "Clean Solution" and then build just the Debug configuration? We need to look at the actual commands VS is executing. Please show the contents of r:\SDKs\llvm\trunk_VC8nocrap_building\utils\TableGen\tblgen.dir\Debug\BuildLog.htm -- Oscar
On Sat, Dec 6, 2008 at 9:48 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:> OvermindDL1 <overminddl1 at gmail.com> writes: > >> I had also tried that before, but let me clean it and do it again to >> give you just a debug build log (since the current log just contains >> errors anyway, seeing the whole build might be useful). So what is >> attached is from another completely clean build, except I added const >> to that functor (else it just does not build for me). Attached is the >> build log, I have everything from a debug build if you need it (I >> built no other configurations beyond debug). > > Your INCLUDE and LIB environment variables contains lots of stuff that > may be interfering with the build. Please try after removing all > third-party libraries from those variables. > > You can try removing _SECURE_SCL and _HAS_ITERATOR_DEBUGGING from the > defines too. You define them to 0, which may be not a good idea, as that > produces different results depending on how you test the variable (with > #ifdef or with #if).I finally got some time to where I could delve into things. First, let me say it had nothing to do with my includes, libraries, or whatnot (those defines I require for everything I compile, they fix some things Microsoft horribly broken). The "const" still needs to be added to the function, that is correct and has to be done. However, the string error in debug builds was a bug that was fixed in VS2k5SP1; I, apparently, was running the SP1 beta. So when I add const to that functor, everything builds nice and fine (well, besides the ton of warnings), the example apps work, etc... and so forth. Thanks for the help though. But yes, let me say again, that functor still needs const added to it. It is correct for the spec, and it is required for at least VC2k5 (I tried building without it by removing my includes, libs, defines, and about ten other things, it is needed in every case, spent about 8 hours on all this so I am extremely sure). Attached is the patch; should I post it to the LLVM list as well? Oh, and yes, instead of VC2k5 being the minimum requirement, it should be VC2k5SP1 (although VC2k3 does not have that issue, if someone managed to get around to fixing the friend errors that VC2k3 is bugged with). Actually, I am forwarding this to the list anyway, good record in case anyone searches. -------------- next part -------------- A non-text attachment was scrubbed... Name: FunctorPatch.patch Type: application/octet-stream Size: 418 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081207/2b43b7b3/attachment.obj>
OvermindDL1 <overminddl1 at gmail.com> writes: [snip]> But yes, let me say again, that functor still needs const added to it. > It is correct for the spec, and it is required for at least VC2k5 (I > tried building without it by removing my includes, libs, defines, and > about ten other things, it is needed in every case, spent about 8 > hours on all this so I am extremely sure). Attached is the patch; > should I post it to the LLVM list as well?Please send the patch to llvm-commits at cs.uiuc.edu> Oh, and yes, instead of VC2k5 being the minimum requirement, it should > be VC2k5SP1[snip] It would be great if you submit a patch for http://www.llvm.org/docs/GettingStarted.html#requirements and/or http://www.llvm.org/docs/GettingStarted.html#brokengcc BTW, that section should be renamed to "broken compilers and other tools", since gcc is not the only compiler that builds LLVM. [snip] -- Oscar