I'm using the following options:
touch foo.f90; gfortran -cpp -E -dM foo.f90
, but when I remove the -E flag I get this error:
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o: in function `_start':
(.text+0x24): undefined reference to `main'
collect2: error: ld returned 1 exit status
As I used 'touch' the file is empty.
The -E flag is described in the manual.
If you use the -E option, nothing is done except preprocessing. Some
of these options make sense only together with -E because they cause
the preprocessor output to be unsuitable for actual compilation.
It makes the compiler to print the preprocessed source code instead of compiling it. That means preprocessed by cpp, the C preprocessor.
If your source code is not a valid Fortran program, then trying to actually compile it (without the -E flag) naturally leads to some kind of error message.
Related
I was trying to compile hello.cob to hello.c:
$ ls
hello.cob
$ cobc -x -C hello.cob
$ ls
hello.c hello.c.h hello.c.l.h hello.cob
But clang failed to compile hello.c to executable file:
$ clang hello.c
/tmp/hello-479acf.o: In function `main':
hello.c:(.text+0x1e): undefined reference to `cob_init'
hello.c:(.text+0x2a): undefined reference to `cob_stop_run'
/tmp/hello-479acf.o: In function `sampleCOBOL_':
hello.c:(.text+0x98): undefined reference to `cob_module_global_enter'
hello.c:(.text+0x133): undefined reference to `cob_display'
hello.c:(.text+0x13f): undefined reference to `cob_stop_run'
hello.c:(.text+0x15a): undefined reference to `cob_check_version'
hello.c:(.text+0x33d): undefined reference to `cob_set_cancel'
hello.c:(.text+0x38e): undefined reference to `cob_fatal_error'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Here is hello.cob (can be compiled by cobc -x hello.cob):
IDENTIFICATION DIVISION.
PROGRAM-ID. sampleCOBOL.
PROCEDURE DIVISION.
DISPLAY "Hello World!".
STOP RUN.
I'm quite sure clang doesn't fail to compile the C source as you don't ave any C compiler warnings or errors.
It cannot link the generated object file because you didn't told clang to link against libcob and there is no "magic" for clang to know where to find its symbols. Adding -lcob to your clang invocation may be enough already.
If you want to know how cobc invokes the compiler/linker add -v to your cobc invocation.
Note: if this version of cobc was built with gcc it defaults to use gcc, too. You can see this with cobc --info which also shows if any of the built-in commands is override by environment variables.
Additional note: cobc does not only call a C compiler/linker, it also generates C code specific for the compiler it was built with. The most important part concerning the C generation is -f[no-]computed-goto, just in case the C compiler complains (which it doesn't in your case).
I'm trying to install OpenDetection on Ubuntu 16.04.
I have installed all the dependencies according to here except OpenCV.
This is the CMake command I used for OpenCV:
cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -D WITH_TBB=ON -D BUILD_NEW_PYTHON_SUPPORT=ON -D WITH_V4L=ON -D WITH_VTK=ON -D INSTALL_C_EXAMPLES=ON -D INSTALL_PYTHON_EXAMPLES=ON -D BUILD_EXAMPLES=ON -D ENABLE_FAST_MATH=1 -D CUDA_FAST_MATH=1 -D WITH_CUBLAS=1 -DOPENCV_EXTRA_MODULES_PATH=/home/tiestu/Documents/GitRepository/OpenCV3/opencv_contrib/modules /home/tiestu/Documents/GitRepository/OpenCV3/opencv
But when I try to make OpenCV, I receive this error which I believe has something to do with VTK!
I have configured VTK using latest prebuilt binary version of cmake with the default settings, as per installation instructions. but this error says:
vtkGenericDataArrayLookupHelper.h:72:23: error: ‘nullptr’ was not declared in this scope
The full error/warning section of the build output is:
In file included from /usr/local/include/vtk-7.1/vtkGenericDataArray.h:72:0,
from /usr/local/include/vtk-7.1/vtkAOSDataArrayTemplate.h:35,
from /usr/local/include/vtk-7.1/vtkIntArray.h:33,
from /usr/local/include/vtk-7.1/vtkCellTypes.h:42,
from /usr/local/include/vtk-7.1/vtkPolyData.h:64,
from /usr/local/include/vtk-7.1/vtkPolyDataAlgorithm.h:36,
from /usr/local/include/vtk-7.1/vtkAppendPolyData.h:35,
from /home/tiestu/Documents/GitRepository/OpenCV3/opencv/modules/viz/src/precomp.hpp:56,
from /home/tiestu/Documents/GitRepository/OpenCV3/opencv/release/modules/viz/opencv_viz_pch_dephelp.cxx:1:
/usr/local/include/vtk-7.1/vtkGenericDataArrayLookupHelper.h:72:5: warning: identifier ‘nullptr’ is a keyword in C++11 [-Wc++0x-compat]
: AssociatedArray{nullptr}, SortedArray(nullptr),
^
/usr/local/include/vtk-7.1/vtkGenericDataArrayLookupHelper.h: In constructor ‘vtkGenericDataArrayLookupHelper<ArrayTypeT>::vtkGenericDataArrayLookupHelper()’:
/usr/local/include/vtk-7.1/vtkGenericDataArrayLookupHelper.h:72:22: warning: extended initializer lists only available with -std=c++11 or -std=gnu++11
: AssociatedArray{nullptr}, SortedArray(nullptr),
^
/usr/local/include/vtk-7.1/vtkGenericDataArrayLookupHelper.h:72:23: error: ‘nullptr’ was not declared in this scope
: AssociatedArray{nullptr}, SortedArray(nullptr),
^
/usr/local/include/vtk-7.1/vtkGenericDataArrayLookupHelper.h:73:15: warning: extended initializer lists only available with -std=c++11 or -std=gnu++11
FirstValue{nullptr}, SortedArraySize{0}
^
/usr/local/include/vtk-7.1/vtkGenericDataArrayLookupHelper.h:73:41: warning: extended initializer lists only available with -std=c++11 or -std=gnu++11
FirstValue{nullptr}, SortedArraySize{0}
^
modules/viz/CMakeFiles/opencv_viz_pch_dephelp.dir/build.make:62: recipe for target 'modules/viz/CMakeFiles/opencv_viz_pch_dephelp.dir/opencv_viz_pch_dephelp.cxx.o' failed
make[2]: *** [modules/viz/CMakeFiles/opencv_viz_pch_dephelp.dir/opencv_viz_pch_dephelp.cxx.o] Error 1
CMakeFiles/Makefile2:6005: recipe for target 'modules/viz/CMakeFiles/opencv_viz_pch_dephelp.dir/all' failed
make[1]: *** [modules/viz/CMakeFiles/opencv_viz_pch_dephelp.dir/all] Error 2
Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2
Does it matter what version of compiler (11 or 0x) I've used? If so what version should I use?
You need to use a compiler that supports the version of OpenCV that you are using, and the version of the C++ language that it uses, which from your error and warning diagnostic messages, looks be at least C++11.
You can read the documentation for the compiler version you have to see what C++ language versions it supports. There's also a support information table on cppreference.com.
It's interesting that you get such errors and warnings at all. Libraries should be able to tell CMake in its CMake configuration what C++ language version it uses in its source files, and CMake would keep track of that requirement to make sure the correct compiler flags get used wherever needed. See the target_compile_features() command for more info on that.
I'm trying to use clang with OpenMPI. I have set the wrapper compiler using
export OMPI_CC=clang
When I try to verify the compiler mpicc is invoking by using
mpicc --showme:command
I get this error
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status
However, a sample mpi code runs fine using regular mpicc and mpirun commands, I guess its sticking back to the default mpicc compiler and not clang. I need to use certain clang functionalities for the OpenMPI code. How do I rectify this error.
This is basically the same issue as in mingw ld cannot find some library which is exist in the search path, MinGW linker can't find MPICH2 libraries - and I'm aware that there are heaps of posts on StackOverflow regarding the issue of static and dynamic linking with MinGW - but I couldn't find anything that explains how I can troubleshoot.
I am building a project with a huge linker command like (via g++) on MinGW, in a MSYS2 shell (git-bash.exe). The process fails with, among others:
/z/path/to/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lssl
I add -Wl,--verbose to the g++ linker call (to be passed to ld), and I can see for the -L/z/path/to/libs/openssl/lib/mingw -lssl:
...
attempt to open /z/path/to/libs/openssl/lib/mingw/libssl.a failed
...
/z/path/to/libs/openssl/lib/mingw/ssl.dll failed
attempt to open /z/path/to/libs/openssl/lib/mingw\libssl.a failed
...
But this is weird, because the file exists?
$ file /z/path/to/libs/openssl/lib/mingw/libssl.a
/z/path/to/libs/openssl/lib/mingw/libssl.a: current ar archive
(... and it was built with the same compiler on the same machine)?
Weirdly, once it attempts to open with forward slash .../libssl.a, once with backslash ...\libssl.a - but at least the first path checks out in a bash shell, as shown above?
It gets even worse if I try to specify -l:libssl.a -- or if I specify -L/z/path/to/libs/openssl/lib/mingw -Wl,-Bstatic -lssl -- instead; then all attempts to open are with a backslash:
...
attempt to open /z/path/to/scripts/other/build/openssl/build/mingw/lib\libssl.a failed
attempt to open /z/path/to/libs/openssl/lib/mingw\libssl.a failed
...
To top it all off, if I look it up manually through the command line using ld, it is found ?!:
$ ld -L/z/path/to/libs/openssl/lib/mingw -lssl --verbose
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.dll.a failed
attempt to open Z:/path/to/libs/openssl/lib/mingw/ssl.dll.a failed
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
Does anyone have an idea why this happens, and how can I get ld to finally find these libraries? Or rather - how can I troubleshoot, and understand why these libraries are not found, when they exist at the paths where ld tries to open them?
OK, found something more - not sure if this is a bug; but my problem is that I'm actually reading arguments from a file (otherwise I get g++: Argument list too long). So, to simulate that:
$ echo " -Wl,--verbose -L/z/path/to/libs/openssl/lib/mingw -lssl -lcrypto " > tmcd3
$ g++ #tcmd3 2>&1 | grep succeeded | grep ssl
# nothing
$ g++ `cat tcmd3` 2>&1 | grep succeeded | grep ssl
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
attempt to open Z:/path/to/libs/openssl/lib/mingw/libcrypto.a succeeded
... it turns out, if the very same arguments are fed on the command line, then static library lookup succeeds - but if the arguments are read from file through the # at-sign, then static library lookup fails?! Unfortunately, I cannot use on my actual project, since even with cat, I'd still get g++: Argument list too long ... So how can I fix this?
MSYS has special handling of directories as arguments when they are used in the shell. This translates e.g. /<drive_letter>/blabla to the proper Windows style paths. This is to accomodate Unix programs that don't handle Z: style directory root.
What you see here is that MSYS isn't performing this interpretation for string read from a file. When you think about it, it's very logical, but as you have experienced first-hand, also sometimes annoying.
Long story short: don't put Unix style paths in files with command arguments. Instead, pass them through e.g. cygpath -w, which works in MSYS2 (which should be the MSYS that Git for Windows 2+ comes with).
Ok, with some more experiments, I noticed that:
-L/z/path/to/libs/openssl/lib/mingw, the Unix path specification, tends to fail - while if we specify the same, except starting with a Windows drive letter, that is:
-LZ:/path/to/libs/openssl/lib/mingw, then things work - also from an arguments file with # at-sign:
$ echo " -Wl,--verbose -LZ:/path/to/libs/openssl/lib/mingw -lssl -lcrypto " > tmcd3
$ g++ #tcmd3 2>&1 | grep succeeded | grep ssl
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
attempt to open Z:/path/to/libs/openssl/lib/mingw/libcrypto.a succeeded
I guess, since the shell is MSYS2/git-bash.exe, entering full POSIX paths on the shell with /z/... is not a problem, because the shell will convert them - but in a file, there is nothing to convert them, so we must use Windows/MingW convention to specify them...
I have been trying to enable the gold linker on FreeBSD to use the link time optimizations. I made gold from the binutils under /usr/ports. After building binutils using make -k install clean i got ld under /usr/bin and in the directory /usr/local/bin i got ld, ld.gold and ld.bfd.
Now while trying to use link time optimization for the simple example programs here http://llvm.org/docs/GoldPlugin.html (a.c and b.c under the heading 'Examples of Link Time Optimization') i entered the four commands as follows:
clang -flto a.c -c -o a.o
ar q a.a a.o
clang b.c -c -o b.o
clang -flto a.a b.o -o main
I got the following error:
usr/bin/ld: unrecogonized option '-plugin'
usr/bin/ld: use the --help option for usage information
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Is there the problem with the linker that ld.gold is not being called. Should I replace the ld with ld.gold? Does the linker looks in the right directiry for the .so plugins?
The LLVMgold.so and libLTO.so shared objects are in the directory /usr/local/llvm-devel/lib/.
I cannot find the directory where clang is installed. I am not sure where to make the bfd-plugins directory and add the symlinks to LLVMgold.so and libLTO.so.
I am using freebsd 10.1 release. How to enable the gold linker for link time optimizations?
also how can I enable it to be the default linker?
You may want to use ld.gold instead of ld. It is installed at /usr/local/bin/ld.gold. If you are using a Makefile, it would work by setting LD variable to ld.gold, either by modifying your Makefile or specifying it on command line. Example in case you are using lang/clang37:
gmake all CC=clang37 LD=ld.gold
EDIT:
It would be even more neat if you add -fuse-ld=gold to your LDFLAGS:
LDFLAGS=-fuse-ld=gold
I'm not sure ld.bfd allows plugins, but I could be wrong.
Your /usr/bin/ld should be a symlink to whatever linker you want. You can change which linker is used by using binutils-config. Check the man-page here: http://www.linuxhowtos.org/manpages/8/binutils-config.htm. I realise this is a Linux link, but it's directed at binutils itself rather than linux-specifically.
It should be something along the lines binutils-config --gold.
On my Gentoo box it is binutils --linker=gold
EDIT: As pointed out, binutils-config doesn't work on BSD it seems. You can still manually update the symlinks though, the downside is that there might be a few of them.
You can find out which ld is used by your compiler by using gcc -print-prog-name=ld or clang -print-prog-name=ld. The file printed should be a symlink you can re-create to point to ld.gold as oposed to ld.bfd.