Compiler/Linker is not working with .manifest files - c++

Some background:
I work with the c++ language in the Code::Blocks IDE on Windows 10. Usually, when I install Code::Blocks I use the mingw-setup build so I can just get right into programming. Due to this I have no experience with setting up compilers and whatnot. Recently a friend asked me to make a program for him so i took him up on it and decided to start working. When it came the time to build it didnt work and I learned that the compiler was outdated so I moved to a new one.
The Problem:
When I tried to make the program for my friend require administrator perms with the new compiler, I made my normal manifest file. The program built and all was good but I realized that my program was not requiring administrator permissions. I went to my old compiler to see if I had messed something up and I had not, the new compiler just didn't work with the manifest file.
What I Previously Had Been Able To Do:
Previously, before I changed my compiler, I was able to put the name.exe.manifest file into the same folder as the name.exe file, build it, then I was golden. Now, even when putting it into the folder it doesnt work.
Questions:
Are there any MSYS2 packages I can use to fix this?
What exactly is the problem?
How can I prevent this in the future?
Besides MSYS2 packages, how else can I fix this?
Some files from my custom build are missing in comparison to the Code::Blocks one, If I copy them over to my build, will it work?
What I Tried:
I have tried putting the manifest file in several different folders
I have tried changing the linker settings to include "-o Dir/SubDir/Manifest"
I have tried having the linker search different directories
I have tried researching the problem and asking around different places. (My conclusion was that it was a problem with a compiler/linker or I didnt have a file I needed.
My Maifest File Code:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="1.0.0.0"
processorArchitecture="X86"
name="NAME HERE"
type="win32"/>
<description>DESCRIPTION HERE</description>
<!-- Identify the application security requirements. -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="requireAdministrator"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Mingw Compiler (Code::Blocks):
Image: (In MingW: The Normal Code::Blocks Build)
Image: (In MingW: The Normal Code::Blocks Build) > Bin Folder
MSYS2 Compiler (Custom Compiler):
Image: MSYS2 Mingw64: Custom Build
Image: MSYS2 Mingw64: Custom Build > Bin folder*
*If you look, the normal Code::Blocks Mingw compiler's bin directory pales in comparison to my build's.
==========================================================================
I will be happy to answer any questions you have!

Related

Setting SFML up with NetBeans in Windows

Hi I am having problems with trying to get sfml going with netbeans. Here is a short video of what I have done. video
After listening to HEKTO I now downloaded the MSYS. I removed the static libraries and get this error now:
The application failed with exit code -1073741515 (0xc0000135).
This could indicate that no required .dll was found in the PATH.
Please try to start the following command from the command shell (cmd.exe).
This may give some additional information.
C:\Users\david\Documents\NetBeansProjects\tester\dist\Debug\MinGW_1-Windows\tester.exe
RUN FAILED (exit value -1,073,741,515, total time: 58ms)
After adding system path.. heres new img:
system path img
The SFML developers recommend the exact match between your MinGW version and your SFML version - please see this page, especially these three lines:
The compiler versions have to match 100%!
Here are links to the specific MinGW compiler versions used to build the provided packages:
TDM 5.1.0 (32-bit), MinGW Builds 7.3.0 (32-bit), MinGW Builds 7.3.0 (64-bit)
Your MinGW compiler is 8.2.0 - it doesn't match. So you'll need to download the MinGW using links from this page and install it manually.
Also you try to link with static libraries (with suffix _s). In this case you have to add other libraries to the linker setup - please see here. If to use dynamic libraries then you won't need any additional libraries, however the SFML directory with its DLLs will need to be added to the system path.
UPDATE. Your question has been rewritten many times, so my answer has become irrelevant - this is not good, the question can be updated to improve it, but please not to rewrite it completely following additional information given to you in comments. References to videos and pictures aren't welcomed here also. Your question must be self-contained and potentially helpful for others, looking for help in similar situations.
That said I'll add two tips for future generations:
Don't use relative paths for include and lib directories in the NetBeans compiler and linker setup - use only absolute paths.
MinGW distributions, referenced on the SFML downloading page, don't contain the MSYS (small collection of Unix tools, which includes make.exe). You'll need to download and install the MSYS separately, for example using the MinGW installer with msys-base package only.

Installing Boost v1.70 in Visual Studio 2019 using Nuget

I'm learning C++, some of the Boost libraries and VS2019 Community Edition. I'm currently reading through the Boost website's online material and the book Learning Boost C++ Libraries, trying to follow along. I would like to update to 1.70.0 and figure out exactly why my code is building correctly. I know, I know...if it's working why question it? Well, the truth is I just don't understand why!
I wasn't aware of Nuget and vcpkg prior to downloading and installing Boost 1.68.0 manually (BTW, there seems to be way too many ways of installing the libraries and it's quite confusing). I have since deleted the original Boost installation directory and tried to install the Boost libraries through Nuget in VS2019. This didn't appear to be successful (although I suspect vcpkg (see below) has something to do with it). I was getting a single linker error (can't find the .lib file) which I eventually resolved (don't ask me how...it's a confusing story involving creating a new project and cutting/pasting my code. Now it works; go figure).
Currently, when I begin an #include directive () in my code I can see the path to the files which is buried under D:\...\vcpkg\installed\x86-windows\include\boost. I've never used vcpkg directly so I have no idea why it's there. The Property Pages for the project don't list the paths under C/C++ > Additional Include Directories or under Linker > Additional Library Directories so I haven't a clue from where the compiler and linker are getting the references. There appear to be no packages installed under the Nuget UI.
Ideally, I would like to start over with the Boost installation and use VS internal tools to do so. I will probably have several different VS solutions as I explore Boost and would prefer Boost to be available to all future projects. Is that possible?
Any advice?
One thing to keep in mind is that the "boost" package only installs the header only libraries, it doesn't install all the libraries that require a binary library.
To install the binary libraries, you need to install individual packages, for instance "boost_log-vc141" is the boost logging library.
First, install the boost package into your project using NuGet. You should see a packages.config added to your project that looks like this:
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="boost" version="1.70.0.0" targetFramework="native" />
</packages>
Next, include the desired boost header file:
#include <boost\array.hpp>
You can confirm that the header is being loaded from the correct path by placing the caret after the hpp, pressing CTRL+SPACE, then hovering hovering over the item in the context list:

