I had done as the "Documentation/gcov.txt" said.
Basic about mime:
$ uname -a
Linux turf.ivor 3.9.5 #1 SMP Fri Jun 14 00:51:05 CST 2013 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/redhat-release
Fedora release 18 (Spherical Cow)
$ zcat /proc/config.gz | egrep "GCOV_|DEBUG_FS"
CONFIG_GCOV_KERNEL=y
CONFIG_GCOV_PROFILE_ALL=y
CONFIG_DEBUG_FS=y
$ mount | grep debugfs
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
# ls -la /sys/kernel/debug/gcov/
total 0
drwxr-xr-x 2 root root 0 Jun 14 2013 .
drwx------ 17 root root 0 Jun 14 2013 ..
-rw------- 1 root root 0 Jun 14 2013 reset
I found nothing but a reset file (an empty file).
As "document" says:
90 4. Files
91 ========
92
93 The gcov kernel support creates the following files in debugfs:
94
95 /sys/kernel/debug/gcov
96 Parent directory for all gcov-related files.
97
98 /sys/kernel/debug/gcov/reset
99 Global reset file: resets all coverage data to zero when
100 written to.
101
102 /sys/kernel/debug/gcov/path/to/compile/dir/file.gcda
103 The actual gcov data file as understood by the gcov
104 tool. Resets file coverage data to zero when written to.
105
106 /sys/kernel/debug/gcov/path/to/compile/dir/file.gcno
107 Symbolic link to a static data file required by the gcov
108 tool. This file is generated by gcc when compiling with
109 option -ftest-coverage.
What should I do?
Does gcov still support latest linux version?
Any advice, and thanks.
`
The issue is likely gcc. Some newer versions no longer generate .ctors seections and are using .init_array instead. You can confirm this by doing a objdump -dr -j .ctors of one of your gcov enabled kernel objects. If it returns no such section found, try .init_array.
I'm working on a fix for this right now trying to understand the arcane mysteries of replacing .ctors with .init_array in the do_ctors call of init/main.c. It's not as simple as swapping the section names in vmlinux.lds.h
Sorry this is not yet an answer.
Do the following changes in vmlinux.lds.h file to add .init_array in .ctors section of vmlinux file and it will work : -
Thanks
GCOV support for ARM is not enabled in Kernel.
Please refer below URL, apply 2 patches to your kernel and you will be able to see gcov file on target
https://groups.google.com/forum/#!topic/linux.kernel/JsvylFnag-Y
For new kernel version above 3.7 or 3.8 you must be sudo user to get your gcda files.
sudo su
Now go to directory /sys/kernel/debug/gcov/
you will see the built linux code path.
I ran into the same problem and i think gcc is the curplit. When my gcc version was under 4.7, eveything seemly goes well. Otherwise the problem just like yous came out.
Why?
greebo52's answer is the answer.
How to solve?
you can use gcc under 4.7 or compile your own gcc 4.7. when you configure gcc 4.7, add this --disable-initfini-array.
like this:
./configure --disable-initfini-array ...(other options)
Related
I am trying to bootstrap cmake 3.11.3 on Ubuntu 16.04.4 LTS xenial.
I have upgrade my gnu g++ compiler as follows:
> $ g++ --version
g++ (Ubuntu 8.1.0-5ubuntu1~16.04) 8.1.0 Copyright (C) 2018 Free
Software Foundation, Inc. This is free software; see the source for
copying conditions. There is NO warranty; not even for MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE.
And manually re-pointed the symbolic links:
$ ll /usr/bin/*g++*
lrwxrwxrwx 1 root root 5 Jun 8 16:57 /usr/bin/g++ -> g++-8*
-rwxr-xr-x 1 root root 919832 Apr 24 15:02 /usr/bin/g++-5*
lrwxrwxrwx 1 root root 22 Jun 6 04:26 /usr/bin/g++-8 -> x86_64-linux-gnu-g++-8*
lrwxrwxrwx 1 root root 22 Jun 8 16:58 /usr/bin/x86_64-linux-gnu-g++ -> x86_64-linux-gnu-g++-8*
lrwxrwxrwx 1 root root 5 Apr 24 15:02 /usr/bin/x86_64-linux-gnu-g++-5 -> g++-5*
-rwxr-xr-x 1 root root 1071984 Jun 6 04:26 /usr/bin/x86_64-linux-gnu-g++-8*
However, I get the following error in the configuration of cmake:
$ sudo ./bootstrap
---------------------------------------------
CMake 3.11.3, Copyright 2000-2018 Kitware, Inc. and Contributors
Found GNU toolchain
C compiler on this system is: gcc
C++ compiler on this system is: g++
Makefile processor on this system is: make
g++ has setenv
g++ has unsetenv
g++ does not have environ in stdlib.h
g++ has stl wstring
g++ has <ext/stdio_filebuf.h>
---------------------------------------------
make: Warning: File 'Makefile' has modification time 2.3 s in the future
make: 'cmake' is up to date.
make: warning: Clock skew detected. Your build may be incomplete.
loading initial cache file /mnt/ganymede/user/gpeytavi/srv_admin/software/cmake-3.11.3/Bootstrap.cmk/InitialCacheFlags.cmake
CMake Error at CMakeLists.txt:92 (message):
The C++ compiler does not support C++11 (e.g. std::unique_ptr).
-- Configuring incomplete, errors occurred!
See also "/mnt/ganymede/user/gpeytavi/srv_admin/software/cmake-3.11.3/CMakeFiles/CMakeOutput.log".
See also "/mnt/ganymede/user/gpeytavi/srv_admin/software/cmake-3.11.3/CMakeFiles/CMakeError.log".
---------------------------------------------
Error when bootstrapping CMake:
Problem while running initial CMake
---------------------------------------------
Any idea why I get a c++11 std::unique_ptr non-compliant error?
In my case, the issue is because of the folder where I have CMake source code is in a mounted directory (in fact my entire rootfs is mounted over NFS)
So, I looked in 'mount' command output and selected '/run/user/1000' location as a local location as this is mounted using tmpfs and moved my CMake source code to this location.
with this, ./bootstrap && make && sudo make install executed successfully.
Actually the ./bootstrap script does try the different C++ standard flags with the compiler. So it should detect its capabilities automatically.
Please make sure you don't have any CXXFLAGS environment variable set and try from scratch again (the messages/warnings you get indicate several tries/errors in the same directory).
Output when Successful
As a reference on my Ubuntu calling CMake's ./bootstrap looks like this:
---------------------------------------------
CMake 3.11.20180423, Copyright 2000-2018 Kitware, Inc. and Contributors
Warning: This is an in-source build
Found GNU toolchain
C compiler on this system is: gcc
C++ compiler on this system is: g++ -std=gnu++1y
Makefile processor on this system is: make
g++ has setenv
g++ has unsetenv
g++ does not have environ in stdlib.h
g++ has stl wstring
g++ has <ext/stdio_filebuf.h>
---------------------------------------------
Debugging
For debugging your problem you also could:
Call ./bootstrap --verbose
Look into Bootstrap.cmk/cmake_bootstrap.log
Known Problem
I only once had a problem with bootstrap using clang compilers where I needed to do the following call:
export CXXFLAGS=-Xclang -std=c++1z -Xclang -stdlib=libc++
Alternative
If you just want to install the latest version see How to specify where CMake is installed in Ubuntu?
I was able to resolve the issue by ensuring that both the build machine and the NFS file server were synchronized by running ntpd on both.
For me it was clock skew. I use the below command :
date -s "2021-11-30 15:08:21"
to set the time to now for the server. Then it work, thanks...
I would like to create a static executable for Darwin for a small utility I wrote called difftodo. difftodo depends indirectly on pcre, and I would like people to be able to download a binary and run it without having to brew install pcre first.
If I compile without options, I get a binary that dynamically links pcre:
$ otool -L /Users/jml/src/difftodo/.stack-work/install/x86_64-osx/lts-7.1/8.0.1/bin/git-todo
/Users/jml/src/difftodo/.stack-work/install/x86_64-osx/lts-7.1/8.0.1/bin/git-todo:
/usr/local/opt/pcre/lib/libpcre.1.dylib (compatibility version 4.0.0, current version 4.7.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
Following instructions at https://github.com/commercialhaskell/stack/issues/1032, I tried the following:
$ stack build --ghc-options -static --ghc-options -optl-static
difftodo-0.2.0: configure
Configuring difftodo-0.2.0...
difftodo-0.2.0: build
Preprocessing library difftodo-0.2.0...
ld: illegal text reloc in '_c1TGM_info' to '_stg_sel_1_upd_info' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
`gcc' failed in phase `Linker'. (Exit code: 1)
-- While building package difftodo-0.2.0 using:
/Users/jml/.stack/setup-exe-cache/x86_64-osx/setup-Simple-Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack-work/dist/x86_64-osx/Cabal-1.24.0.0 build lib:difftodo exe:all-todos exe:diff-todo exe:git-todo --ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
I don't understand this failure at all.
Creating static Mac OS X C build implies that creating fully static binary on OS X is impossible and undesirable. However, I am content to have dynamic links to libSystem etc., just not to the third-party libraries I am depending on.
Note that I have a static version of pcre available:
$ ls -la /usr/local/opt/pcre/lib/
total 2700
drwxr-xr-x 18 jml admin 612 Oct 1 11:02 .
drwxr-xr-x 13 jml admin 442 Oct 1 11:02 ..
-r--r--r-- 1 jml admin 443872 Oct 1 11:02 libpcre.1.dylib
-r--r--r-- 1 jml admin 492016 Oct 1 11:02 libpcre.a
...
http://gelisam.blogspot.co.uk/2014/12/how-to-package-up-binaries-for.html describes a method for working around this problem: edit the link tables in the executable and ship it together with the libraries. I would much rather have a single executable.
I installed the golang.
~/go/bin$ ls
go godoc gofmt
Trying to test, but to no avail.
~/go/bin$ go version
-bash: /home/orc/go/bin/go: no such file or directory
My $PATH:
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/orc/go/bin:
Info:
~/go/bin$ uname -m
x86_64
~/go/bin$ file go
go: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
~/go/bin$ pwd
/home/orc/go/bin
Please tell me what's wrong?
UPDATE
~/go/bin$ ls -l
итого 28688
-rwxr-xr-x 1 orc orc 9571864 Фев 18 14:40 go
-rwxr-xr-x 1 orc orc 16164032 Фев 18 14:41 godoc
-rwxr-xr-x 1 orc orc 3594712 Фев 18 14:40 gofmt
~/go/bin$ ./go
-bash: ./go: Нет такого файла или каталога
!!!
~/go/bin$ file $(which ls)
/bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
~/go/bin$ uname -a
Linux olimp-web 2.6.32-5-amd64 #1 SMP Mon Jun 13 05:49:32 UTC 2011 x86_64 GNU/Linux
Please explain how to fix it?
Have you checked that you have the correct version for your architecture installed. I have just had this exact problem when I put a 32-bit binary on a 64-bit virtual machine. I removed the 32-bit version and installed the architecture appropriate version (based on the instructions on the website) and it worked. Hope that works for you too.
A couple of things to check, which may come to nothing, but they'll at least rule out things:
There's no indication in your question that your current directory is within /home/orc, a simple pwd should clarify that.
Can you run the file directly, such as with ./go or ~/go/bin/go?
Is it executable? The output of ls -l should clarify that.
Get the full machine details with uname -a.
Check the system executables in case it's somehow not 64-bit, despite the indication: file $(which ls).
Make sure there's no funny characters in the path that would prevent it being picked up there: echo $PATH | od -xcb.
Make sure your GOPATH is set up correctly (not sure this would affect go version but it's something extra to try).
In my case go compiler and language were not installed...
sudo apt install golang-go
For me this was the answer, this is on ubuntu18.04 windows subsystem linux 2 install:
export GOPATH=$HOME/go
export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin
I was facing the same issue in Docker, I'm writing an answer for anybody that may be using docker, In my case I had to install glibc, for context I'm using alpine3.17
And here's the portion of my dockerfile -
COPY --from=golang:1.19.5-alpine3.17 /usr/local/go/ /usr/local/go/
ENV GOPATH=/go
ENV PATH="${PATH}:/usr/local/go/bin:$GOPATH/bin"
RUN apk update && apk add --no-cache wget gcompat && apk -U upgrade
RUN wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub
RUN wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.35-r0/glibc-2.35-r0.apk
RUN apk add --force-overwrite glibc-2.35-r0.apk
I'm working with ruby1.8.7 on an embedded platform, and I'm trying to port the ruby sqlite3 gem onto the platform.
The underlying sqlite3_native.so makes successfully, and is installed on the target. ldd indicates that all dependencies are met. However, when I try to load it, I get a LoadError (File not Found). Other .so libraries in the same directory load successfully.
#ls -l
total 167
lrwxrwxrwx 1 root root 7 Oct 10 16:24 di.so -> di.so.5
-rw-r--r-- 1 root root 16540 Oct 10 15:29 di.so.5
-rwxrwxrwx 1 root root 37916 Mar 6 2012 serialport.so
-rwxrwxrwx 1 root root 51375 Oct 16 17:25 sqlite3_native.so
#[path_to_ruby]/bin/ruby -r ./di -e exit
#
#[path_to_ruby]/bin/ruby -r ./serialport -e exit
#
#[path_to_ruby]/bin/ruby -r ./ssqlite3_native -e exit
./sqlite3_native.so: File not found - ./sqlite3_native.so (LoadError)
Does anyone have any thoughts on possible causes?
Kind regards
Steve
The power of taking a walk to clear one's head....
The issue is in the linking of the library in the make process, not on the target machine.
The mkmf generated makefile links in libruby.so via the line
LIBS = $(LIBRUBYARG_SHARED) -lsqlite3 -lrt -ldl -lcrypt -lm -lc
removing libruby ( $(LIBRUBYARG_SHARED) ) changes the generated library in some subtle way (it is 20 bytes smaller) which then allows the ruby executable to locate and load the library.
I did install the libnfc 1.5.1 in the default directory (/usr/loca/
lib).
if i do an ls i see the libs there:
foo:libnfc-1.5.1 bar$ ls -l /usr/local/lib/libnfc*
-rwxr-xr-x 1 root wheel 62092 Nov 23 09:05 /usr/local/lib/libnfc.2.dylib
-rw-r--r-- 1 root wheel 226696 Nov 23 09:05 /usr/local/lib/libnfc.a
lrwxr-xr-x 1 root wheel 14 Nov 23 09:05 /usr/local/lib/libnfc.dylib ->libnfc.2.dylib
-rwxr-xr-x 1 root wheel 930 Nov 23 09:05 /usr/local/lib/libnfc.la
foo:libnfc-1.5.1 bar$
I did try to run the configure script from mfoc with the following command:
LDFLAGS="-L/usr/local/lib" ./configure
it says that I don't have libnfc >= 1.5.1
checking for LIBNFC... no
configure: error: libnfc >= 1.5.1 is mandatory.
any idea?
This is a guess, but the error looks like it comes from pkg-config. Try:
$ ./configure LDFLAGS=-L/usr/local/lib PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
You really need to look in config.log to see exactly why it cannot find the library.
EDIT: It has often been claimed that pkg-config is fundamentally broken. This case has finally persuaded me that that is indeed true. Setting LDFLAGS should be sufficient, and the fact that it isn't renders this configure script broken. With that in mind, it might be better to disable pkg-config by running configure with the argument PKG_CONFIG=:
Try setting DYLD_LIBRARY_PATH variable and point it to /usr/local/lib before running ./configure:
$ export DYLD_LIBRARY_PATH=/usr/local/lib
$ ./configure