I'm trying to create the same executable using MSVC compiler in Visual Studio, no matter when it is compiled. That has many applications, including reproducibility and version control. However, it always saves the timestamp of when the .exe was created in its headers, and there doesn't seem to be an option in the compiler to turn that off. I tried using MinGW's strip tool, and noticed the timestamp of the File Hdr section is always set 0. However, besides setting the timestamp in the File Hdr, MSVC also sets it in a "Debug" section, as we can see in this PEBear screenshot:
GNU's strip tool isn't able to remove that. What is this section? How to remove it/turn if off. What is "POGO"?
Related
I'm building a library in debug mode and it builds fine, but the built version of this library doesn't indicate in any way that it is built in debug mode. What I mean is that if the library is called mylib and after building it in debug mode I'm getting mylib.dll I don't really know in what mode did I built it. I'd prefer that I would have my output called mylibd.dll or mylib_d_.dll, but is this possible to specify something like it in Visual Studio 2015?
In Visual Studio you can have settings that differ per build configuration. Therefore, to achieve what you want, you would change the library names only for the Debug configuration.
In Solution Explorer, right click on the library in question, and go to Properties. Make sure the Configuration combo is set to Debug. Then, in Configuration Properties select the General group and change the Target Name setting as you like.
There are also several individual settings for the output files generated:
Linker/General/Output File
Linker/Manifest File/Manifest File
Linker/Debugging/Generate Program Database File
Linker/Advanced/Import Library
You can double check the full command line in Linker/Command Line to make sure all the filenames match your expectations.
Similarly, this can be done for static libraries as well. The appropriate configuration properties group in this case is called Librarian.
I am working on a project that was created using cmake. (It's a project that is built for lots of different platforms, including Linux Mac OS, and now iOS.)
The cmake process creates an Xcode project which I then am modifying manually.
One of the things the project contains is dozens of preprocessor macros that drive #ifdefs in the code.
The cmake tool only defines these macros for debug builds. I need to build a release version so I can profile the project. however, the release build fails because of missing preprocessor macros, which cause the #ifdef/#ifndef compiler directives to be set wrong.
I'd really rather not manually enter 35 preprocessor settings, especially since the Xcode editor displays this awkward popup with + and - buttons to add/remove one at a time, and when I'm editing release symbols, I can't see the debug symbols, and copy/paste doesn't work.
What I really want to do is find the internal file in the xcode project that sets these macros, copy it out of the debug settings, and either paste it into the release version, or at the very least, manually enter one macro at a time into the release version by copying it from a textfile containing the macros that were defined in the debug version.
Can somebody tell me where the debug and release preprocessor macros are saved in the Xcode project file hierarchy so I can go read the raw file and possibly modify it?
In your project.pbxproj, search for GCC_PREPROCESSOR_DEFINITIONS. That should be a list of the macros. It should be pretty easy to copy and paste the list from one configuration to the other.
I have a large Visual Studio 2012 Solution with about 15 Projects inside. I would really like to disable debugging symbol generation for a few of these Projects; the rest should allow debugging. All of this is related to the Debug configuration.
I'm having a terrible time making this happen. The only mention of Zi in my pro files looks like this:
# Get rid of debug information
QMAKE_CFLAGS_DEBUG -= -Zi
QMAKE_CXXFLAGS_DEBUG -= -Zi
QMAKE_CXXFLAGS_RELEASE_WITH_DEBUGINFO -= -Zi
But when I load the Solution file, Property Pages -> C/C++ -> All Options -> Debug Information Format, the Program Database (/Zi) option is still displayed. I also removed any mention of Zi in the mkspecs and qmake.conf (even though the above -= lines should have removed it).
So I opened the qmake source code (every file under qmake/generators/win32), and I see that there doesn't seem to be a way to turn off debug symbols; only the absence of a -Zi should prevent it from showing up.
If I set a project to <inherit from parent or project defaults> manually, the Zi option shows up again. Which leads me to believe it's being inherited... but from where?!
I'm losing my mind. Please help.
EDIT 1:
Apparently, the inherited properties comes from the Microsoft.Cpp.* property sheets. Follow the instructions in that link for finding the property sheets inherited by your project, and you can modify them to get rid of the -Zi flag.
It sure would be nice to have a flag that forces None for the Debug Information Format. Anyone know what that might be?
EDIT 2:
Third idea: try to change the default location of the inherited property sheets to somewhere I can control.
The Windows environment variable $(UserRootDir) specifies the location of the inherited property sheets. MSBUILD allegedly allows you to change the value of this variable with the /property command line argument. Unfortunately, I can't figure out how to get qmake to accept the argument. Is there any way to set input arguments to the qmake MAKEFILE_GENERATOR builder?
This quest is starting to feel like a wild goose chase. If CMD had sed abilities, I'd just write a script to change the <DebugInformationFormat> inside the vcxproj file and be done.
I submitted QTBUG-32885 for that 2 months ago, but it hasn't been fixed yet.
For now you can patch your qmake as described in the ticket.
Per default, when compiling a Visual Studio project in release mode, the complete path to the pdb is put into the image file, e.g.:
c:\myprojects\demo\release\test.pdb
Using an undocumented linker switch (/pdbpath:none) one can force Visual Studio 2008 to reduce the full qualified name of the pdb, e.g:
test.pdb
I need to do the same with a project which is still built using VC6.
I tried the "/pdbpath:none" switch at the project settings level, but the linker complains about this unknown switch.
Does anyone knows a method (or a tool) to accomplish this either when linking a VC6 project or afterwards directly at the image level?
Your best bet is to use pdbstr.exe from MS directly. It allows for direct extraction, update, and misc other functions directly, independent of compiler version (up to the last supported version, which I think is VS2013 right now). We use it to add SVN linkings directly to PDBs which we then store in local symbol stores using srctool.
For newer link.exe versions, the syntax changed.
The option you want is now /pdbaltpath:%_PDB%
It is documented on MSDN: https://msdn.microsoft.com/en-us/library/dd998269.aspx
%_PDB% expands to the file name of the actual .pdb file without any path information
For VC6, you might want to continue using the same compilers but a new version of link.exe.
The Windows Driver Kits also come with a tool named binplace.exe which can modify this information post-build.
I've written a command-line OpenCL compiler. I'd like to have VS compile my kernel source files using this whenever I build the C# project that includes them. I've looked around and found information and custom build tasks, custom tools, etc, but I haven't been able to get it to work correctly.
How can I tell VS to run my exe on the source files in the same way that it runs the c# compiler, etc for other files in the project?
I report errors from this tool by calling Console.Error.WriteLine(). This dutifully places the errors in the Output pane, where I can double-click them, taking me to the appropriate place in the .cl kernel source file. However, the errors don't appear in the VS error panel. ??
Alternatively, if anyone's aware of an existing OpenCL compiler - it's annoying to have to run the host application just to compile the kernel - I'd appreciate a link.
I've managed to get this working by adding a post-build step to the project options. However, I'd really prefer for this exe to be run for every *.cl file in the project.
Update I had neglected to include an error code when formatting my error messages. Correcting them to match any of the formats listed here took care of that issue. Still trying to figure out how to associate an exe with a given file extension, though.