How to include JBOSS modules in compile path

After applying patches to JBOSS 6.4 to bring it to 6.4.14, my build breaks.
I am using the various modules in the build path using **/*.jar. (See below for code)
RedHat disables old versions of jars when applying patches red hat doc
This is by design.
When applying a patch to EAP 6.2.0 to build EAP 6.2.x , the Patch tool does not replace the existing files. It will place new files under the folder $JBOSS_HOME/modules/system/layers/base/.overlays/_ and cripple the original files by flipping a bit in the end of central directory record to prevent them from being used.
How can I include all the jars in the modules directory except for the disabled ones?
Relevant portion of my build.xml file.
<property name="jbossmodules" value="${env.JBOSS_HOME}/modules" />
<path id="class.path">
<pathelement path="${class.lib}" />
<pathelement path="${java.class.path}" />
[...]
<fileset dir="${jbossmodules}">
<include name="**/*.jar" />
</fileset>
I worked with Redhat support. If one has the appropriate user type, one can download a directory of jars to compile against. In short Redhat seems to discourage compiling against a live patched version of JBOSS. But neither do they make it easy to get a set of jars one can compile against.

QT missing dll after deploy

I've copied all of the dlls from QT that were required, and my application works fine on my Windows server machine.
However when trying to run it on a Windows 7 box i get the following message:
This application failed to start because it could not find or load he
Qt platform plugin "windows".
Reinstallning the application may fix this problem.
Any ideas what I'm missing here?
I'd scratched my head over this some time ago. It turned out that this was caused not by missing qwindows.dll, but rather one of libEGL.dll or libGLESv2.dll. This was tricky, because dependency walker does not show those libs as direct dependencies.
If you want to test on your dev machine, whether your app has all required libs, fire up console issue SET PATH=, cd to your app directory and run it.
This is complete list of dlls that my app is using (Qt 5.2 / QtQuick app only, rest is C++). QtQuick is nice but the size of Qt dependencies is a bit scary:
icu*.dll - depending on whether you've compiled with ICU
libEGL.dll
libGLESv2.dll
Qt5Core.dll
Qt5Gui.dll
Qt5Network.dll
Qt5Qml.dll
Qt5Quick.dll
Qt5Widgets.dll
Widely used solution is put all necessary libraris in the folder of application.
What are libraries application need?
Run application and see error message:
The program can't start because <Library name> is missing from your computer.
Try reinstalling the program to fix this problem
Library set is depended from Qt version. Run several times application and each time copy required lib you found what is neeeded for application.
In my case (Qt 5.2.1) there are
icudt51.dll,
icuin51.dll,
icuuc51.dll,
libgcc_s_dw2-1.dll,
libstdc++-6.dll,
libwinpthread-1.dll,
Qt5Core.dll,
Qt5Gui.dll,
Qt5Widgets.dll.
All libs you can found in your Qt install folder. But don't use libraries from Tools\QtCreator folder, because QtCreator has another version of these libraries!
In case of error:
This application failed to start because it could not find or load he Qt platform plugin windows. Reinstallning the application may fix this problem.
You should create folder platforms and copy qwindows.dll into it.
If you still got error you should create qt.conf file in application's folder with content:
[Paths]
Plugins=plugins
This solution is described in https://qt-project.org/forums/viewthread/37265
More information about qt.conf you can find at http://qt-project.org/doc/qt-5/qt-conf.html
In latest versions of Qt you can find deploy tool (since 5.2). This tool find necessary libraries for application and copy into application folder. You can run it something like this:
call c:\Qt\QtX.Y.Z\X.Y.Z\mingw48_32\bin\qtenv2.bat
cd /d "c:\path\to\your\application\folder"
windeployqt.exe your_application.exe
Generally it works well. But I notice that some libraries are not copied, but you can found by method is descibed at beggining of post. More useful information you can find at
http://qt-project.org/doc/qt-5/windows-deployment.html
In rare cases yo can got this error if some library is missing but not appear in error message above. Example: Qt 5.1.1: Application failed to start because platform plugin "windows" is missing
I wasn't in this situation, so I can't tell more.

