I was wondering whether it's possible to print a custom error message in case someone tries to compile an .iss file with an unsupported Inno Setup version. This would be more helpful than for example having the compiler tell you "the WizardStyle directive isn't known" (or something like that). I've checked the "constants" section of the documentation, but couldn't find the compiler version number there.
Use preprocessor and its Ver predefined variable and #if and #error directives. Actually the documentation of the #error directive shows exactly the code you need:
#if VER < EncodeVer(5,4,2)
#error A more recent version of Inno Setup is required to compile this script (5.4.2 or newer)
#endif
Related
Im having problem when i build a fresh project , nothing was added/ remove; i get an error no such file or directory 'atomic'
So i investigate a bit and i kind of found the culprit on the makefile. on line 43
line 43: LIBS = $(SUBLIBS) /opt/Qt/6.2.3-armv7l/lib/libQt6Quick.so /opt/Qt/6.2.3-armv7l/lib/libQt6OpenGL.so /opt/Qt/6.2.3-armv7l/lib/libQt6Gui.so -lEGL /opt/Qt/6.2.3-armv7l/lib/libQt6QmlModels.so /opt/Qt/6.2.3-armv7l/lib/libQt6Qml.so -pthread /opt/Qt/6.2.3-armv7l/lib/libQt6Network.so /opt/Qt/6.2.3-armv7l/lib/libQt6Core.so -latomic -lpthread -lGLESv2 atomic
removing word "atomic" at the end removes the error but im not sure if this is the right thing to do as it might cause some weird bugs under the hood. Qt says the line causing the error is line 228
line 227: untitled: $(OBJECTS)
line 228: $(LINK) $(LFLAGS) -o $(TARGET) $(OBJECTS) $(OBJCOMP) $(LIBS)
How do i properly solve this issue?
I am using qt 6.2
Since this is a fresh unmodified project the .pro is also at default
QT += quick
CONFIG += c++11
# You can make your code fail to compile if it uses deprecated APIs.
# In order to do so, uncomment the following line.
#DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x060000 # disables all the APIs deprecated before Qt 6.0.0
SOURCES += \
main.cpp
RESOURCES += qml.qrc
# Additional import path used to resolve QML modules in Qt Creator's code model
QML_IMPORT_PATH =
# Additional import path used to resolve QML modules just for Qt Quick Designer
QML_DESIGNER_IMPORT_PATH =
# Default rules for deployment.
qnx: target.path = /tmp/$${TARGET}/bin
else: unix:!android: target.path = /opt/$${TARGET}/bin
!isEmpty(target.path): INSTALLS += target
It seems that you are building Qt6 on a Raspberry PI, which isn't an official supported platform.
Does removing atomic may result in some weird bugs?
No, that shouldn't be the case. A missing needed libraries would result in a link time error, not a runtime error.
Off course, since Raspberry PI isn't a supported platform, weird things may happen because it is not (well) tested on this platform, but this will not be related to removing the atomic library.
It seems to me a bug in the Makefile generation code, as library are normally specified using the -l option (which searches for the lib in the specified library search path), instead of providing the relative path to the library. As pointed out in the comments -latomic is also specified. So, atomic seems to be unneeded.
Why does Qt report the error at line 228?
Because this is the line that generates the full linker statement that is being executed. Line 43 is included by $(LIBS).
Tracking the root cause
Searching for atomic inside your (modified) source code of Qt may point you why this library is added to the LIBS variable. The best solution is to remove it at that place.
Relevant resources
Note that this issue is already discussed here.
I want my Inno Setup script to be build using the command line, and I want to pass in the product version number as a parameter. I am trying to implement it like so:
[setup]
VersionInfoVersion={param:version|0.0.0.0}
However the compiler informs me this is invalid for that directive. I have read this post on how to pass in custom parameters from the command line and assume I should just be able to pass in something like:
compil32 /cc "c:\isetup\samples\my script.iss" /version=1.0.0.0
I have also tried the suggestion from this post and tried doing the following:
#define PathToMyBinary "C:\bin\x64\Release"
#define ApplicationVersion GetFileVersion('#PathToMyBinary\MyBinary.dll')
VersionInfoVersion={#ApplicationVersion}
But it doesn't seem to return anything. Both approaches seem valid to me so I'm hoping someone can explain where I am going wrong.
Assuming you define the version via a pre-processor variable like:
[Setup]
VersionInfoVersion={#ApplicationVersion}
To set the version on a command-line, you have to use the ISCC.exe command-line compiler and its /D switch:
ISCC.exe Example1.iss /DApplicationVersion=1.2.3.4
If you want to provide a default value for the version, so the script can compile even without defining the variable on the command line, use #ifndef at the top of the script:
#ifndef ApplicationVersion
#define ApplicationVersion "1.2.3.4"
#endif
To read the version from a binary, you are correctly using the GetFileVersion pre-processor function.
But your syntax to make up the path is wrong.
A correct syntax is PathToMyBinary + '\MyBinary.dll', like:
#define PathToMyBinary "C:\bin\x64\Release"
#define ApplicationVersion GetFileVersion(PathToMyBinary + '\MyBinary.dll')
See Inno Setup Preprocessor: Expression Syntax.
After looking at many different options I found that this worked for me.
This is the command line to compile the setup file
"C:\Program Files (x86)\Inno Setup 5\iscc.exe" "MySetup.iss" /DVersion=1.2.3.4
In the setup file I added these lines, the first lines are to enable you to still run the script in the editor and ensure you would not get the error: Undeclared identifier: "Version"
#ifndef Version
#define Version = '0.0.0.0';
#endif
[Setup]
VersionInfoVersion={#Version}
In order to get my setup script (iss file) to work, I had to remove the #define ApplicationVersion line from my script. Once I did that, it recognized my /DApplicationVersion=8 input parameter.
"C:\Program Files (x86)\Inno Setup 5\iscc.exe" "install.iss" /DApplicationVersion=8
I am including a procedurally generated file into code used by several libraries, using something like
#include MY_CONFIG_FILE_H
Then I am attempting to set this value in my Application.mk using the following directive
APP_CFLAGS += -DMY_CONFIG_FILE_H=<Config/MyFile.h>
however, this results in ndk-build not finding the path. It fails right away on the first file it tries to compile
"Compile++ thumb : MyLibraryName <= MyFirstFile.cpp
The system cannot find the path specified.
make: *** [obj/local/armeabi-v7a/objs/MyLibraryName/MyFirstFile.o] Error 1
Indeed, the file is not there, but it did manage to create the file path. There must be some strange/inconsistent string manipulation going on.
Any ideas? Work arounds? Is this a known issue in ndk-build.cmd? For the record I'm on Windows x64 and NDK R9.
Also notice that if I only include > and no <, I get a different error
The filename, directory name, or volume label syntax is incorrect.
Changing the line to
APP_CFLAGS += -DMY_CONFIG_FILE_H="<Config/MyFile.h>"
worked. Hope this helps anyone else!
I was trying to compile libSDL-1.2.14 for my mips platform.
But it was not successful.
These were the steps that I tried out :
export PATH=/opt/mips-4.3/bin:$PATH
Went inside the libSDL-1.2.14 source folder.
Gave a "./configure --prefix=/usr/local/SDL_Lib --host=mips-linux-gnu"
Executed the "make" command
This was the error received :
cc1: warning: include location
"/usr/include" is unsafe for
cross-compilation
./src/audio/dma/SDL_dmaaudio.c: In
function 'DMA_WaitAudio':
./src/audio/dma/SDL_dmaaudio.c:167:
error: can't find a register in class
'COP3_REGS' while reloading 'asm'
./src/audio/dma/SDL_dmaaudio.c:167:
error: 'asm' operand has impossible
constraints make: *
[build/SDL_dmaaudio.lo] Error 1
But then i reconfigured the make file by giving the following commands :
make clean
./configure --prefix=/usr/local/SDL_Lib --host=mips-linux-gnu CPPFLAGS=-I/opt/mips-4.3/mips-linux-gnu/libc/usr/include/
make
NOTE : /opt/mips-4.3/mips-linux-gnu/libc/usr/include/ - This is the path where you can locate the select.h file for the mips Platform.
It contains the definitions of the macros FD_ZERO and FD_SET.
Still I am getting the same error.
cc1: warning: include location
"/usr/include" is unsafe for
cross-compilation
./src/audio/dma/SDL_dmaaudio.c: In
function 'DMA_WaitAudio':
./src/audio/dma/SDL_dmaaudio.c:167:
error: can't find a register in class
'COP3_REGS' while reloading 'asm'
./src/audio/dma/SDL_dmaaudio.c:167:
error: 'asm' operand has impossible
constraints make: *
[build/SDL_dmaaudio.lo] Error 1
Please help me with some valuable pointers.
Thanks,
Sen
First, don't set the path to the cross-compiler as the first part of your PATH, set it as last:
export PATH=$PATH:<path to cross-compiler>
It's safer this way. Second, run ./configure --help to get all the options. What that error message would say if it was smarter is the following:
You're trying to cross-compile since you're setting the --host flag
But you're not changing any of the other options for where to find includes and libs for the target environment
I'm going to use /usr/include by default
But that's for the host system which will not work when cross-compiling
Check what other configure options you need to set to tell the configure script where to find the .h files (includes) and the libraries for your target. These usually come with the cross-compiler that you download. Also, you should probably set the CROSS_COMPILE environment variable to the cross-compiler prefix before running configure. The prefix is the part before gcc in a cross-compiler, assuming you're using GCC as your cross-compiler.
VS C++ 2008
I am just working through a DirectX tutorial.
In the source code had this line:
#pragma comment (lib, "d3d9.lib")
When I compiled everything linked ok.
However, I commented out this line and tried to include the header and library myself under properties, like this:
C/C++ - General
Additional include directories: "C:\Program Files\Microsoft DirectX SDK (August 2009)\Include"
Linker - General
Additional library directories: "C:\Program Files\Microsoft DirectX SDK (August 2009)\Lib\x64"
Linker - Input: d3d9.lib
However, I got this linker error:
1>main.obj : error LNK2019: unresolved external symbol _Direct3DCreate9#4 referenced in function _initD3D
However, when I just use the pragma I didn't get any linker errors. Only when I try and include them with the properties as above.
What is the real difference in using pragma and including the header/libraries using the properites?
Many thanks,
at first, #pragma comment(lib) is just linker configuration
at second, the SDK should be in path, so dont set additional library directories (you may override it with wrong version), just add d3d9.lib to linker's input.
As far as I know, there is no difference. pragma lib simply says to the linker to look for a specific library by name.
Also, since the path is not specified in the pragma, the linker relies on the current lib paths for your project. Try not add any path to your linker options (by default DX SDK adds paths to any visual studio installed, directly modifying the global visual studio paths. See Tools/Options/Projects and Solutions/VC++ Directories/Show Directories for Library files)
Some things to check:
you are indeed building for x64
your path is really pointing to the DX SDK (it is installed to Program Files(x86) if you are on x64)
verify if there are not other linker warnings