I am trying to set up static analysis for our code base which is cross compiled for a ARM based CPU. It appears that scan-build provided by clang is one of the best open source solutions for this. When I run scan-build, this is what I get.
$ scan-build-3.8 --use-cc=arm-linux-gnueabi-gcc --analyzer-target=arm-linux-gnueabi make
scan-build: Using '/usr/lib/llvm-3.8/bin/clang' for static analysis
echo "(Version file)"
(Version file)
/opt/sysroots/x86_64-linux/usr/libexec/arm-linux-gnueabi/gcc/arm-linux-gnueabi/6.3.0/real-ld: cannot find crti.o: No such file or directory
/opt/sysroots/x86_64-linux/usr/libexec/arm-linux-gnueabi/gcc/arm-linux-gnueabi/6.3.0/real-ld: cannot find crtbeginS.o: No such file or directory
/opt/sysroots/x86_64-linux/usr/libexec/arm-linux-gnueabi/gcc/arm-linux-gnueabi/6.3.0/real-ld: cannot find -lgcc
/opt/sysroots/x86_64-linux/usr/libexec/arm-linux-gnueabi/gcc/arm-linux-gnueabi/6.3.0/real-ld: cannot find -lgcc_s
/opt/sysroots/x86_64-linux/usr/libexec/arm-linux-gnueabi/gcc/arm-linux-gnueabi/6.3.0/real-ld: cannot find -lc
/opt/sysroots/x86_64-linux/usr/libexec/arm-linux-gnueabi/gcc/arm-linux-gnueabi/6.3.0/real-ld: cannot find -lgcc
/opt/sysroots/x86_64-linux/usr/libexec/arm-linux-gnueabi/gcc/arm-linux-gnueabi/6.3.0/real-ld: cannot find -lgcc_s
/opt/sysroots/x86_64-linux/usr/libexec/arm-linux-gnueabi/gcc/arm-linux-gnueabi/6.3.0/real-ld: cannot find crtendS.o: No such file or directory
/opt/sysroots/x86_64-linux/usr/libexec/arm-linux-gnueabi/gcc/arm-linux-gnueabi/6.3.0/real-ld: cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status
Clearly, Linker is trying to find some files and not finding it. I dug a little more deeper into how the linker gets the files by running this command.
$ /opt/sysroots/x86_64-dspg-linux/usr/libexec/arm-linux-gnueabi/gcc/arm-linux-gnueabi/6.3.0/real-ld crti.o --verbose
This prints a lot of data, this what I found interesting.
SEARCH_DIR("=/opt/dspg/v2.4.0-rc2/sysroots/x86_64-dspg-linux/usr/arm-dspg-linux-gnueabi/lib"); SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib");
My crti.o is not located in any of the paths above and hence ld is failing.
Now the question. When the scan-build calls the linker how does it inform the search directories and can I change it ?
Related
I'm trying to cross compile bluez 4.60 to a 32bit arm platform, when I try and cross compile using the following command:
./configure '--enable-shared=yes' '--enable-static=no' '--disable-network' '--enable-sap' '--disable-serial' '--enable-input' '--disable-audio' '--disable-service' '--enable-health' '--disable-pnat' '--disable-gstreamer' '--disable-alsa' '--enable-usb' '--disable-tools' '--disable-bccmd' '--disable-pcmcia' '--enable-hid2hci' '--enable-dfutool' '--enable-hidd' '--enable-pand' '--enable-dund' '--disable-cups' '--disable-test' '--disable-datafiles' '--enable-maemo6' '--enable-dbusoob' '--disable-wiimote' '--enable-hal' '--disable-gatt' '--disable-udevrules' '--disable-configfiles' --build=x86_64-linux-gnu --host=arm-linux-gnueabihf
I get:
<toolchain>/7.3.0/real-ld: cannot find crti.o: No such file or directory
<toolchain>/7.3.0/real-ld: cannot find crtbeginS.o: No such file or directory
<toolchain>/7.3.0/real-ld: cannot find -ludev
<toolchain>/7.3.0/real-ld: cannot find -lgcc
<toolchain>/7.3.0/real-ld: cannot find -lgcc_s
<toolchain>/7.3.0/real-ld: cannot find -lc
<toolchain>/7.3.0/real-ld: cannot find -lgcc
<toolchain>/7.3.0/real-ld: cannot find -lgcc_s
<toolchain>/7.3.0/real-ld: cannot find crtendS.o: No such file or directory
<toolchain>/7.3.0/real-ld: cannot find crtn.o: No such file or directory
after some search it seems that -lc and -lgcc etc., are from libc. the -ludev made me think it was failing to find any libraries at all in the toolchain but after further investigation it found glib just find which is what's so confusing.
I'm hitting a linker error (compile time, not run time):
ld: library not found for -l:/usr/lib/libobjc.A.dylib
That's just the latest version of the error. I'm trying to link against /usr/lib/libobjc.A.dylib, and I want to hard-code the path; the library is guaranteed to exist at this path on the platform I'm on. And it does:
bhaller#lanois % ls -l /usr/lib/libobjc.A.dylib
-rwxr-xr-x 1 root wheel 859536 Jan 23 08:59 /usr/lib/libobjc.A.dylib
I have tried:
-L/usr/lib/ -llibobjc.A.dylib
-L/usr/lib/ -llibobjc.A
-l/usr/lib/libobjc.A.dylib
-l:/usr/lib/libobjc.A.dylib
In every case I get the same error, that ld couldn't find the library. But it's right there, and I'm giving the complete path to it! What am I missing??
Here's the full invocation, with a bunch of other cruft:
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -arch x86_64 -headerpad_max_install_names -macosx_version_min 10.10.0 -o QtSLiM.app/Contents/MacOS/QtSLiM -L/Users/bhaller/Desktop/QtSLiM QMAKE/QtSLiM/../core/ -L/Users/bhaller/Desktop/QtSLiM QMAKE/QtSLiM/../eidos/ -L/Users/bhaller/Desktop/QtSLiM QMAKE/QtSLiM/../treerec/tskit/ -L/Users/bhaller/Desktop/QtSLiM QMAKE/QtSLiM/../gsl/ -L/Users/bhaller/Desktop/QtSLiM QMAKE/QtSLiM/../eidos_zlib/ -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -rpath #executable_path/Frameworks -rpath /Users/bhaller/Qt5.9.8/5.9.8/clang_64/lib main.o QtSLiMWindow.o QtSLiMAppDelegate.o QtSLiMWindow_glue.o QtSLiMChromosomeWidget.o QtSLiMExtras.o QtSLiMPopulationTable.o QtSLiMIndividualsWidget.o QtSLiMEidosPrettyprinter.o QtSLiMAbout.o QtSLiMPreferences.o QtSLiMSyntaxHighlighting.o QtSLiMFindRecipe.o QtSLiMHelpWindow.o QtSLiMScriptTextEdit.o QtSLiMEidosConsole.o QtSLiMEidosConsole_glue.o QtSLiMConsoleTextEdit.o QtSLiM_SLiMgui.o QtSLiMTablesDrawer.o QtSLiMFindPanel.o QtSLiMGraphView.o QtSLiMGraphView_FixationTimeHistogram.o QtSLiMGraphView_FrequencySpectra.o QtSLiMGraphView_LossTimeHistogram.o QtSLiMGraphView_PopulationVisualization.o QtSLiMGraphView_FitnessOverTime.o QtSLiMGraphView_FrequencyTrajectory.o QtSLiMHaplotypeManager.o QtSLiMHaplotypeOptions.o QtSLiMHaplotypeProgress.o QtSLiMVariableBrowser.o qrc_buttons.o qrc_icons.o qrc_recipes.o qrc_help.o moc_QtSLiMWindow.o moc_QtSLiMAppDelegate.o moc_QtSLiMChromosomeWidget.o moc_QtSLiMExtras.o moc_QtSLiMPopulationTable.o moc_QtSLiMIndividualsWidget.o moc_QtSLiMAbout.o moc_QtSLiMPreferences.o moc_QtSLiMSyntaxHighlighting.o moc_QtSLiMFindRecipe.o moc_QtSLiMHelpWindow.o moc_QtSLiMScriptTextEdit.o moc_QtSLiMEidosConsole.o moc_QtSLiMConsoleTextEdit.o moc_QtSLiMTablesDrawer.o moc_QtSLiMFindPanel.o moc_QtSLiMGraphView.o moc_QtSLiMGraphView_FixationTimeHistogram.o moc_QtSLiMGraphView_FrequencySpectra.o moc_QtSLiMGraphView_LossTimeHistogram.o moc_QtSLiMGraphView_PopulationVisualization.o moc_QtSLiMGraphView_FitnessOverTime.o moc_QtSLiMGraphView_FrequencyTrajectory.o moc_QtSLiMHaplotypeManager.o moc_QtSLiMHaplotypeOptions.o moc_QtSLiMHaplotypeProgress.o moc_QtSLiMVariableBrowser.o -lcore -leidos -ltskit -lgsl -leidos_zlib -l:/usr/lib/libobjc.A.dylib -framework QtOpenGL -framework QtWidgets -framework QtGui -framework QtCore -framework DiskArbitration -framework IOKit -framework OpenGL -framework AGL -lc++ -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0/lib/darwin/libclang_rt.osx.a -F/Users/bhaller/Qt5.9.8/5.9.8/clang_64/lib
ld: library not found for -l:/usr/lib/libobjc.A.dylib
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [QtSLiM.app/Contents/MacOS/QtSLiM] Error 1
make: *** [sub-QtSLiM-make_first] Error 2
I feel like I must just be an idiot, but I can't see it. Help?
Your linkage command shows that your linker is the OS X linker. Refer to it's manual
with respect to the -l option:
-lx
This option tells the linker to search for libx.dylib or libx.a in the library search path.
If string x is of the form y.o, then that file is searched for in the same places, but
without prepending lib or appending .a or .dylib to the filename.
This will show you why all of:
-L/usr/lib/ -llibobjc.A.dylib
-L/usr/lib/ -llibobjc.A
-l/usr/lib/libobjc.A.dylib
-l:/usr/lib/libobjc.A.dylib
are wrong. In each of your attempts, where name is whatever you have typed after -l,
the linker will be directed to search for libname.dylib or libname.a. Of course
none of those files - e.g. liblibobjc.A.dylib.dylib,liblibobjc.A.dylib.a - exists
in /usr/lib/ or any of the other specified or default search directories, and
in the third and fourth attempts, libname.(dylib|a) resolves to strings that that
cannot even possibly be unqualified filenames.
Your final variation evidently wants to used -l:name in an attempt to make the linker
search precisely for name ( = /usr/lib/libobjc.A.dylib). However,
-l:name is an option for the GNU Binutils linker, (the default linker in Linux)
and as per the documentation, is not an option for the OS X linker. (Furthermore, that option of the Binutils linker
directs the linker to search in each directory for a file with the exact unqualified name name, which /usr/lib/libobjc.A.dylib
could not be).
To get the linker to locate libobjc.A.dylib in /usr/lib/ you require the option:
-lobjc.A
Consider for example the other -l options in your your linkage command:
-lcore -leidos -ltskit -lgsl -leidos_zlib
Before you try that however, I suggest that you check in /usr/lib for the existence
of a symbolic link:
libobjc -> libobjc.A
This would indicate that libobjc.A is the version of libobjc that your toolchain
is configured to select, and that the linkage option you require is simply:
-lobjc
The search option -L/usr/lib/ is in any case redundant, since /usr/lib/ is a default
linker search directory.
I am getting the below error during ./configure.
configure:3429: checking whether the C compiler works
configure:3451: gcc -m32 -D_FILE_OFFSET_BITS=64 -m32 conftest.c >&5
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/4.4.7/libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/4.4.7/libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status
configure:3455: $? = 1
configure:3493: result: no
configure:3498: error: in `/root/cjk/1.x/src/externals/mecab':
configure:3500: error: C compiler cannot create executables
I have tried couple of solutions mentioned in internet but to no avail.
I have installed complete Developers package in the machine.
I have installed glibc-devel.i686 package as well.
I ran into the exact same issue (CentOS 6.5 x64, gcc 4.4.7). I made sure yum install glibc-devel.i686 was performed. A quick find / -name "libgcc_s.*" revealed:
/lib64/libgcc_s.so.1
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgcc_s.so
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgcc_s.so
So, perhaps you can try the workaround suggested here:
Add the absolute path to the gcc_s library on the link line, OR
(Recommended) If the library's filename has any major and minor version numbers appended to it, simply create a soft link to the library in the same location without the major and minor version numbers in the target filename.
I settled for compiling/linking my application statically by adding -static to my gcc invocation. So,
gcc -static -m32 ...
In that case make sure yum install glibc-static.i686 is done.
I'm trying to compile this on Ubuntu but it doesn't link and I don't understand why.
http://ubee.enseeiht.fr/vision/ELSD/
home#home:~/projects/elsd_1.0$ make
cc -I/usr/local/include -L/usr/local/lib -o elsd elsd.c valid_curve.c process_curve.c process_line.c write_svg.c -llapack_LINUX -lblas_LINUX -llibf2c -lm
/usr/bin/ld: cannot find -llapack_LINUX
/usr/bin/ld: cannot find -lblas_LINUX
/usr/bin/ld: cannot find -llibf2c
collect2: error: ld returned 1 exit status
make: *** [elsd] Error 1
home#home:~/projects/elsd_1.0$
home#home:~/projects/elsd_1.0$ ls /usr/local/lib
blas_LINUX.a libcblaswr.a python2.7 site_ruby
lapack_LINUX.a node_modules python3.4 tmglib_LINUX.a
home#home:~/projects/elsd_1.0$
home#home:~/projects/elsd_1.0$ ls /usr/local/include
blaswrap.h clapack.h f2c.h
home#home:~/projects/elsd_1.0$
My mail problem as solved by SSC by telling me to add -Wl --verbose to see what the linker was doing, my main problem was CLAPACK.
Download clapack.tgz which extracts to directory CLAPACK-3.2.1, go to this directory.
mv make.inc.example make.inc
Type make
Now I have blas_LINUX.a lapack_LINUX.a tmglib_LINUX.a in this directory.
Copy the header files from INCLUDE to /usr/local/include, have to chmod a+r .... to give read access
In elsd_1.0 edit the makefile and change "-llapack_LINUX -lblas_LINUX" to "-llapack -lblas"
I guess I did something with the .a files in step 4 maybe I moved the to /usr/local/lib.
Anyway, as long as CLAPACK can link then it works.
I'm trying to compile a makefile which includes the following line:
gcc -I. -I/home/usr/Documents/MTV/include -ggdb3 -Wall -O2 -o ascii2bin.c \
-L. -L../lib -lmatrix -lseq_io -lpic -lm
And this is what I get:
../lib/libmatrix.a: file not recognized: File format not recognized
collect2: ld returned 1 exit status
Any idea on what might happen to libmatrix.a? How can I read what's inside libmatrix.a? I tried using the 'ar -t' command, but it also says file format not recognized.
The project was compiled on Cygwin before by others, and now I'm using ubuntu gcc to try to redo it, could this be the problem?
A library file built for cygwin will not work on linux.
The library itself must be recompiled from source to match the details (ABI, dynamic system library dependencies, etc) of the system on which it is intended to be used.
Cygwin tries to be source compatible with Linux, so if you have the source rebuilding may be straightforward. But it is not binary-compatible, and libraries are basically binary building blocks with metadata to permit linking them together.