Qt - 4.7.3 - How to make static build

I used 4.7.2 for the past months. Now I downloaded 4.7.3. Now I am searching to type "configure -static". But I don't know where the hell "the qt path". Can anybody shed a light on this issue.
Download the source package here. Download and install your favorite perl distribution. I must warn you that Strawberry perl comes with its own toolchain and that may get used instead of the MinGW you downloaded. Use ActivePerl if you don't want any trouble, or build it yourself.
Unzip it to say, C:\Qt-source so that there is a configure.exe in C:\Qt-source
Open the toolchain's command prompt
a) If you're using the Visual Studio compiler, search in the "start" menu for a CMD shortcut in the Visual Studio folder. The Windows SDK also has this shortcut.
b) If you're using MinGW, either use the accompanying mingwvars.cmd, or open a command prompt, (Run->"cmd.exe") and type set PATH=C:\path\to\mingw\bin;%PATH%. Try gcc -v to see if it can be found.
Make a build directory, preferable something like C:\Qt. Do set QTPATH=C:\Qt and set PATH=C:\Qt\bin;%PATH% and cd C:\Qt, and type:
..\Qt-source\configure -static
After configure finishes, you'll either have to type nmake (Visual Studio) or mingw32-make.
Go do something else, because it will take a while.
Some tips that result from my experience, and add a bit more to the answer of rubenv:
Pass the install directory as a flag of the configure; be sure to choose a different directory from the one where you have stored a non-static version of Qt!
Some modules will likely cause you troubles when compiling statically because you need to resolve the dependencies statically; one example is webkit, so if you don't need it be sure to disable it
It is generally not a good idea to build the debug symbols into a static library, so I normally debug with the dynamic version, and use the static Qt to generate releases only.
Therefore, my configure looks something like this:
configure -static -prefix C:\Qt\4.8.6_static -no-webkit -release