Can you please let me know that which flag you have build now . That you were able to generate the .gcda files now. I am using this flag for compilation .
CFLAGS_linux= -m32 -fPIC -g -pg -fprofile-arcs -ftest-coverage --coverage
and for linking I am using this
LDFLAGS_linux= -m elf_i386 -Bstatic -L/usr/lib/gcc/x86_64-redhat-linux/4.1.1/32 --whole-archive -lgcov --no-whole-archive -Bdynamic -shared -L/usr/lib -fprofile-arcs -ftest-coverage -lc
I am able to generate .gcno and my process is also coming up. But when I am trying to run the process and performing some operation the .gcda is not getting generated.
Related
For some reasons, I want to build a static shared library: a self sustain
library that without any external dependent library.
My build environment is alpine linux.
(I believe that gcc is /usr/bin/aarch64-alpine-linux-musl-gcc)
I build my shared library as follows:
gcc -fpic -c jpg_to_bmp.c -o jpg_to_bmp.o
ld -fpic -shared -static -lc -lstdc++ jpg_to_bmp.o FreeImage/Dist/libfreeimage.a -o libmy_img_static.so
gcc -I ./ -L ./ main.c -o main.o
However
LD_LIBRARY_PATH=`pwd` ./main test.jpg test.bmp
dies with Segmentation fault
if I link the shared library without -static -lc -lstdc++
ld -fpic -shared -static -lc -lstdc++ jpg_to_bmp.o FreeImage/Dist/libfreeimage.a -o libmy_img_static.so
Everything works fine.
How do I build a static shared library(self-sustain) using musl ?
Did I miss any step or flag ?
I have a project with a makefile, linker file and some other c files. Whenever i try to run the make command from my windows. i end up with this error. I am using a cygwin terminal. The project was initially used Linux environment.
process_begin: CreateProcess(NULL, arm-none-eabi-gcc -c -g -Os -I. -fno-common -
ffunction-sections -ffreestanding -fno-builtin -mthumb -mcpu=cortex-m7 -specs=na
no.specs -Wall -Winline -fstack-usage -DSTM32F769xx -mfloat-abi=hard -mfpu=fpv5-
d16 -fno-strict-aliasing -Wno-discarded-qualifiers stm32init.c -o stm32init.o, .
..) failed.
make (e=2): The system cannot find the file specified.
make: *** [makefile:20: stm32init.o] Error 2
Let me know how i can fix this problem.
I'm working on a Linux project in C consisting of two different open source applications. "Project A" (libduo) creates an archive used for linking a couple test programs and creates the library like this:
/usr/bin/ar rv libduo.a duo.o http_parser.o https.o match.o parson.o urlenc.o
/usr/bin/ar: creating libduo.a
a - duo.o
a - http_parser.o
a - https.o
a - match.o
a - parson.o
a - urlenc.o
ranlib libduo.a
One of the libduo test programs is built like this:
gcc -g -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -I. -I. -DDUODIR=\"/usr/local/duo/libduo/etc\" -DHAVE_CONFIG_H -c test-duologin.c
gcc -o test-duologin test-duologin.o -L. -lduo -lssl -lcrypto
"Project B" is an OpenLDAP module which I've built with -lduo and a few options to tell it where to find things:
(cd .libs && rm -f pw-apr1.la && ln -s ../pw-apr1.la pw-apr1.la)
../../../libtool --mode=compile gcc -g -O2 -Wall -I../../../include -I../../../include -I../../../servers/slapd -I../../../contrib/slapd-modules/passwd/libduo -c pw-duo.c
gcc -g -O2 -Wall -I../../../include -I../../../include -I../../../servers/slapd -I../../../contrib/slapd-modules/passwd/libduo -c pw-duo.c -fPIC -DPIC -o .libs/pw-duo.o
gcc -g -O2 -Wall -I../../../include -I../../../include -I../../../servers/slapd -I../../../contrib/slapd-modules/passwd/libduo -c pw-duo.c -o pw-duo.o >/dev/null 2>&1
../../../libtool --mode=link gcc -g -O2 -Wall -version-info 0:0:0 \
-rpath /usr/local/libexec/openldap -module -o pw-duo.la pw-duo.lo libduo.a -lduo
*** Warning: Linking the shared library pw-duo.la against the
*** static library libduo.a is not portable!
cc -shared .libs/pw-duo.o libduo.a -lduo -Wl,-soname -Wl,pw-duo.so.0 -o .libs/pw-duo.so.0.0.0
/usr/bin/ld: libduo.a(duo.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
libduo.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:51: recipe for target 'pw-duo.la' failed
make: *** [pw-duo.la] Error 1
The Makefile I'm using is the same one distributed with the OpenLDAP project. I've just added a section in the Makefile to build my module, using the same options for the other modules already there but adding -lduo to my section along with the paths to the libduo includes and libduo.a.
As make suggests above, I've recompiled by adding -fPIC after the -Wall option but it the same error was repeated. As a last resort, I tried adding -static to the module build but make was having none of that either:
*** Warning: Linking the shared library pw-duo.la against the
*** static library libduo.a is not portable!
This is the first time I've tried to build a C application against a lib not in the standard Linux locations so not exactly sure what's going on. I suspect libduo is built intended to be statically linked into everything, but the OpenLDAP modules are designed to use shared libraries. Can anyone elucidate?
Update: with help of comments below and this link I created a shared library from the .o files and distributed/built against that.
I have a bunch of .cu files that use dynamic parallelism (a.cu, b.cu, c.cu.., e.cu, f.cu), and a main.c file that uses MPI to call functions from a.cu on multiple nodes. I'm trying to write a make file to compile the executable, but I keep facing the following errors:
cudafiles.o: In function `__cudaRegisterLinkedBinary_66_tmpxft_00001a84_00000000_17_cuda_device_runtime_compute_61_cpp1_ii_8b1a5d37':
link.stub:(.text+0x1fb): undefined reference to `__fatbinwrap_66_tmpxft_00001a84_00000000_17_cuda_device_runtime_compute_61_cpp1_ii_8b1a5d37'
Here is my makefile:
INCFILES=-I/usr/local/cuda-8.0/include -I/opt/mpi/mvapich2-gnu/2.2/include -I./
LIBFILES=-L/usr/local/cuda-8.0/lib64 -L/opt/mpi/mvapich2-gnu/2.2/lib
LIBS=-lcudart -lcudadevrt -lcublas_device -lmpi
ARCH=-gencode arch=compute_60,code=sm_60
NVCC=nvcc -ccbin g++
default: all
all: clean final.o
io.o: io.cpp
g++ -c -std=c++11 io.cpp
final.o: io.o a.cu b.cu c.cu d.cu e.cu f.cu main.cpp
$(NVCC) -std=c++11 $(INCFILES) $(LIBFILES) $(LIBS) -g -G -Xptxas -v -dc $(ARCH) a.cu b.cu c.cu d.cu e.cu f.cu
$(NVCC) -std=c++11 $(ARCH) $(INCFILES) $(LIBFILES) $(LIBS) -rdc=true -dlink a.o b.o c.o d.o e.o f.o io.o -o cudafiles.o
mpicxx -O3 $(INCFILES) $(LIBFILES) -c main.cpp -o main.o
mpicxx $(INCFILES) $(LIBFILES) $(LIBS) cudafiles.o a.o b.o c.o d.o e.o f.o io.o main.o -o exec
clean:
rm -rf *.o exec
The original problem reported was an undefined reference to main. This was arising from this line in the Makefile:
$(NVCC) -std=c++11 $(ARCH) $(INCFILES) $(LIBFILES) $(LIBS) -rdc=true a.o b.o c.o d.o e.o f.o io.o -o cudafiles.o
As constructed, this actually instructs nvcc to perform full/final linking. However the intent of this line was to perform the device-link step only, required when compiling with -rdc=true or -dc, and when not performing the final link with nvcc. In this case, the final link was being performed by mpicc/mpicxx. To perform the device-link step only, we need to specify -dlink. Without that switch, nvcc expects to do final linking, but fails because none of the supplied objects contain a main function. The correct solution, since we have no intent to do final link at this point, is to use the -dlink switch.
I also suggested converting everything to C++ style linking, since nvcc links that way. It might be possible to sort out a C-style link with a C++-style link, but this just seems troublesome to me. Therefore I suggested converting the only .c file (main.c) to a .cpp file, and convert from mpicc to mpicxx
The next problem that arose was undefined references to e.g. cudaSetDevice() and cudaFree(). These are part of the CUDA runtime API library ("libcudart"). When performing final link with nvcc, these are linked automatically. But since final link is being performed by mpicxx (basically a wrapper on g++), it's necessary to call out the link against that library specifically with -lcudart.
Finally, the remaining problem was a link-order problem. In a nutshell, link dependencies need to be satisfied from left to right in the linker command line. Different compilers are more or less picky about this. The final reordering changes were to specify the libraries to link against in the correct order, and also to specify these libraries at the end of the link command line, so that any dependencies on these libraries, to their left in the link command line, are satisfied.
I have a project in C language and it compiles just fine in visual studio without any problem. But for some reasons I need to compile it in CodeBlocks. I can't find a reason why I get this error when I build the project. This is the full build log :
mingw32-gcc.exe -g -W -O0 -DWIN32 -D_DEBUG -D_WINDOWS -D_USRDLL -DSERVICE_EXPORTS -DAXIS2_DECLARE_EXPORT -IC:\Tools\axis2c-bin-1.6.0-win32\include -I. -IC:\Tools\axis2c-bin-1.6.0-win32\include -IC:\Tools\axis2c-bin-1.6.0-win32\include\platforms -IE:\dev\CodeBlocks\MinGW -c C:\Tools\axis2c-bin-1.6.0-win32\bin\tools\wsdl2c\src_addToDatabase_CodeBlocks\adb_Person.c -o "Debug Win32\adb_Person.o"
mingw32-gcc.exe -g -W -O0 -DWIN32 -D_DEBUG -D_WINDOWS -D_USRDLL -DSERVICE_EXPORTS -DAXIS2_DECLARE_EXPORT -IC:\Tools\axis2c-bin-1.6.0-win32\include -I. -IC:\Tools\axis2c-bin-1.6.0-win32\include -IC:\Tools\axis2c-bin-1.6.0-win32\include\platforms -IE:\dev\CodeBlocks\MinGW -c C:\Tools\axis2c-bin-1.6.0-win32\bin\tools\wsdl2c\src_addToDatabase_CodeBlocks\adb_addTodatabaseMethod.c -o "Debug Win32\adb_addTodatabaseMethod.o"
mingw32-gcc.exe -g -W -O0 -DWIN32 -D_DEBUG -D_WINDOWS -D_USRDLL -DSERVICE_EXPORTS -DAXIS2_DECLARE_EXPORT -IC:\Tools\axis2c-bin-1.6.0-win32\include -I. -IC:\Tools\axis2c-bin-1.6.0-win32\include -IC:\Tools\axis2c-bin-1.6.0-win32\include\platforms -IE:\dev\CodeBlocks\MinGW -c C:\Tools\axis2c-bin-1.6.0-win32\bin\tools\wsdl2c\src_addToDatabase_CodeBlocks\adb_addTodatabaseMethodResponse.c -o "Debug Win32\adb_addTodatabaseMethodResponse.o"
mingw32-gcc.exe -g -W -O0 -DWIN32 -D_DEBUG -D_WINDOWS -D_USRDLL -DSERVICE_EXPORTS -DAXIS2_DECLARE_EXPORT -IC:\Tools\axis2c-bin-1.6.0-win32\include -I. -IC:\Tools\axis2c-bin-1.6.0-win32\include -IC:\Tools\axis2c-bin-1.6.0-win32\include\platforms -IE:\dev\CodeBlocks\MinGW -c C:\Tools\axis2c-bin-1.6.0-win32\bin\tools\wsdl2c\src_addToDatabase_CodeBlocks\axis2_extension_mapper.c -o "Debug Win32\axis2_extension_mapper.o"
mingw32-gcc.exe -g -W -O0 -DWIN32 -D_DEBUG -D_WINDOWS -D_USRDLL -DSERVICE_EXPORTS -DAXIS2_DECLARE_EXPORT -IC:\Tools\axis2c-bin-1.6.0-win32\include -I. -IC:\Tools\axis2c-bin-1.6.0-win32\include -IC:\Tools\axis2c-bin-1.6.0-win32\include\platforms -IE:\dev\CodeBlocks\MinGW -c C:\Tools\axis2c-bin-1.6.0-win32\bin\tools\wsdl2c\src_addToDatabase_CodeBlocks\axis2_stub_AddToDatabaseService.c -o "Debug Win32\axis2_stub_AddToDatabaseService.o"
mingw32-gcc.exe -g -W -O0 -DWIN32 -D_DEBUG -D_WINDOWS -D_USRDLL -DSERVICE_EXPORTS -DAXIS2_DECLARE_EXPORT -IC:\Tools\axis2c-bin-1.6.0-win32\include -I. -IC:\Tools\axis2c-bin-1.6.0-win32\include -IC:\Tools\axis2c-bin-1.6.0-win32\include\platforms -IE:\dev\CodeBlocks\MinGW -c C:\Tools\axis2c-bin-1.6.0-win32\bin\tools\wsdl2c\src_addToDatabase_CodeBlocks\main.c -o "Debug Win32\main.o"
mingw32-gcc.exe -g -W -O0 -DWIN32 -D_DEBUG -D_WINDOWS -D_USRDLL -DSERVICE_EXPORTS -DAXIS2_DECLARE_EXPORT -IC:\Tools\axis2c-bin-1.6.0-win32\include -I. -IC:\Tools\axis2c-bin-1.6.0-win32\include -IC:\Tools\axis2c-bin-1.6.0-win32\include\platforms -IE:\dev\CodeBlocks\MinGW -c C:\Tools\axis2c-bin-1.6.0-win32\bin\tools\wsdl2c\src_addToDatabase_CodeBlocks\adb_Message.c -o "Debug Win32\adb_Message.o"
mingw32-g++.exe -LC:\Tools\axis2c-bin-1.6.0-win32\lib -LC:\Tools\axis2c-bin-1.6.0-win32\lib -LE:\dev\CodeBlocks\MinGW\lib -o AddToDatabaseServiceClient.exe "Debug Win32\adb_Person.o" "Debug Win32\adb_addTodatabaseMethod.o" "Debug Win32\adb_addTodatabaseMethodResponse.o" "Debug Win32\axis2_extension_mapper.o" "Debug Win32\axis2_stub_AddToDatabaseService.o" "Debug Win32\main.o" "Debug Win32\adb_Message.o" C:\Tools\axis2c-bin-1.6.0-win32\lib C:\Tools\axis2c-bin-1.6.0-win32\lib\axiom.lib C:\Tools\axis2c-bin-1.6.0-win32\lib\axutil.lib C:\Tools\axis2c-bin-1.6.0-win32\lib\axis2_engine.lib
e:/dev/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: C:\Tools\axis2c-bin-1.6.0-win32\lib: No such file: Permission denied
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 8 seconds)
0 errors, 0 warnings
I'm using CodeBlocks 10.05 and GNU GCC compiler(minGW). the project is an axis2c generated C webservice client.
I put -fPIC in Other options tab under the Compiler settings. then I rebuilt the project. as it was mentioned in CodeBlocks-wiki . I tried to run the application but I got that error again.
I have another question that I posted in This link which is related to this issue. I'd appreciate it if anyone help me.
Do you see that the linker's error message says:
C:\Tools\axis2c-bin-1.6.0-win32\lib: No such file
That is because there is no such file as C:\Tools\axis2c-bin-1.6.0-win32\lib. It is a directory, and you cannot "link a directory", just as you cannot "compile a directory".
We can be sure it is a directory because all the libraries that you are linking are in that directory:
C:\Tools\axis2c-bin-1.6.0-win32\lib\axiom.lib
C:\Tools\axis2c-bin-1.6.0-win32\lib\axutil.lib
C:\Tools\axis2c-bin-1.6.0-win32\lib\axis2_engine.lib
and also because you have specified (twice) that it is a directory that the linker should search to find libraries:
-LC:\Tools\axis2c-bin-1.6.0-win32\lib -LC:\Tools\axis2c-bin-1.6.0-win32\lib
You need to either:
Replace C:\Tools\axis2c-bin-1.6.0-win32\lib in your Link libraries settings with
C:\Tools\axis2c-bin-1.6.0-win32\lib\<name_of_some_missing_library>.lib
or, if there is no missing library (the 3 above are all you need), then:
Delete C:\Tools\axis2c-bin-1.6.0-win32\lib from your Link libraries settings
You can also delete -LC:\Tools\axis2c-bin-1.6.0-win32\lib from the Other linker options
(if that's how you've specified this linker search path), and/or you can delete
C:\Tools\axis2c-bin-1.6.0-win32\lib from Search directories -> Linker (if
that's how you've done it). You are specifying all of the axis libraries by absolute
pathnames, so there is no need to tell the linker where to look for them.
You may have also have produced this duplicated linker search path by specifying it
once in Settings -> Compiler -> Global compiler settings and again in the Linker settings or
Search directories -> Linker of your project. If so, remove it from the global compiler settings.
Those settings are ones that you want to apply to every project that you build with the compiler: that's the significance of Global.
-fPIC has no relevance whatever and you do not require it to build an .exe
I did what #Mike Kinghan said.
plus I searched and found out that the libraries that I'm using are compiled with MSVC++ and cannot be used with MinGW. according to this topic.
I created .def files with reimp
then I modified each stdcall function in .def files (I changed "_name#ordinal" to "name")
then I used dlltool to create .a files.
I linked the .a files to my project.
Everything went fine and I could compile my project. but when I try to run it. I get this error.
The procedure entry point axiom_attribute_create could not be located in the dynamic link library
I have got no idea what to do.