In the log I see a line
/usr/bin/install -c .libs/libgiomm-2.4.so.1.0.25T /mydir/glibmm-2.16.4/glibmm-2.16.4/gio/giomm/TEMP/usr/lib/libgiomm-2.4.so.1.0.25
Thats the only place where I see this T file in the build ouptut.
Who generates this file and why? Why doesn't it install .libs/libgiomm-2.4.so.1.0.25?
Related
Every now and then a new tarball or a new xyHub/Lab-repository needs to be built. They usually come with a Makfile or an Autotools/CMake/XY-Generator provides one on the fly. As the maintainers most likely use another operating system or distribution than the one I am currently running, the assumptions that went into their Makefiles usually do not fit my filesystem hierarchy (lib vs. lib64, bin vs. sbin, /usr/lib vs. /lib and so on). As the final command in the build sequence usually is
sudo make install
it is quite annoying to move thousands of files to the correct place. Or even worse determine which files of my distribution were overwritten. Here GNU Makes dry run mode comes in very handy. Running
sudo make -n install
first, saves me the trouble of cleaning up my file system, by just printing all the commands from all active GNU Make recepies without executing them. In case of a handwritten or Autotools-generated Makfile this works as intended. If the Makefile contains something like:
#PREFIX is environment variable, but if it is not set, then set default value
ifeq ($(PREFIX),)
PREFIX := /usr/local
endif
install: unixlib.a
install -d $(DESTDIR)$(PREFIX)/lib/
install -m 644 unixlib.a $(DESTDIR)$(PREFIX)/lib/
install -d $(DESTDIR)$(PREFIX)/include/
install -m 644 unixlib.h $(DESTDIR)$(PREFIX)/include/
I would see exactly what would happen. Every install/cp/mv-command with the full path information would be printed. If I made a mistake with the install prefix in the configure step I can see it there. If the default in the Makefile is weird because it comes from another OS, I would see it there.
Now in case of a CMake-generated Makefile this is different. Doing
mkdir build && cd build
cmake ..
make
sudo make -n install
only produces output that ends in
...
make -f CMakeFiles/Makefile2 preinstall
/usr/bin/cmake -E cmake_echo_color --switch= --cyan "Install the project..."
/usr/bin/cmake -P cmake_install.cmake
As these commands get not executed, just printed, I do not get all the cp/mv/mkdir/install/etc-commands that I would like to see first, before I let the Makefile touch the file system.
Is there a way to get the list of commands that would be executed from the install target in a CMake-generated Makefile as it is the case with handwritten or Autotools-generated ones?
Is there a way to get the list of commands that would be executed from the install target.
Actually, the core part of installation process is contained in the file cmake_install.cmake (which is created in the build directory). This file is processed as CMake script using cmake -P flow of the cmake executable.
The script cmake_install.cmake performes installation of files with install command. Semantic of the install command, used by the script, differs from the one described in documentation: internally, CMake uses some undocumented features of the command.
But it shouldn't be so hard to understand cmake_install.cmake script in general and deduce paths from it.
I have installed the cds library with command ./build.sh -b 64 -z '-std=c++0x' -l '-L /usr/lib/x86_64-linux-gnu' --with-boost /usr/include/boost --amd64-use-128bit at build folder.
After I tried to compile the example init.cpp of src folder, I typed this in terminal: g++ init.cpp -o init, and terminal showed: fatal error: cds/init.h: No such file or directory.
What should I do for compilation command in this case?
Thanks.
For general troubleshooting in cases like this, i would recommend finding where on the system the file got installed (if your build.sh actually installed the file). You would be able to find the missing header file using
find / -path '*/cds/init.h' 2>/dev/null
Then you need to supply two parameters to g++:
First one gets the compiler to know about the include files from the install directory
-I path_to_folder_one_step_above_cds_folder
Second one gets the linker to know about the librarys location. If the library file is called libcds.so, you can find it by running
find / -name libcds.so 2>/dev/null
So for linking, you supply the flag
-L path_to_folder_one_step_above_libcds.so
In your case you might not need the -L flag, since most of your library supposedly is header only.
UPDATE: the build.sh script is printing out important information at the top, starting with "Building with the following options:". The important bits will be "Compile options:" and "Link options:". Those should be enough to solve your specific option.
UPDATE2: build.sh also exports some flags which might include more options. You can print them out directly after running build.sh by running
echo LDFLAGS=$LDFLAGS
echo CFLAGS=$CFLAGS
echo CXXFLAGS=$CXXFLAGS
you are likely to need to pass all these options to g++ when compiling and linking against that library. LDFLAGS are specific to the linker only. Both the other ones are needed for compiling c++ files.
I'm trying to compile a C file named test.c using docker's gcc container.
I'm using the following command, I have put the test.c in my homein ubuntu.
sudo docker run -v /home/moomal/workspace/FypProject/WebContent/file/:/myapp.c:ro gcc:4.9 sh -c "gcc -o myapp /home/moomal/workspace/FypProject/WebContent/file/myapp.c; ./myapp"
It works cool, but, I want to change the folder from home to a folder inside my eclipse web project folder. I have an editor on a web page and then on compile it creates a test.c file inside a folder. I want to access that file.
I tried adding the path like /home/moomal/workspace/FypProject/WebContent/file but I get the error
gcc: error: /home/moomal/workspace/FypProject/WebContent/file/myapp.c: No such file or directory
gcc: fatal error: no input files
compilation terminated.
sh: 1: ./myapp: not found
You seem to be confused about several things here.
The -v HOST_PATH:CON_PATH argument can be used to mount files inside a container, as you seem to be attempting. The HOST_PATH can be a file or a directory. The CON_PATH determines where that file or directory will be in the container. In your case, I think you want:
-v /home/moomal/workspace/FypProject/WebContent/file/myapp.c:/myapp.c
Not just ...file/:/myapp.c. I'm not sure what you expected your version to do (how can a directory be mapped to a file?).
Also, in the shell command you give the path on the host, but as this is processed in the container, you need the path in the container i.e:
gcc -o myapp /myapp.c
Putting it together, I would expect to see something like:
sudo docker run -v /home/moomal/workspace/FypProject/WebContent/file/myapp.c:/myapp.c:ro gcc:4.9 sh -c "gcc -o myapp /myapp.c; ./myapp"
i am using ubuntu 10.10
i am trying to compile simple helloworld file using
gcc -c option
the output file is created but it does not have execute permission
if i dont use -c option the output file has execute permission ..
Please help
The command gcc -c generates a non-executable object file. If you want the output to be executable, do not use the -c option.
I am not sure what you hoped -c was for, but it is exactly for not generating an executable, and your GCC is working as designed.
From the man gcc:
-c Compile or assemble the source files, but do not link. The linking
stage simply is not done. The ultimate output is in the form of an
object file for each source file.
It is not executable. It needs to undergo linking process to become an execution file.
I like to keep my Makefiles flexible and multifunctional. One of the tasks I usually add to make command is tar, for example the following instruction does the job:
tar:
tar -cvf $(PROGNAME).tar $(SRCS) Makefile
My question is: How can CMake be used to generate personalized commands like tar?
I would like to see some code samples.
For the full functionality it would be useful to create project's components and be able to use them as parameters.
(Exempli gratia: archive only header files or some specific library).
Thanks in advance for your answers!
The literal translation of your tar example would be:
ADD_CUSTOM_TARGET(tar
tar -cvf ${CMAKE_CURRENT_BINARY_DIR}/${PROGNAME}.tar ${SRCS} Makefile
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR})
This adds a new target "tar" that always executes the given command whenever it is requested as a command line target, i.e. whenever you run make tar it will create a new tar file. The WORKING_DIRECTORY argument will ensure that the source files are taken from the source directory, while CMAKE_CURRENT_BINARY_DIR ensures the output goes in the current build directory.
A slightly better iteration would be to replace tar with ${CMAKE_COMMAND} -E tar, as this doesn't depend on the command line tar program being available. So something like this would tar up all the header files when you run make tar:
SET(HEADER_FILES my.h another.h)
SET(PROGNAME myprog)
ADD_CUSTOM_TARGET(tar ${CMAKE_COMMAND} -E tar -czvf
${CMAKE_CURRENT_BINARY_DIR}/${PROGNAME}.tar.gz ${HEADER_FILES}
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR})
An even better iteration would be to use the CPack features to create source or binary tar files, but that's quite a bit more work and may not be what you need anyway.