I am a bit confused by the way qt handles libraries. My plan was to put the external libraries I need into the source directory, so that a do not have to install them into the system. As this doesn't seem to work (see below) I was wondering, if this is generally a bad idea or if there is some trick to it??
So I compiled the libraries and put them into /mysubdir. In the .pro-file I added
LIBS+= -L"mysubdir" -l"mylib"
I got the compiler error [projectname] Error 2 and don't know what it means.
The argument passed to -L must be an absolute path. Please give it a try with a full path, or at least -L./wcslibc. Though I'm not sure whether ./ will be recognized correctly. You can get the current path in qmake like this:
LIBS += -L$${PWD}/wcslibc -lwcs
Related
I am developing a project in QT, when I want to use Windeployqt to wrap my exe.
error:Warning: Unable to read \mkspecs\qconfig.pri comes out
I execute Eindeployqt in "QT5.1.1 for Desktop(Mingw 4.8.3)", I checked the qconfig.pri exsited in
C:\Qt\Qt5.1.1\5.1.1\mingw48_32\mkspecs\qconfig.pri
I have added environment variable, can anyone help on this?
Usually you would do this with environment variable
QMAKESPEC=C:\SOMEPATH\qt\mkspecs\win32-g++
or in your case probably:
QMAKESPEC=C:\Qt\Qt5.1.1\5.1.1\mingw48_32\mkspecs
though normally it should be a folder below mkspecs specifying your platform (win32-g++ in my first example).
The windeploy tool will use the paths provided from qmake.
Assuming that you are in the bin folder of your qt installation.
All "important" paths can be seen with:
qmake -query
In your case you will see that all paths have the wrong location.
You have to add a qt.conf file.
https://doc.qt.io/qt-5/qt-conf.html
with the following content:
[Paths]
Prefix = ..
Now, running qmake -query should return correct paths. Also the windeploy tool should be able to find the correct paths.
I'm new to OCaml, but I'm trying to figure out the equivalent of __filename, __dirname from Node. That is, I need to build a path relative to the file containing the code in question.
For reference, I'm working through Ghuloum's IACC: http://ell.io/tt$ocameel
I'm building my first compiler, and I have an utterly-simplistic ‘runtime’ file (in C — temporarily) adjacent to the compiler's source-code. I need to be able to pass the path to this file, as an argument (or a pre-compiled version, I suppose) to gcc or my linker, to have it linked against my compiler's output when I invoke the linker/assembler tooling.
(This may be a stupid question — I'm at a bit of an unknown-unknown here, “how does a compiler get the runtime to the linker”, or something like that. Any commentary about idiomatic solutions to this is welcome, even if it's not a direct answer to the above question!)
If you're running the source file directly via ocaml myfile.ml, Sys.argv.(0) will give you the path to the source file and you can use Filename.dirname to get the directory from that.
If you first compile the source file into an executable and then run the executable, Sys.argv.(0) will give you the name of the executable. In that scenario it's impossible to get the location of the source code (especially if you consider that the person running the executable might not even have the source code on their system).
If you set up your project structure, so that your sources live in src/, your compiled binary in bin/ and the compiled stdlib in lib/, you could just use Filename.dirname Sys.argv.(0) ^ "../lib" as the library path for gcc. This will work whether you run ocaml src/mycompiler.ml, bin/mycompiler or just mycompiler after installing everything to /usr/ or /usr/local/.
I have a solution with various projects, one of which is the main executable, and the rest are libraries the executable depends on. Each one compiles and links fine. However, trying to start the executable gives weird results. Using ldd, I see that the executable is trying to find libraries like so:
../bin/debug/libBlahBlah.so => not found
However, for each project, I'm declaring "bin/debug" (which is the output directory for these libraries) as a libdirs entry, and linking against the library by adding "BlahBlah" as a link, where "BlahBlah" is the name of the project.
I'm not even sure how to accomplish this without premake. Any help is appreciated.
The original intention was to have the library sit next to the executable then set an RPATH that searched for the library next to executable. With the way it is now, it searches for that absolute path relative to the executable... I cannot figure out how to get it off.
I'm using premake5. I've tried to use the nightly and compiling myself. Upstream is currently not compiling however.
If you are using the latest alpha or source of Premake5, you can use the "RelativeLinks" flag to use -L/-l instead of relative paths to libraries:
project "MyProject"
flags "RelativeLinks"
You will still need to set up the rpath properly though; you can do that with buildoptions() and the appropriate command line flags for your compiler. Maybe (untested):
buildoptions "-Wl,-rpath=."
That should work in Premake 4 as well.
I'm hoping this is an easy question. I have setup an Ogre3D project in QtCreator 2.6.1 using MSVC2010. I have to setup a custom build step and I noticed that the letter 'd' is appended to the name of the compiled .exe (e.g. OrgeProgramd.exe, CoolGamed.exe)
This is not critical, I was just wondering why this happens. Is it normal? The target in the .pro file is correct. I tried building with Release and I get the same thing. Any ideas?
Look through your pro/pri files and find the line, similar to this: TARGET = $$join(TARGET,,,d). If you do - that would be the reason.
After creating qt project in codeblocks and running it I'm getting:
Anyone knows how to resolve it?
Thanks
This looks to me like you're building against one version of Qt and linking against another at runtime. Run the QtSDK Maintenance Tool and remove any versions of Qt Desktop that you don't need. You may then need to repoint Codeblocks at the correct headers.
I'm guessing that if you're running from within Codeblocks, you've had to explicitly specify which dlls to use when you run your newly built app. If so, make sure that those are the correct versions (i.e. replace them with dlls from QT INSTALL DIR\Desktop\4.7.x\mingw\bin [though I'm not on my work PC at the moment, so this path may be slightly wrong. Just make sure you're in the correct 4.7.x folder]).
To be honest though, if you're running from Windows, why not use QtCreator? Aside from slightly lacking in terms of GDB integration, it's pretty good and you'd find problems like this are harder to come across.
This is (esp on Windows) a common problem. When installing the Qt SDK, you'll get at least 2 .dll's with the same name but in different versions. It happens, that you link against the intended (dev-)lib but at runtime the version from the Designer/Creator is used.
The easiest way to avoid this, is to deploy the right version of the dll's together with your binaries (.exe and stuff) in a separate folder. This can be achived by modifying your build script. It depends on your build system which is usually qmake/.pro or cmake/CMakeLists.txt.
As for CMake, given an environment variable MYQTDLLDIR containing the path to the files to be deployed you can use something like that:
configure_file($ENV{MYQTDLLDIR}/QtCore4.dll ${CMAKE_CURRENT_BINARY_DIR} COPYONLY)
configure_file($ENV{MYQTDLLDIR}/QtGui4.dll ${CMAKE_CURRENT_BINARY_DIR} COPYONLY)
documentation stripped from cmake --help-full:
configure_file Copy a file to another location and modify its
contents.
configure_file(
[COPYONLY] [ESCAPE_QUOTES] [#ONLY])
Copies a file to file and substitutes variable
values referenced in the file content. If is a relative
path it is evaluated with respect to the current source directory.
The must be a file, not a directory. If is a
relative path it is evaluated with respect to the current binary
directory. If names an existing directory the input file
is placed in that directory with its original name.
This command replaces any variables in the input file referenced as
${VAR} or #VAR# with their values as determined by CMake. If a
variable is not defined, it will be replaced with nothing. If
COPYONLY is specified, then no variable expansion will take place. If
ESCAPE_QUOTES is specified then any substituted quotes will be C-style
escaped. The file will be configured with the current values of CMake
variables. If #ONLY is specified, only variables of the form #VAR#
will be replaces and ${VAR} will be ignored. This is useful for
configuring scripts that use ${VAR}. Any occurrences of #cmakedefine
VAR will be replaced with either #define VAR or /* #undef VAR */
depending on the setting of VAR in CMake. Any occurrences of
#cmakedefine01 VAR will be replaced with either #define VAR 1 or
#define VAR 0 >depending on whether VAR evaluates to TRUE or FALSE in
CMake
As for qmake you could use INSTALLS (used when make install is called) or execute a "plain command" after linking. Using INSTALLS:
mytarget.path = /output/path
mytarget.files += /path/to/QtCore4.dll
mytarget.files += /path/to/QtGui4.dll
INSTALLS += mytarget
qmake using command execution:
win32 {
EXTRA_BINFILES += \
$${MYQTDLLDIR}/QtCore4.dll \
$${MYQTDLLDIR}/QtGui4.dll
EXTRA_BINFILES_WIN = $${EXTRA_BINFILES}
EXTRA_BINFILES_WIN ~= s,/,\\,g
DESTDIR_WIN = $${DESTDIR}
DESTDIR_WIN ~= s,/,\\,g
for(FILE,EXTRA_BINFILES_WIN){
QMAKE_POST_LINK +=$$quote(cmd /c copy /y $${FILE} $${DESTDIR_WIN}$$escape_expand(\n\t))
}
}