I've got a c++-project which uses Clang API, and I'd like to have ability to debug into clang/llvm function when I debugging my project.
I built llvm+clang v3.7.0 using CMake with the following opts:
-DCMAKE_INSTALL_PREFIX=$HOME/opt/llvm -DCMAKE_BUILD_TYPE=Debug
but GDB doesn't step into clang API's functions.
What am I doing wrong?
It's likely what you're doing is not setting a breakpoint on the command line with -cc1 on it. clang forks immediately for error handling purposes, so if you set a breakpoint on main you'll see it happen. If you want to debug starting at clang then you should:
Build with debug symbols (looks like you're doing that)
Run clang with -v to get the various command lines, e.g.
dzur:~/tmp> ~/builds/build-llvm/bin/clang -v t.c -S
"/usr/local/google/home/echristo/builds/build-llvm/bin/clang-3.9" -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name t.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim
-fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -v -dwarf-column-info -debugger-tuning=gdb -coverage-file /usr/local/google/home/echristo/tmp/t.c -resource-dir /usr/local/google/home/echristo/builds/build-llvm/bin/../lib/clang/3.9.0 -internal-isystem /usr/local/include -internal-isystem /usr/local/google/home/echristo/builds/build-llvm/bin/../lib/clang/3.9.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdebug-compilation-dir /usr/local/google/home/echristo/tmp -ferror-limit 19 -fmessage-length 120 -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics
-o t.s -x c t.c
Set a breakpoint on the this command line where you'd like in the sources.
Related
I am about 3 hours new to Linux/Cygwin/virtually anything even borderline computer science. I have been tasked with installing a program for rotors/propellers for research (XROTOR), but I cannot figure out how to run the program. It seems to have been developed in Fortran (maybe?), and came with a README. The README is asking me to build the file, but I have no clue what that means. I have downloaded Cygwin, and have gotten as far as the "make libPLT.a" line. I then cd'ed to the bin folder, and typed in "make xrotor" like the README states, but I keep getting the following error:
$ make
ifort -c -I../src -O -static ../src/xrotor.f
sh: ifort: command not found
make: *** [Makefile:147: xrotor.o] Error 127
I've included the README as well. I don't know what I'm doing, and I figured this was a decent place to start. Any help is GREATLY appreciated!!!
EDIT: Left the README out for whatever reason, sorry. I've written it out here:
General
XROTOR and its plot library should compile on any Unix system
with normal Fortran-77, C, and X-Windows support. So far,
XROTOR has been tested on the following systems:
DEC-5000
Alpha
SGI
* Sun
* RS/6000
* HP-9000
* Pentium/Linux
The systems marked with "*" have peculiar features which require slight
modifications to the Makefiles in the plotlib/ and bin/ directories.
Examine these Makefiles before building the plot library and Xrotor.
Build Sequence
To install, first build the plot library in ./plotlib ...
% cd plotlib
% make libPlt.a
Then build the programs in ./bin ...
% make xrotor
% make jplot
The README is missing some details, but you need to compile the program from sources,
and to do so you need to adjust some variables in the Makefile's
As prerequisite for compiling you need gcc-fortran,make and library libX11-devel
plus the X11 system for the graphic. Installing xinit is a good start.
$ tar -xf Xrotor7.55.tar.tgz
$ cd Xrotor
$ cd plotlib
than modify config.make to set PLTLIB = libPlt.a
I used my preferred editor, but other are also ok
$ vim config.make
To build:
$ make libPlt.a
gfortran -c -O2 -fdefault-real-8 plt_base.f
gfortran -c -O2 -fdefault-real-8 plt_font.f
gfortran -c -O2 -fdefault-real-8 plt_util.f
gfortran -c -O2 -fdefault-real-8 plt_color.f
gfortran -c -O2 -fdefault-real-8 set_subs.f
gfortran -c -O2 -fdefault-real-8 gw_subs.f
gfortran -c -O2 -fdefault-real-8 ps_subs.f
gcc -c -O2 -DUNDERSCORE Xwin.c
gfortran -c -O2 -fdefault-real-8 plt_old.f
gfortran -c -O2 -fdefault-real-8 plt_3D.f
ar r libPlt.a plt_base.o plt_font.o plt_util.o plt_color.o set_subs.o gw_subs.o ps_subs.o Xwin.o plt_old.o plt_3D.o
ar: creating libPlt.a
ranlib libPlt.a
Than moving to program build directory
$ cd ../bin
again modify Makefile.gfortran to set PLTOBJ = ../plotlib/libPlt.a and LIBS = -L/usr/lib -lX11
$ vim Makefile.gfortran
and build all program in one shot
$ make -f Makefile.gfortran
gfortran -c -I../src -O ../src/xrotor.f
gfortran -c -I../src -O ../src/xoper.f
gfortran -c -I../src -O ../src/xdesi.f
gfortran -c -I../src -O ../src/xmodi.f
...
gfortran -c -I../src -O ../src/plotdata.f
gfortran -o xrotor xrotor.o xoper.o xdesi.o xmodi.o xaero.o xjmap.o xio.o xnoise.o xrotpl.o xcasepl.o xbend.o xinte.o xutils.o jputil.o plutil.o modify.o srclin.o spline.o userio.o vortex.o plotdata.o ../plotlib/libPlt.a -L/usr/lib -lX11
gfortran -c -I../src -O ../src/jplot.f
../src/jplot.f:107:72:
PAUSE 'Hit return to see J values'
1
Warning: Deleted feature: PAUSE statement at (1)
../src/jplot.f:112:72:
PAUSE 'Hit return to see CP values'
1
Warning: Deleted feature: PAUSE statement at (1)
gfortran -o jplot jplot.o xutils.o jputil.o userio.o ../plotlib/libPlt.a -L/usr/lib -lX11
gfortran -c -I../src -O ../src/jplote.f
gfortran -o jplote jplote.o xutils.o jputil.o userio.o ../plotlib/libPlt.a -L/usr/lib -lX11
The Warning means that the PAUSE command does not exist anymore so the progran will
likely not pause on the expected locations.
This could explain why it is not working as expected, but probably as the code is very old some code assumptions about the Unix system are not anymore valid.
Running it after starting the Xwindow graphic system from inside a Xterm
$ ./xrotor
=========================
XROTOR Version 7.55
=========================
Note: The following floating-point exceptions are signalling: IEEE_DENORMAL
STOP COLORSPECTRUM: Non-monotonic color axis. Check COLWIDTH.
Need to edit the COLORSPECTRUMTRP subroutine xrotor/plotlib/plt_color.f. Add the following after line 508
COLWIDTH=(/1.0,1.20000005,0.5,1.4,1.0,1.20000005,1.5/)
In a nutshell, I can build the program with a direct g++ command line. It builds then executes successfully on the target.
If, however, I use the simplest cmake script I can think of, the build succeeds, but the program fails to execute on the target. The failed output of the executable is:
terminate called after throwing an instance of 'std::system_error'
what(): Enable multithreading to use std::thread: Operation not permitted
Aborted
The g++ command line I use for a successful build and execution is:
/opt/criticallink/mityomapl138_20151114/sysroots/i686-clsdk-linux/usr/bin/arm-criticallink-linux-gnueabi/arm-criticallink-linux-gnueabi-g++ -o ThreadTest -std=c++11 -pthread main.cpp ThreadTest.cpp
When I run the straight g++ program on the target, I get:
Atomic Success Count: 1000 of 1000.
Mutex Success Count: 1000 of 1000.
Unclean Success Count: 922 of 1000.
Unclean Failure Count: 78 of 1000.
The CMakeLists.txt file I use is:
# cmake file for building the ThreadTest executable. This requires c++11.
CMAKE_MINIMUM_REQUIRED(VERSION 2.8.12)
# !!! Set up the compiler to use, first (i.e. before the PROJECT() call.)
# gcc location.
SET(CROSS_COMPILE_FULL
"/opt/criticallink/mityomapl138_20151114/sysroots/i686-clsdk-linux/usr/bin/arm-criticallink-linux-gnueabi/arm-criticallink-linux-gnueabi-")
# sysroot location
SET(CROSS_COMPILE_FULL_HOST
"/opt/criticallink/mityomapl138_20151114/sysroots/arm926ejste-criticallink-linux-gnueabi")
SET(CMAKE_C_COMPILER "${CROSS_COMPILE_FULL}gcc")
SET(CMAKE_CXX_COMPILER "${CROSS_COMPILE_FULL}g++")
SET(CMAKE_FIND_ROOT_PATH "${CROSS_COMPILE_FULL_HOST}")
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
# The project will use the compiler specified above (or the default compiler for Windows.)
PROJECT(CommonSDK)
SET(MY_TEST_HOME "$ENV{TEST_HOME}")
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -pthread")
SET(CUR_PROJECT_NAME ThreadTest)
SET(PROJECT_HOME_DIR "${MY_TEST_HOME}/${CUR_PROJECT_NAME}")
SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY "$ENV{TEST_EXEC_HOME}")
FILE(GLOB CUR_PROJECT_FILES "${PROJECT_HOME_DIR}/*.cpp" "${PROJECT_HOME_DIR}/*.h")
FIND_PACKAGE(Threads REQUIRED)
ADD_EXECUTABLE(${CUR_PROJECT_NAME} ${CUR_PROJECT_FILES})
TARGET_LINK_LIBRARIES(${CUR_PROJECT_NAME} ${CMAKE_THREAD_LIBS_INIT})
I invoke cmake with:
mkdir build
cd build
cmake ..
And the cmake output is:
-- The C compiler identification is GNU 4.8.3
-- The CXX compiler identification is GNU 4.8.3
-- Check for working C compiler: /opt/criticallink/mityomapl138_20151114/sysroots/i686-clsdk-linux/usr/bin/arm-criticallink-linux-gnueabi/arm-criticallink-linux-gnueabi-gcc
-- Check for working C compiler: /opt/criticallink/mityomapl138_20151114/sysroots/i686-clsdk-linux/usr/bin/arm-criticallink-linux-gnueabi/arm-criticallink-linux-gnueabi-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /opt/criticallink/mityomapl138_20151114/sysroots/i686-clsdk-linux/usr/bin/arm-criticallink-linux-gnueabi/arm-criticallink-linux-gnueabi-g++
-- Check for working CXX compiler: /opt/criticallink/mityomapl138_20151114/sysroots/i686-clsdk-linux/usr/bin/arm-criticallink-linux-gnueabi/arm-criticallink-linux-gnueabi-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Configuring done
-- Generating done
-- Build files have been written to: /home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/build
Here is the VERBOSE output from the make:
make VERBOSE=1
/usr/bin/cmake -H/home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest -B/home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/build --check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start /home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/build/CMakeFiles /home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/build/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory `/home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/build'
make -f CMakeFiles/ThreadTest.dir/build.make CMakeFiles/ThreadTest.dir/depend
make[2]: Entering directory `/home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/build'
cd /home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/build && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest /home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest /home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/build /home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/build /home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/build/CMakeFiles/ThreadTest.dir/DependInfo.cmake --color=
Dependee "/home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/build/CMakeFiles/ThreadTest.dir/DependInfo.cmake" is newer than depender "/home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/build/CMakeFiles/ThreadTest.dir/depend.internal".
Dependee "/home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/build/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "/home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/build/CMakeFiles/ThreadTest.dir/depend.internal".
Scanning dependencies of target ThreadTest
make[2]: Leaving directory `/home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/build'
make -f CMakeFiles/ThreadTest.dir/build.make CMakeFiles/ThreadTest.dir/build
make[2]: Entering directory `/home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/build'
/usr/bin/cmake -E cmake_progress_report /home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/build/CMakeFiles 1
[ 50%] Building CXX object CMakeFiles/ThreadTest.dir/main.cpp.o
/opt/criticallink/mityomapl138_20151114/sysroots/i686-clsdk-linux/usr/bin/arm-criticallink-linux-gnueabi/arm-criticallink-linux-gnueabi-g++ -O2 -pipe -g -feliminate-unused-debug-types -std=c++11 -pthread -o CMakeFiles/ThreadTest.dir/main.cpp.o -c /home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/main.cpp
/usr/bin/cmake -E cmake_progress_report /home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/build/CMakeFiles 2
[100%] Building CXX object CMakeFiles/ThreadTest.dir/ThreadTest.cpp.o
/opt/criticallink/mityomapl138_20151114/sysroots/i686-clsdk-linux/usr/bin/arm-criticallink-linux-gnueabi/arm-criticallink-linux-gnueabi-g++ -O2 -pipe -g -feliminate-unused-debug-types -std=c++11 -pthread -o CMakeFiles/ThreadTest.dir/ThreadTest.cpp.o -c /home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/ThreadTest.cpp
Linking CXX executable /home/mitydsp/Code/CommonSDK/OutputTest/DbricHost/ThreadTest
/usr/bin/cmake -E cmake_link_script CMakeFiles/ThreadTest.dir/link.txt --verbose=1
/opt/criticallink/mityomapl138_20151114/sysroots/i686-clsdk-linux/usr/bin/arm-criticallink-linux-gnueabi/arm-criticallink-linux-gnueabi-g++ -O2 -pipe -g -feliminate-unused-debug-types -std=c++11 -pthread -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed CMakeFiles/ThreadTest.dir/main.cpp.o CMakeFiles/ThreadTest.dir/ThreadTest.cpp.o -o /home/mitydsp/Code/CommonSDK/OutputTest/DbricHost/ThreadTest -rdynamic -lpthread
make[2]: Leaving directory `/home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/build'
/usr/bin/cmake -E cmake_progress_report /home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/build/CMakeFiles 1 2
[100%] Built target ThreadTest
make[1]: Leaving directory `/home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/build'
/usr/bin/cmake -E cmake_progress_start /home/mitydsp/Code/CommonSDK/source/Tests/ThreadTest/build/CMakeFiles 0
I've exhaustively looked in StackOverflow, Google, etc. -- and the suggestions I've come across are incorporated in the CMakeLists.txt, above. But I still can't get the cmake executable to run properly on the target.
Any help would be appreciated!
I was able to resolve this problem by adding the -Wl,--no-as-needed linker option. In the CMakeLists.txt file, it's done like this:
SET(CMAKE_EXE_LINKER_FLAGS "-Wl,--no-as-needed ${THREADTEST_COMPILE_FLAG}")
Apparently the default for the gcc linker is --as-needed -- where the linker chooses not to link a library it thinks is not needed. The interesting thing is that the straight g++ command line build correctly decides that libpthread is needed. In the cmake case, g++ apparently decides that libpthread is not needed. You'll see in the make output, above, that cmake gloms together a lot of g++ command line options with duplicates and other messiness. I suspect that is probably the root issue.
Nevertheless, here is the CMakeLists.txt file that works. Notice that for my case at least, the call to FIND_PACKAGE(Threads REQUIRED) was not required at all.
# cmake file for building the ThreadTest executable. This requires c++11.
CMAKE_MINIMUM_REQUIRED(VERSION 2.8.12)
# !!! Set up the compiler to use, first (i.e. before the PROJECT() call.)
# gcc location.
SET(CROSS_COMPILE_FULL
"/opt/criticallink/mityomapl138_20151114/sysroots/i686-clsdk-linux/usr/bin/arm-criticallink-linux-gnueabi/arm-criticallink-linux-gnueabi-")
# sysroot location
SET(CROSS_COMPILE_FULL_HOST
"/opt/criticallink/mityomapl138_20151114/sysroots/arm926ejste-criticallink-linux-gnueabi")
SET(CMAKE_C_COMPILER "${CROSS_COMPILE_FULL}gcc")
SET(CMAKE_CXX_COMPILER "${CROSS_COMPILE_FULL}g++")
SET(CMAKE_FIND_ROOT_PATH "${CROSS_COMPILE_FULL_HOST}")
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
# The project will use the compiler specified above (or the default compiler for Windows.)
PROJECT(CommonSDK)
SET(MY_TEST_HOME "$ENV{TEST_HOME}")
SET(THREADTEST_COMPILE_FLAG "-std=c++11 -pthread")
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${THREADTEST_COMPILE_FLAG}")
SET(CMAKE_EXE_LINKER_FLAGS "-Wl,--no-as-needed ${THREADTEST_COMPILE_FLAG}")
SET(CUR_PROJECT_NAME ThreadTest)
SET(PROJECT_HOME_DIR "${MY_TEST_HOME}/${CUR_PROJECT_NAME}")
SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY "$ENV{TEST_EXEC_HOME}")
FILE(GLOB CUR_PROJECT_FILES "${PROJECT_HOME_DIR}/*.cpp" "${PROJECT_HOME_DIR}/*.h")
ADD_EXECUTABLE(${CUR_PROJECT_NAME} ${CUR_PROJECT_FILES})
TARGET_LINK_LIBRARIES(${CUR_PROJECT_NAME} ${CMAKE_THREAD_LIBS_INIT})
I'm new to linux. Can anyone explain to me the following verbose mode output for my hello world program? Also, what do the files crt1.o, crti.o, crtend.o, crtbegin.o and crtn.o and lc and lgcc do? Any other explanatory links are also welcome.
$ gcc -v hello.c
Reading specs from /usr/lib/gcc-lib/i686/3.3.1/specs
Configured with: ../configure --prefix=/usr
Thread model: posix
gcc version 3.3.1
/usr/lib/gcc-lib/i686/3.3.1/cc1 -quiet -v -D__GNUC__=3
-D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=1
hello.c -quiet -dumpbase hello.c -auxbase hello -Wall
-version -o /tmp/cceCee26.s
GNU C version 3.3.1 (i686-pc-linux-gnu)
compiled by GNU C version 3.3.1 (i686-pc-linux-gnu)
GGC heuristics: --param ggc-min-expand=51
--param ggc-min-heapsize=40036
ignoring nonexistent directory "/usr/i686/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/include
/usr/lib/gcc-lib/i686/3.3.1/include
/usr/include
End of search list.
as -V -Qy -o /tmp/ccQynbTm.o /tmp/cceCee26.s
GNU assembler version 2.12.90.0.1 (i386-linux)
using BFD version 2.12.90.0.1 20020307 Debian/GNU
Linux
/usr/lib/gcc-lib/i686/3.3.1/collect2
--eh-frame-hdr -m elf_i386 -dynamic-linker
/lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o
/usr/lib/gcc-lib/i686/3.3.1/crtbegin.o
-L/usr/lib/gcc-lib/i686/3.3.1
-L/usr/lib/gcc-lib/i686/3.3.1/../../.. /tmp/ccQynbTm.o
-lgcc -lgcc_eh -lc -lgcc -lgcc_eh
/usr/lib/gcc-lib/i686/3.3.1/crtend.o
/usr/lib/crtn.o
The first part is the version and configuration data for the compiler driver (that's the gcc binary, which is not actually the compiler itself):
Reading specs from /usr/lib/gcc-lib/i686/3.3.1/specs
Configured with: ../configure --prefix=/usr
Thread model: posix
gcc version 3.3.1
Then it prints the command it uses to call the real compiler, cc1:
/usr/lib/gcc-lib/i686/3.3.1/cc1 -quiet -v -D__GNUC__=3
-D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=1
hello.c -quiet -dumpbase hello.c -auxbase hello -Wall
-version -o /tmp/cceCee26.s
And cc1 prints it's version and config info.
GNU C version 3.3.1 (i686-pc-linux-gnu)
compiled by GNU C version 3.3.1 (i686-pc-linux-gnu)
GGC heuristics: --param ggc-min-expand=51
--param ggc-min-heapsize=40036
Then cc1 tells you what directories it will search for include files.
ignoring nonexistent directory "/usr/i686/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/include
/usr/lib/gcc-lib/i686/3.3.1/include
/usr/include
End of search list.
The compiler is now complete, so gcc tells you the assembler command it will use.
as -V -Qy -o /tmp/ccQynbTm.o /tmp/cceCee26.s
And the assembler, as, gives its version info.
GNU assembler version 2.12.90.0.1 (i386-linux)
using BFD version 2.12.90.0.1 20020307 Debian/GNU
Linux
The assembler is now done so gcc gives the linker command. It's using collect2 as an intermediary to the real linker ld, but that's not important here.
/usr/lib/gcc-lib/i686/3.3.1/collect2
--eh-frame-hdr -m elf_i386 -dynamic-linker
/lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o
/usr/lib/gcc-lib/i686/3.3.1/crtbegin.o
-L/usr/lib/gcc-lib/i686/3.3.1
-L/usr/lib/gcc-lib/i686/3.3.1/../../.. /tmp/ccQynbTm.o
-lgcc -lgcc_eh -lc -lgcc -lgcc_eh
/usr/lib/gcc-lib/i686/3.3.1/crtend.o
/usr/lib/crtn.o
The linker gives no verbose output (try -Wl,-v), so that's it.
The "crt" files mean "C RunTime". They are small sections of code inserted at the start of your program, and at the end. They take care of initialising your global variables, heap, and stack. They call atexit functions after you return from main. And some more besides.
Hope that helps.
Can anyone tell me where to find the following files in Cygwin setup.exe?
sys/socket.h
netinet/in_systm.h
netinet/in.h
netinet/ip.h
arpa/inet.h
netdb.h
here is what -v is printing out
$ make
gcc -g -c -v it.c
Using built-in specs.
Target: i686-w64-mingw32
Configured with: ../gcc44-svn/configure --target=i686-w64-mingw32 --host=i686-w6
4-mingw32 --disable-multilib --disable-nls --disable-win32-registry --prefix=/mi
ngw32 --with-gmp=/mingw32 --with-mpfr=/mingw32 --enable-languages=c,c++
Thread model: win32
gcc version 4.4.3 (GCC)
COLLECT_GCC_OPTIONS='-g' '-c' '-v' '-mtune=generic'
c:/strawberry/c/bin/../libexec/gcc/i686-w64-mingw32/4.4.3/cc1.exe -quiet -v -ip
refix c:\strawberry\c\bin\../lib/gcc/i686-w64-mingw32/4.4.3/ it.c -quiet -dumpba
se it.c -mtune=generic -auxbase it -g -version -o C:\Users\AppData\Local\
Temp\ccuWjX0W.s
ignoring nonexistent directory "/mingw32/include"
ignoring duplicate directory "c:/strawberry/c/lib/gcc/../../include"
ignoring duplicate directory "c:/strawberry/c/lib/gcc/../../lib/gcc/i686-w64-min
gw32/4.4.3/include"
ignoring duplicate directory "c:/strawberry/c/lib/gcc/../../lib/gcc/i686-w64-min
gw32/4.4.3/include-fixed"
ignoring duplicate directory "c:/strawberry/c/lib/gcc/../../lib/gcc/i686-w64-min
gw32/4.4.3/../../../../i686-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
c:\strawberry\c\bin\../lib/gcc/i686-w64-mingw32/4.4.3/../../../../include
c:\strawberry\c\bin\../lib/gcc/i686-w64-mingw32/4.4.3/include
c:\strawberry\c\bin\../lib/gcc/i686-w64-mingw32/4.4.3/include-fixed
c:\strawberry\c\bin\../lib/gcc/i686-w64-mingw32/4.4.3/../../../../i686-w64-ming
w32/include
/mingw/include
End of search list.
GNU C (GCC) version 4.4.3 (i686-w64-mingw32)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p
3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 4728d1fc720cf46696475c98813fbdef
i think it is looking in strawberry for the files.
NOTE: netinet/in_system.h is actually spelled netinet/in_systm.h; I've edited your question to correct it.
These should all be part of the cygwin package. You can't have a working Cygwin installation without that package.
They're all under /usr/include.
$ cygcheck -c cygwin
Cygwin Package Information
Package Version Status
cygwin 1.7.16-1 OK
$ cygcheck -l cygwin | wc -l
280
$ cygcheck -l cygwin | egrep 'sys/socket.h|netinet/in_systm.h|netinet/in.h|netinet/ip.h|arpa/inet.h|netdb.h'
/usr/include/netdb.h
/usr/include/netinet/in.h
/usr/include/netinet/in_systm.h
/usr/include/netinet/ip.h
/usr/include/arpa/inet.h
/usr/include/sys/socket.h
$
If those files are missing, you might try reinstalling the cygwin package -- but first make sure you're looking for them in the right place, under /usr/include.
At my company we have a really annoying problem with our linker (ld 2.17). It links very very slow on a relatively fast system (Core Duo, 2GB Ram) and I don't really now how to fix this. It takes about five to ten minutes to compile a relatively big project (which takes about 5 seconds to link on my Gentoo system).
Personally i think it is a huge productivity killer, at least for me. We tried to use a more recent version of ld (2.19) but without any success. I asked in #debian on #freenode, but this problem seems to be very unique. I did not find any information about similar problems on the net. It only happens when we build with debug symbols. I changed the gcc debug-information flags to -g, -g3, and -ggdb, but that did not help either.
So my question is, how do you profile and debug a linker? I have never done anything like it, and I am unable to find any documentation about it. Basically any reasonable gprof gmon.out would be very helpful, as I could ask the binutils developers about a concrete problem. I am just completely oblivious about this.
Edit: We 'fixed' our problem switching to debian lenny on most systems. Thanks for the answers!
You can try gold (binutils-gold) instead of ld.
It is supposed to be faster.
Here is a quote from Wikipedia Gold(linker)
The motivation for writing gold was to
make a linker that is faster than the
GNU linker[3], especially for large
applications coded in C++.
The author of gold (Ian Lance Taylor) has published an (longish) article about linkers where he explains his motifs in writing gold and why most linkers are slow. If you are interested in the inner workings of linkers this article is worth reading.
If you're observing the slowdown running gcc (as opposed to directly running the linker as ld), try compiling with
$ gcc -save-temps -v [... rest of your command line ...]
This will print out all the intermediary commands, such as the internal collect2 and final ld, as well as ensure that the objects passed to those commands will remain on disk even after the command has completed.
Then you should be able to run the commands individually to find the worst stage, and then run it with different options or profiling.
For example,
$ echo 'int main() {}' > test.c
$ gcc -save-temps -v test.c
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/paludis/sys-devel-gcc-4.3.3-r2/work/gcc-4.3.3/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.3 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.3/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --disable-libgcj --enable-objc-gc --enable-languages=c,c++,objc,obj-c++,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.3-r2 p1.1, pie-10.1.5'
Thread model: posix
gcc version 4.3.3 (Gentoo 4.3.3-r2 p1.1, pie-10.1.5)
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-mtune=generic'
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.3/cc1 -E -quiet -v test.c -D_FORTIFY_SOURCE=2 -mtune=generic -fpch-preprocess -o test.i
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-mtune=generic'
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.3/cc1 -fpreprocessed test.i -quiet -dumpbase test.c -mtune=generic -auxbase test -version -o test.s
GNU C (Gentoo 4.3.3-r2 p1.1, pie-10.1.5) version 4.3.3 (x86_64-pc-linux-gnu)
compiled by GNU C version 4.3.3, GMP version 4.2.4, MPFR version 2.4.1-p5.
warning: GMP header version 4.2.4 differs from library version 4.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 20f3dbffbfd03e5311a257ae1239cd71
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-mtune=generic'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../x86_64-pc-linux-gnu/bin/as -V -Qy -o test.o test.s
GNU assembler version 2.19.1 (x86_64-pc-linux-gnu) using BFD version (GNU Binutils) 2.19.1
COMPILER_PATH=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.3/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.3/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.3/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../x86_64-pc-linux-gnu/bin/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-mtune=generic'
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.3/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/crtbegin.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../.. test.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/crtend.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64/crtn.o
$ ls
a.out test.c test.i test.o test.s
$ /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.3/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/crtbegin.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../.. test.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/crtend.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64/crtn.o
$ .../collect2 -v ...
collect2 version 4.3.3 (x86-64 Linux/ELF)
/usr/bin/ld -v --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/crtbegin.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../.. test.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/crtend.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../lib64/crtn.o
GNU ld (GNU Binutils) 2.19.1
$
If you need help building a debug version of ld, here's a quick recipe to get you going.
$ sudo apt-get install build-essential dpkg-dev
$ sudo apt-get build-dep binutils
$ apt-get source binutils
$ cd binutils-*
$ DEB_BUILD_OPTIONS='debug noopt nostrip' dpkg-buildpackage -uc -us
$ cd ..
$ sudo dpkg -i *.deb
Instead of that quick hack, though, I'd recommend using schroot or sbuild to avoid polluting your own system.
To answer the profiling question; you should look at OProfile - this is a system-level profiler that can profile multiple running processes. It should allow you to identify which sub-process of the link is taking the most time, and furthermore will show which functions the most time is being spent.
I'd like to suggest two ways to check:
use strace to check what files linker is loading/parsing to link; with this you may know is there any unnecessary path is searched by linker.
use ld with -verbose option to know what ld is doing. Five minutes compare to five seconds should not be the linker's problem, it should be some problem of your host machine or some option.