The following line generate the executable :
arm-none-eabi-ld -L/home/th/opt/arm-none-eabi/lib/ -L/home/th/opt/lib/gcc/arm-none-eabi/8.2.0/ -T /home/th/autoreverse/game/game.ld main.cpp.obj init.cpp.obj syscalls.cpp.obj queue.cpp.obj echange.cpp.obj echangeur.cpp.obj startup.s.obj -lstdc++ -lc -lgcc -o game.elf
...but replacing ld call by g++ call, do not do the job :
arm-none-eabi-g++ -L/home/th/opt/arm-none-eabi/lib/ -L/home/th/opt/lib/gcc/arm-none-eabi/8.2.0/ -T /home/th/autoreverse/game/game.ld main.cpp.obj init.cpp.obj syscalls.cpp.obj queue.cpp.obj echange.cpp.obj echangeur.cpp.obj startup.s.obj -lstdc++ -lc -lgcc -o game.elf
/home/th/opt/lib/gcc/arm-none-eabi/8.2.0/../../../../arm-none-eabi/bin/ld: main.cpp.obj: in function `std::__ioinit':
/home/th/autoreverse/game/main.cpp:43: multiple definition of `__dso_handle'; /home/th/opt/lib/gcc/arm-none-eabi/8.2.0/crtbegin.o:(.data+0x0): first defined here
/home/th/opt/lib/gcc/arm-none-eabi/8.2.0/../../../../arm-none-eabi/bin/ld: /home/th/opt/lib/gcc/arm-none-eabi/8.2.0/../../../../arm-none-eabi/lib/crt0.o: in function `_start':
/home/th/tools/newlib-cygwin-build/arm-none-eabi/libgloss/arm/semihv2m/../../../../../newlib-cygwin/libgloss/arm/crt0.S:430: undefined reference to `__bss_start__'
/home/th/opt/lib/gcc/arm-none-eabi/8.2.0/../../../../arm-none-eabi/bin/ld: /home/th/tools/newlib-cygwin-build/arm-none-eabi/libgloss/arm/semihv2m/../../../../../newlib-cygwin/libgloss/arm/crt0.S:430: undefined reference to `__bss_end__'
collect2: error: ld returned 1 exit status
What is going wrong ?
Problem solved.
Calling g++ with arguments "-v" print the complete g++ command. That's when I saw that g++ include some C runtime files : crtbegin, crti and crt0.
One of thoses files requests for bss_start' and bss_end'.
I don't need thoses files ! Remove theses with "-nostdlib" argument.
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 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.
I'm using Luarocks 2.2.0beta1 to install luafilesystem on windows 7 with lua 5.2 and mingw. I got this error:
>luarocks install luafilesystem
Installing http://rocks.moonscript.org/luafilesystem-1.6.2-2.src.rock...
Using http://rocks.moonscript.org/luafilesystem-1.6.2-2.src.rock... switching to 'build' mode
mingw32-gcc -O2 -c -o src/lfs.o -IC:/lua/include/src/lfs.c
mingw32-gcc -shared -o lfs.dll src/lfs.o C:/lua/bin/lua52.dll -lm
C:\lua\bin\lua52.dll: file not recognized: File format not recognized
collect2.exe: error: Id returned 1 exit status
Error: Build error: Failed compiling module lfs.dll
any idea how to fix this?
note: until now, I have no problem installing other module with luarocks that have no dependency with luafilesystem.
Solved, this problem arise because actually I'm not using the same MinGW compiler when building lua52.dll. I don't know which compiler I use at the first time. Thanks to #siffiejoe
I am adding some pthreads code into my Linux application that I'm building with autotools. I was getting an error about not linking in libpthreads. So I want to specify the pthreads dependency and compiler/linker flags in autotools.
I found some references that say use an ACX_PTHREAD macro. GNU provides an AX_PTHREAD macro. Both are very similar in concept. But I've tried both (on Ubuntu 13.04 64-bit), and found that they set -pthread in $PTHREAD_CFLAGS, but for some reason they don't set the -lpthread linker flag in $PTHREAD_LIBS.
The build fails. When I run make, I get:
...
/bin/sh ../libtool --tag=CXX --mode=link g++ -g -O2 -o myapp main.o ... -lconfuse -llog4cpp -lnsl -lpopt -lfuse -L/usr/local/lib -lrt
libtool: link: g++ -g -O2 -o .libs/myapp main.o ... -lconfuse -llog4cpp -lnsl /usr/lib/x86_64-linux-gnu/libpopt.so -lfuse -L/usr/local/lib -lrt
/usr/bin/ld: app-fuse.o: undefined reference to symbol 'pthread_kill##GLIBC_2.2.5'
/usr/bin/ld: note: 'pthread_kill##GLIBC_2.2.5' is defined in DSO /lib/x86_64-linux-gnu/libpthread.so.0 so try adding it to the linker command line
/lib/x86_64-linux-gnu/libpthread.so.0: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
...
In this case, the ./configure step shows:
...
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... yes
...
I notice it checks for -lpthreads, but shouldn't it be checking for -lpthread?
I've found that I can use:
AC_CHECK_LIB(pthread, pthread_create, [PTHREAD_LIBS+=-lpthread])
and then the build succeeds. But I assume this isn't the best way to make it work on the widest variety of platforms.
I see Ubuntu also has a package libpthread-stubs0-dev. But I'm not sure what it's for.
What is the "right way" to use pthreads with autotools?
Thanks to Peter Simons who asked on the autoconf mailing list, we have a somewhat official answer:
Compiler flags and linker flags are not mutually-exclusive sets, not
least because linking is typically done via the compiler frontend (cc)
and not by invoking the linker (ld) directly. Any flags that you can
use in the compile step (e.g. -O2, -DFOO, -I/tmp/include) will
generally be accepted in the linking step, even if it's not applicable
then. (The reverse may not be true, e.g. -lfoo.)
Given that, it's a lot less error-prone to use PTHREAD_CFLAGS (and
other CFLAGS variables) when linking, rather than duplicating the
applicable flags into PTHREAD_LIBS/LDFLAGS/etc. variables and not
using any CFLAGS variables then.
So just use PTHREAD_CFLAGS for your linker, too.
I bumped into this same issue when I added a first C++ source to an otherwise working C project (a shared library). Adding this C++ file caused libtool to switch from linking with gcc to linking with g++. Seems that linking with gcc a '-pthread' is enough to add the dynamic dependency to libpthread, but when linking with g++, it is not.
I tried with the above patch to a local ax_pthread.m4, but this didn't help. Passing '-lpthread' to g++ would fix the issue.
Edit: for some reason, ax_pthread.m4 forces C as the test language even if the AC_LANG is set as C++. This patch makes things work for me:
--- m4/ax_pthread.m4_orig 2013-06-15 20:03:36.000000000 +0300
+++ m4/ax_pthread.m4 2013-06-15 20:03:51.000000000 +0300
## -87,7 +87,6 ##
AU_ALIAS([ACX_PTHREAD], [AX_PTHREAD])
AC_DEFUN([AX_PTHREAD], [
AC_REQUIRE([AC_CANONICAL_HOST])
-AC_LANG_PUSH([C])
ax_pthread_ok=no
# We used to check for pthread.h first, but this fails if pthread.h
## -313,5 +312,4 ##
ax_pthread_ok=no
$2
fi
-AC_LANG_POP
])dnl AX_PTHREAD
It seems that the AX_PTHREAD macro is finding the -pthread compiler flag, and using that. But it looks as though for that particular flag, it should be specified to the linker as well (it apparently does the equivalent of -lpthread in the linker). I modified the macro as follows, so that the -pthread flag is specified as a linker flag too:
diff --git a/m4/ax_pthread.m4 b/m4/ax_pthread.m4
index 6d400ed..f426654 100644
--- a/m4/ax_pthread.m4
+++ b/m4/ax_pthread.m4
## -172,6 +172,12 ## for flag in $ax_pthread_flags; do
AC_MSG_CHECKING([whether pthreads work without any flags])
;;
+ -pthread)
+ AC_MSG_CHECKING([whether pthreads work with $flag])
+ PTHREAD_CFLAGS="$flag"
+ PTHREAD_LIBS="$flag"
+ ;;
+
-*)
AC_MSG_CHECKING([whether pthreads work with $flag])
PTHREAD_CFLAGS="$flag"
I guess I should submit this to the macro authors.
Expanding on a suggestion above (https://stackoverflow.com/a/20253318/221802) with exact script, this error went away for me after updating my PKbuild.sh script with pthread args:
./bootstrap && \
CPPFLAGS=" -g3 -Wall -pthread "\
CFLAGS=" -pthread -g3 -Wall "\
LDFLAGS=" -lpthread "\
./configure --enable-maintainer-mode \
--enable-debug \
--prefix=/usr \
--mandir=/usr/share/man \
--enable-pie \
--prefix=/usr \
--enable-library \
--enable-test \
......... [and so on]
I used the advice from another post: autoconf with -pthread
Here they mentioned you could download this file:
http://svn.sleuthkit.org/repos/sleuthkit/trunk/configure.ac
Place it into your m4 directory.
Then include this in your configure.ac:
ACX_PTHREAD
Finally, add this to your Makefile.am:
bin_PROGRAMS = main
main_SOURCES = main.c
main_CFLAGS = $(PTHREAD_CFLAGS)
main_LDADD = $(PTHREAD_LIBS)
After going through so much trouble, I was able to install VXL-1.14.0 and compiled opengazer http://www.inference.phy.cam.ac.uk/opengazer/. I followed its README and a very useful note by mirkrules http://www.mirkules.com/opengazer/vxl_install_notes.txt to modify Makefile of opengazer and relevant files (such as "PointTracker.h"). For example, in my Makefile, I changed the first few lines to be as follows (The vxl headers are in "/usr/local/include/vxl" and shared libraries are in "/usr/local/lib", which has "libvnl_algo.so" and "libvnl.so"):
VXLDIR = /usr/local
VERSION = opengazer-0.1.2
CPPFLAGS = -Wall -g -O3
LINKER = -L$(VXLDIR)/lib -L/usr/local/lib -lm -ldl -lvnl -lmvl -lvnl_algo -lvgl -lgthread-2.0
# change the following line if your vxl library is installed elsewhere
INCLUDES = $(foreach prefix,/usr/local/include $(VXLDIR)/include $(VXLDIR)/include/vxl, \
$(foreach suffix,/core /vcl /contrib/oxl /core/vnl/algo,-I$(prefix)$(suffix)))
===
Still, when I compile, I get error as below:
LeastSquares.o: In function `LeastSquares::solve()':
/home/mycomp/Downloads/opengazer-0.1.2/LeastSquares.cpp:27: undefined reference to `vnl_cholesky::vnl_cholesky(vnl_matrix<double> const&, vnl_cholesky::Operation)'
/home/mycomp/Downloads/opengazer-0.1.2/LeastSquares.cpp:27: undefined reference to `vnl_cholesky::solve(vnl_vector<double> const&) const'
LeastSquares.o: In function `~vnl_cholesky':
/usr/local/include/vxl/core/vnl/algo/vnl_cholesky.h:45: undefined reference to `vnl_vector<double>::~vnl_vector()'
/usr/local/include/vxl/core/vnl/algo/vnl_cholesky.h:45: undefined reference to `vnl_matrix<double>::~vnl_matrix()'
LeastSquares.o: In function `LeastSquares::solve(double&, double&, double&)':
/home/mycomp/Downloads/opengazer-0.1.2/LeastSquares.cpp:39: undefined reference to `vnl_vector<double>::~vnl_vector()'
LeastSquares.o: In function `~vnl_cholesky':
/usr/local/include/vxl/core/vnl/algo/vnl_cholesky.h:45: undefined reference to `vnl_matrix<double>::~vnl_matrix()'
/usr/local/include/vxl/core/vnl/algo/vnl_cholesky.h:45: undefined reference to `vnl_vector<double>::~vnl_vector()'
/usr/local/include/vxl/core/vnl/algo/vnl_cholesky.h:45: undefined reference to `vnl_matrix<double>::~vnl_matrix()'
/usr/local/include/vxl/core/vnl/algo/vnl_cholesky.h:45: undefined reference to `vnl_matrix<double>::~vnl_matrix()'
collect2: ld returned 1 exit status
make: *** [opengazer] Error 1
Could anyone who is familiar with either VXL, Opengazer or compiling C libraries in general tell me what possibly is going on here? Thank you.
Using an older version of gcc seems to solve the problem:
sudo apt-get install g++-4.4
Then change the lines in Makefile that contains g++ to g++-4.4.
Refer to install notes if you get the ambiguous exception problem afterward.