I've been trying to get a dead simple listing from a university textbook to compile with the newest QT SDK for Windows I downloaded last night. After struggling through the regular nonsense (no make.bat, need to manually add environment variables and so on) I am finally at the point where I can build. But only one of the two libraries seem to work.
The .pro file I use is dead simple:
SUBDIRS += utils \
dataobjects
TEMPLATE = subdirs
In each of these two subfolders I have the source for a library. Running QMAKE generates a makefile and running Make runs through all the preliminaries and then fails on the g++ call:
g++ -enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc --out-implib,libdataobjects.a -shared -mthreads -Wl -Wl,--out-implib,c:\Users\Cobus\workspace\lib\libdataobjects.a -o ..\..\lib\dataobjects.dll object_script.dataobjects.Debug -L"c:\Users\Cobus\Portab~1\Qt\2010.02.1\qt\lib" -LC:\Users\Cobus\workspace\lib -lutils -lQtXmld4 -lQtGuid4 -lQtCored4
c:/users/cobus/portab~1/qt/2010.02.1/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/bin/ld.exe: cannot find -lutils
The problem seems to be right near the end of the command line, where -lutils is added, indicating that there is a library by the name of utils. While I would have expected to see that, you'll notice the library names after --out include lib in the name, so they become libutils and libdataobjects. I have tried to figure out why this is happening, to no avail.
Anyone have an idea what's going on?
You .pro file uses the SUBDIRS template which requires a .pro file matching the directory name for each subdir. You should have a utils\utils.pro and dataobjects\dataobject.pro file as well.
Is c:\Users\Cobus\workspace\lib\libdataobjects.a built correctly? If not, check the sub directory .pro files.
With what you posted, I would not expect anything to compile. You need targets in the sub-directory .pro files to build anything.
Their seems to be another pro file as the generated Makefile is pulling QtXml which it wont do by default.
Please check the subdirs for any .pro or .pri files .. one of them will have answer to your confusion
Related
I am installing GSI V3.5 https://dtcenter.org/com-GSI/users/. I have no experience in gcc so I cannot use a correct terminolgy for this.
After compiling the program I get an error
” ...........
"/raid60/raid2/opt/local/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld:
cannot find Scrt1.o: No such file or directory
/raid60/raid2/opt/local/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld:
cannot find crti.o: No such file or directory
/raid60/raid2/opt/local/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld:
cannot find -lm
/raid60/raid2/opt/local/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld:
cannot find -lgomp "
It seems that there is problem with gcc which cannot find the
directory including Scrt1.0, crti.o and others.I found these files in
this directory
/home/opt/anaconda/x86_64-conda_cos6-linux-gnu/sysroot/usr/lib. Because I do not have adminstration previlage, as suggested, I could
not install packages like libc6-dev. Follwing
https://askubuntu.com/questions/251978/cannot-find-crti-o-no-such-file-or-directory
And
https://askubuntu.com/questions/251978/cannot-find-crti-o-no-such-file-or-directory,
I added the directory above to ~/.cshrc.
setenv LD_LIBRARY_PATH
/home/opt/anaconda/x86_64-conda_cos6-linux-gnu/sysroot/usr/lib
But still gcc does not recognize this path.
I also tried to feed this path into configure using LDFLGAS
> ./configure
> LDFLAGS="-L/home/opt/anaconda/x86_64-conda_cos6-linux-gnu/sysroot/usr/lib"
But no success. At the end I added LDFLAGS into configure
script. But it also did not work. Any help is highly apreaciated.
Of course, the expected answer would be making gcc identify the path
of crti.o and other missing files.
UPDATE:
As Florian Weimer suggested, I made the file crt.specs. I also updated related line in configure. These files are in dropbox link . But I still get the same error.
UPDATE 2.
These are some lines before error occurs:
../write_obsdiags.o ../wrwrfmassa.o ../wrwrfnmma.o
-L/opt/local/wrf_kpp/gsi35/comGSIv3.5_EnKFv1.1/lib -lsp_i4r8 -lsigio_i4r4 -lsfcio_i4r4 -lnemsio -lbacio -lw3nco_i4r8 -lbufr_i4r8 -lw3emc_i4r8 -lcrtm /opt/local/wrf_kpp/WRFV3//external/io_int/libwrfio_int.a
/opt/local/wrf_kpp/WRFV3//external/io_netcdf/libwrfio_nf.a
/opt/local/wrf_kpp/WRFV3//frame/pack_utils.o
/opt/local/wrf_kpp/WRFV3//frame/module_machine.o
/opt/local/wrf_kpp/WRFV3//frame/module_driver_constants.o
-L/home/srvx11/lehre/users/a1276905/.conda/envs/libgsi/lib -lnetcdff -lnetcdf -L/home/srvx11/lehre/users/a1276905/.conda/envs/libgsi/lib -L/home/srvx11/lehre/users/a1276905/.conda/envs/libgsi/lib -llapack -lblas -fopenmp /raid60/raid2/opt/local/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld:
cannot find Scrt1.o: No such file or directory
Update 3
I have used option -B to add directory including crti.o to the search path of gcc.
when I invoke
gcc -print-search-dirs
I see my desired path "/home/opt/anaconda/x86_64-conda_cos6-linux-gnu/sysroot/usr/lib" among known paths
libraries:
=/home/opt/anaconda/x86_64-conda_cos6-linux-gnu/sysroot/usr/lib/x86_64-unknown-linux-gnu/5.3.0/:/home/opt/anaconda/x86_64-conda_cos6-linux-gnu/sysroot/usr/lib/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../x86_64-unknown-linux-gnu/lib/x86_64-unknown-linux-gnu/5.3.0/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../x86_64-unknown-linux-gnu/lib/../lib64/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../x86_64-unknown-linux-gnu/5.3.0/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../lib64/:/lib/x86_64-unknown-linux-gnu/5.3.0/:/lib/../lib64/:/usr/lib/x86_64-unknown-linux-gnu/5.3.0/:/usr/lib/../lib64/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../x86_64-unknown-linux-gnu/lib/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../:/lib/:/usr/lib/
But I am not through.
The linker search path is only used for libraries. It is not used to locate any object files, including the startup object files.
If the toolchain was built with sysroot support, you can use --sysroot to change where GCC looks for most of its files. This may require adding symbolic links or copying files to create a working sysroot environment and can be somewhat cumbersome.
If you want to change just the location of the startup files, you can do so with a custom GCC specs file. What you need to use is unfortunately somewhat dependent on the GCC version and how GCC was built. This means that as a starting point, you need to use the specs built into GCC, which you can obtain using this command:
gcc -dumpspecs
There are two sections in this file, *startfile: and *endfile:, that are of interest. Copy those two lines and the line following each into a new file, say crt.specs. Edit them and replace Scrt1.o, crt1.o, crti.o (in *startfiles:) and crtn.o (in *endfiles:) with the absolute path to the files you want to use (presumable files you have extracted from libc6-dev using dpkg -x).
Then you can use the new specs by invoking GCC using:
gcc --specs=crt.specs
It will definitely save you a lot of trouble if you can get the system administrator to install the libc6-dev package. It is the only safe way to ensure that these files are kept up-to-date along with the libc6 package.
I am new to NaCl. I was trying to build and run the sample code as per the instrction provided https://developer.chrome.com/native-client/devguide/tutorial/tutorial-part1
I was able run the original code.
Now in this example I created one .cc and .h file and called one of the function in new .cc file from the hello_tutorial.cc(this file already exists). But I am not sure how do I add this new file in the Makefile, so that compiler would include these file as well when I run the make command.
Can anybody help what I am missing here ?
The Makefile for part1 of the tutorial is hand rolled so you need to add a couple of new lines for each source file:
[new_file].bc: [new_file].cc
$(PNACL_CXX) -o $# $< -O2 $(CXXFLAGS) $(LDFLAGS)
And then add .bc to the dependencies of the pexe:
hello_tutorial.pexe: hello_tutorial.bc [new_file.bc]
If you switch to part2 of the tuturial it uses the NaCl SDK build system which makes things a little easier and you just need to add your source to the "SOURCES =" line in the Makefile.
I compiled a library using the MinGW toolchain provided with Qt 5.0.2 on Windows. As a result I received a library.so file. First I failed using the library in a Qt application, but now I found out that everything works fine when I make a copy of the liblibrary.so file and call it liblibrary.dll or liblibrary.lib (which is the only file ending supported by the add library wizard in QtCreator).
Now I wonder if this is normal or if I should change something in order not to have both files (which are exact copies). Leaving one away makes the application crash during start up. I added the library as follows to my Qt pro file:
LIBS += -L"../path/to/library" -llibrary
INCLUDEPATH += $$quote(../path/to/library)
EDIT: I compiled the library using the MinGW of Qt, not as Qt project but using mingw32-make and the provided Makefile. As a result I get the liblibrary.so.
EDIT: It seems to work also when renaming the copy to liblibrary.dll instead of .lib. But still, I need two files to make the application work -- the .so and the .dll.
Chris
That's weird, I think you should get a *.a and *.dll files when building a shared lib with MinGW on Windows, as said in the documentation:
In windows, MinGW will output .a and .dll, MSVC2010 will ouput .lib and .dll. In linux, MinGW will output .so, .so.1, .so.1.0 and .so.1.0.0 – .lib, .a and .so are import libraries.
You definitely shouldn't rename your file!
Be careful to:
not to include the "lib" prefix after "-l" in your project file.
put everything after after "-l" in lower case as you're on Windows
not adding any extension to your library name after "-l"
add and reference the .h file used in your library
A real example using QtWebsocket lib:
INCLUDEPATH += "$${PWD}/include/"
LIBS += -L"$${PWD}/libs/" -lqtwebsocket
...
HEADERS += ... \
$${PWD}/include/QWsSocket.h \
...
In my include/ folder, I have the following file:
QWsSocket.h (taken from original project - required)
In my libs/ folder, I have the following file:
libQtWebsocket.a
QtWebsocket.dll
Edit: I struggled with this too initially. Have you tried to build your lib as a static lib instead (CONFIG += staticlib in your library project)? This might help you getting you *.pro file right before switching to using the shared library.
Edit 2: Ok, the fact that you get a *.so file is still a bit odd. In this question
the user has the same issue as you and keep both files, which is just a workaround. According to a later answer it seems that you need to modify your makefile to generate a file with the proper extension. Maybe this will help: http://www.mingw.org/wiki/sampleDLL
I have the following project structure:
/
general.pro
a/
a.pro
some files
b/
b.pro
some files
c/
Makefile
some files
general.pro is a TEMPLATE=subdirs style qmake-project. The two other project files are normal/common qmake project files (folder a and b). The third folder (folder c) contains a kernel module with the following Makefile: http://pastebin.com/Bv39D6KK
I'm wondering if that Makefile can be translated somehow to a qmake project file.
If not, is there a way to the the general.pro project file that there is a "c" folder containing a Makefile which should be ran too?
Regards
I really doubt, you can include Makefile in a .pro file.
Here is my thoughts about what you can do:
If c is your project, you could simply create one more .pro file for it.
If it is not, and you don't need to edit it, you could build it without including into subdirs (if it's a library, you are using in a or b, you still can build it, and then create a .pri file and add includes and libs etc).
If you need it for a build machine or for deploying, you could use build script.
You could use cmake.
Update:
It turns out, there is a solution.
Though, I could not make it work myself, I hope it helps. What you need is to add following lines to a top-level pro file:
mytarget.commands = make -C c
QMAKE_EXTRA_TARGETS += mytarget
PRE_TARGETDEPS += mytarget
Where c is a name of sub-directory, containing Makefile.
I'm currently transferring a project built with qmake to CMake.
In the version with qmake, in the .pri file, there was
MOC_DIR = .moc/$${PLATFORM_NAME}
that permitted to produce the MOC temporary files in a given directory, keeping the sources clean. How to do the same thing with CMake?
Note: with CMake, I use the FindQt4.cmake package and the command QT4_WRAP_CPP().
As baysmith says, if your goal is to keep your source directory clean, the real solution is to use CMake's "out-of-source" builds feature. If you're on Windows, set "Where to build the binaries" to a new directory, different from the "Where is the source code" directory. If you're on Unix, it goes something like this:
cd <source directory>
mkdir build
cd build
cmake ..
make
By running CMake on a different directory, all of the build files will go into that directory, and your sources will stay clean. (Note: the build directory doesn't have to be inside the source directory. See the CMake wiki for more details.)
If "out-of-source" doesn't work for you, I was able to find one other option. Based on what I can tell from the Qt4Macros.cmake file installed with my CMake 2.8, it isn't accessible as a config parameter. Here's the relevant line:
SET(_moc ${CMAKE_CURRENT_BINARY_DIR}/${_current_MOC})
The workaround is to change all of your MOC include directives to specify the subfolder you'd like to build to.
#include "moc/mainwindow.moc"
After creating the moc directory inside my build directory, there were no problems building, and my MOC file was in the new directory.