I would like to cross-compile lmbench for ARM64, on a x86 machine. I have built my own cross-compiler according to the guide here: http://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/
When I tried cross-compiling lmbench3 with this cross-compiler I first had to:
remove all the lines where bk.ver was used in the src/Makefile
replace bk.ver by 3 at line 200 of the Makefile, so that I have:
sed -e "s/<version>/3/g" < ../scripts/lmbench > $O/lmbench
Set CC=aarch64-linux-gcc, OS=aarch64-linux-gnu, CFLAGS="$CFLAGS -static"
Put all the glibc-2.20/sunrpc/rpc header files into /opt/cross/aarch64-linux/include/rpc folder
Then when I type the make command I get the following error:
gmake[1]: Entering directory `/home/florian/lmbench3/src'
aarch64-linux-gcc -O -DRUSAGE -DHAVE_uint=1 -DHAVE_int64_t=1 -DHAVE_DRAND48 -DHAVE_SCHED_SETAFFINITY=1 -o ../bin/aarch64-linux-gnu/bw_tcp bw_tcp.c ../bin/aarch64-linux-gnu/lmbench.a -lm
../bin/aarch64-linux-gnu/lmbench.a(lib_tcp.o): In function `tcp_done':
lib_tcp.c:(.text+0x18): undefined reference to `pmap_unset'
../bin/aarch64-linux-gnu/lmbench.a(lib_tcp.o): In function `tcp_connect':
lib_tcp.c:(.text+0x338): undefined reference to `pmap_getport'
../bin/aarch64-linux-gnu/lmbench.a(lib_tcp.o): In function `tcp_server':
lib_tcp.c:(.text+0x568): undefined reference to `pmap_unset'
lib_tcp.c:(.text+0x584): undefined reference to `pmap_set'
collect2: error: ld returned 1 exit status
gmake[1]: *** [../bin/aarch64-linux-gnu/bw_tcp] Error 1
gmake[1]: Leaving directory `/home/florian/lmbench3/src'
make: *** [lmbench] Error 2
I know that pmap_set, pmap_unset and pmap_getport are called in lib_tcp.c, but I don't find anywhere their definitions. When I compile lmbench3 for x86 I don't get this error, and I checked everywhere on the host machine for the definition of these functions, but still don't find them anywhere.
Does anyone know what to do with this error? I guess I still need to use RPC, so I'd prefer not commenting any line.
From the error info, ld didn't find the lib, try following
make results LDFLAGS=-ltirpc
Related
I am new to Buildroot (using 2021.02.5 version on Ubuntu on a Virtual Machine) and trying to compile an OS for my ZedBorad (ARM processor) during my internship.
I followed the tutorial that was given to me to do so but I still can't get make to work without printing any error.... :(
I configured what I want that way :
Kernel > Linux Kernel disabled
Bootloader > U-Boot disabled
Toolchain > C library = glibc
Target Packages > python3, xml module, python-lxml and python-numpy all selected
Networking Applications > dhcpcd and dropbear selected
Right now, what is returned to me are errors due to undefined reference to ... :
More precisely, the end of my logs after running make is as follows :
/home/ouriacc/workspace/Buildroot/build-zb/host/lib/gcc/arm-buildroot-linux-gnueabihf/9.4.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: /home/ouriacc/workspace/Buildroot/build-zb/build/glibc-2.32-50-g737efa27fca5c97f566a2005687fda7d6659cd2e/build/elf/librtld.os: in function `fdopendir':
(.text+0x1a89c): undefined reference to `__GI___fxstat64'
/home/ouriacc/workspace/Buildroot/build-zb/host/lib/gcc/arm-buildroot-linux-gnueabihf/9.4.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: (.text+0x1a8c0): undefined reference to `__GI___fcntl64_nocancel'
/home/ouriacc/workspace/Buildroot/build-zb/host/lib/gcc/arm-buildroot-linux-gnueabihf/9.4.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: /home/ouriacc/workspace/Buildroot/build-zb/build/glibc-2.32-50-g737efa27fca5c97f566a2005687fda7d6659cd2e/build/elf/ld.so.new: hidden symbol `__getpid' isn't defined
/home/ouriacc/workspace/Buildroot/build-zb/host/lib/gcc/arm-buildroot-linux-gnueabihf/9.4.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:566 : /home/ouriacc/workspace/Buildroot/build-zb/build/glibc-2.32-50-g737efa27fca5c97f566a2005687fda7d6659cd2e/build/elf/ld.so] Erreur 1
make[3]: *** [Makefile:470 : elf/subdir_lib] Erreur 2
make[2]: *** [Makefile:9 : all] Erreur 2
make[1]: *** [package/pkg-generic.mk:250 : /home/ouriacc/workspace/Buildroot/build-zb/build/glibc-2.32-50-g737efa27fca5c97f566a2005687fda7d6659cd2e/.stamp_built] Erreur 2
make: *** [Makefile:23 : _all] Erreur 2
I read several threads on forums about this error but I still can't figure out exactly what I should do in my case. For what I understand, there is a problem with my ld.so library and I should add something to remove or fix this error in a Makefile but I don't know what to write, where to write it and even which Makefile I should edit (as there are at least 2)...
Does anybody has an answer or another solution to help me please ?
It seems that you use an external toolchain. Try to set LD_LIBRARY_PATH environment variable for your toolchain. For example:
export LD_LIBRARY_PATH="/opt/x86-64-core-i7--glibc--stable-2020.08-1/x86_64-buildroot-linux-gnu/lib64:$LD_LIBRARY_PATH"
in your case possible the following will be suitable:
export LD_LIBRARY_PATH="/home/ouriacc/workspace/Buildroot/build-zb/host/lib/gcc/arm-buildroot-linux-gnueabihf/9.4.0/../../../../arm-buildroot-linux-gnueabihf/lib64:$LD_LIBRARY_PATH"
You may do that in docker, if you use one or in the your shell environment.
I am attempting to run NPB benchmarking on my RHEL7.3 install but come into a similar issue as the question asked here
Error while building NAS benchmarks
Trying to make the BT benchmark, which is in fortran, I get the following error:
cd BT; make NPROCS=16 CLASS=W SUBTYPE= VERSION=
make[1]: Entering directory '/mnt/npb_install/NPB3.3-MPI/BT'
make[2]: Entering directory '/mnt/npb_install/NPB3.3-MPI/sys'
make[2]: Nothing to be done for 'all'
make[2]: Leaving directory '/mnt/npb_install/NPB3.3-MPI/sys'
../sys/setparams bt 16 W
make[2]: Entering directory '/mnt/npb_install/NPB3.3-MPI/BT'
make[3]: Entering directory '/mnt/npb_install/NPB3.3-MPI/BT'
gfortran -O -o ../bin/bt.W.16 bt.o make_set.o initialize.o exact_solution.o exact_rhs.o set_constants.o adi.o define.o copy_faces.o rhs.o solve_subs.o x_solve.o y_solve.o z_solve.o add.o error.o verifiy.o setup_mpi.o ../common/print_results.o ../common/timers.o btio.o -L/usr/lib/openmpi-x84_64/ -lmpi
/bin/ld: cannot find -lmpi
collect2: error: ld returned 1 exit status
make[3]: *** [bt-bt] Error 1
make[3]: Leaving direc.......
However I am not using Intel MPI but rather OpenMPI, though I don't full understand the implication of that.
My make.def file has the following mpi related settings
#-------------------------------------
# This is the fortran compiler usedd for MPI programs
#-----------------------------------------
MPIF77 = gfortran
# This links MPI fortran programs; usually the same as ${MPIF77}
FLINK = ${MPIF77}
#------------------------------------------
# These macros are passed to the linker to help link with MPI correctly
#-------------------------------------------
FMPI_LIB = -L/usr/lib/openmpi/lib/ -lmpi
#-----------------------------------------
# These macros are passed to the compiler to help find 'mpif.h'
#------------------------------------------
FMPI_INC = -I/usr/include/openmpi-x86_64/
Similar to those posted in the above question.
From the error, I assume that the input parameters -lmpi is not a valid input parameter for gfortran when compiling but removing it leads to a screen full of undefined references like:
file.f:(.text+0x123): undefined reference to 'mpi_whatever_'
Is it possible to compile NPB with gfortran? Or am I clearly doing something wrong here?
I have seen that using ifort is another option but I thought I'd ask the question before moving towards that possible solution
After hacking at it I resolved the issue with the following fixes, not sure what did it.
OpenMPI may have not been installed properly (was unable to call mpicc or other wrappers/comps), to fix it I ran the following commands
module avail
#displayed the openmpi-x86_64 module
module add open-x86_64
which mpirun
#displayed location of mpirun
The more likely fix was simply changing gfortran in the make.def file to mpif77
I've tired to maintenance the latest VIM/GVIM for windows, here is my OpenSource project.
However, I found the compile always failed by cygwin since the vim version higher than v7.4.399 (including v7.4.399).
Version less than v7.4.399 can be compiled with the same command successfully!
Failed Information:
obj/ex_docmd.o:ex_docmd.c:(.text+0x45f): undefined reference to `crypt_get_key'
obj/fileio.o:fileio.c:(.text+0xbb7): undefined reference to `crypt_works_inplace'
obj/fileio.o:fileio.c:(.text+0xbe6): undefined reference to `crypt_encode_alloc'
obj/fileio.o:fileio.c:(.text+0xd69): undefined reference to `crypt_encode_inplace'
obj/fileio.o:fileio.c:(.text+0x69e3): undefined reference to `crypt_free_state'
obj/fileio.o:fileio.c:(.text+0x6c66): undefined reference to `crypt_free_state'
obj/fileio.o:fileio.c:(.text+0x6c97): undefined reference to `crypt_free_key'
obj/fileio.o:fileio.c:(.text+0x716f): undefined reference to `crypt_get_method_nr'
obj/fileio.o:fileio.c:(.text+0x7177): undefined reference to `crypt_get_header_len'
obj/fileio.o:fileio.c:(.text+0x8e48): undefined reference to `crypt_works_inplace'
obj/fileio.o:fileio.c:(.text+0x8e73): undefined reference to `crypt_decode_inplace'
obj/fileio.o:fileio.c:(.text+0x906d): undefined reference to `crypt_method_nr_from_magic'
obj/fileio.o:fileio.c:(.text+0x9098): undefined reference to `crypt_set_cm_option'
obj/fileio.o:fileio.c:(.text+0x90c8): undefined reference to `crypt_create_from_header'
obj/fileio.o:fileio.c:(.text+0x90df): undefined reference to `crypt_set_cm_option'
obj/fileio.o:fileio.c:(.text+0x90e7): undefined reference to `crypt_get_header_len'
obj/fileio.o:fileio.c:(.text+0x9158): undefined reference to `crypt_decode_alloc'
obj/fileio.o:fileio.c:(.text+0x9e3f): undefined reference to `crypt_append_msg'
obj/fileio.o:fileio.c:(.text+0x9ed4): undefined reference to `crypt_get_method_nr'
obj/fileio.o:fileio.c:(.text+0x9edc): undefined reference to `crypt_get_header_len'
obj/fileio.o:fileio.c:(.text+0xa5bc): undefined reference to `crypt_get_key'
obj/fileio.o:fileio.c:(.text+0xca32): undefined reference to `crypt_free_state'
obj/fileio.o:fileio.c:(.text+0xdd15): undefined reference to `crypt_get_method_nr'
obj/fileio.o:fileio.c:(.text+0xdd37): undefined reference to `crypt_create_for_writing'
obj/fileio.o:fileio.c:(.text+0xe2d2): undefined reference to `crypt_append_msg'
/usr/lib/gcc/i686-pc-mingw32/4.7.3/../../../../i686-pc-mingw32/bin/ld: obj/fileio.o: bad reloc address 0x2e8 in section `.rdata'
/usr/lib/gcc/i686-pc-mingw32/4.7.3/../../../../i686-pc-mingw32/bin/ld: final link failed: Invalid operation
collect2: error: ld returned 1 exit status
Make_cyg.mak:603: recipe for target 'vim.exe' failed
make: *** [vim.exe] Error 1
The compile command:
make -B -f Make_cyg.mak PYTHON=/cygdrive/c/Marslo/MyProgramFiles/Python27 DYNAMIC_PYTHON=yes PYTHON_VER=27 PYTHON3=/cygdrive/c/Marslo/MyProgramFiles/Python34 DYNAMIC_PYTHON3=yes PYTHON3_VER=34 FEATURES=huge IME=yes GIME=yes MBYTE=yes CSCOPE=yes USERNAME=Marslo.Jiao USERDOMAIN=China GUI=no
I checked the difference between v7-4-398 and v7-4-399, and found there something updated with encryption. Then I added the libs and other stuff about crypt in cygwin as below, but the compile still CANNOT work....
What should I do can compile the higher version vim ?
Environments:
Cygwin version: Latest setup-x86_64.exe, mintty 1.2-beta1 (x86_64-pc-cygwin)
Have you tried compiling with all the patches that are currently available. I think Bram Moolenaar (Maintainer for vim) forgot to add some of the files in one of the patches and one of the later one fixes that. If not post to vim_dev#vim.org
This was also reported to at https://groups.google.com/forum/#!topic/vim_dev/D8FyRd0EwlE.
Patch 7.4.401 should fix it https://groups.google.com/forum/#!topic/vim_dev/q0dbl0_9k9U
Got this issue again on CentOS 7, Python 2.7.10, 64bit.
According to this answer, this issue has been fixed;
export vi_cv_path_python_plibs="-L/<python_config_path> ..."
For example in my situation:
export vi_cv_path_python_plibs="-L/usr/local/lib/python2.7/config ..."
Compile command:
$ ./configure --prefix=$HOME/.marslo/myprograms/vim74 --enable-pythoninterp --with-python-config-dir=/usr/local/lib/python2.7/config --with-features=huge --disable-smack --enable-cscope --with-tlib=ncurses --with-compiledby=marslo#china
$ cd src && make first
$ cd .. && make
$ make install
You can disable sodium library in ./configure such as :
./configure -disable-libsodium
Recently when I try to compile a large Fortran code, I met an error, which is in terms of hypre:
/ccs/home/phimar/opt/hypre//lib/libHYPRE.a(par_cr.o): In function `hypre_BoomerAMGCoarsenCR1':
par_cr.c:(.text+0x20e): undefined reference to `_simd_drand48_pd64x2'
/ccs/home/xialing/opt/hypre//lib/libHYPRE.a(par_cr.o): In function `cr':
par_cr.c:(.text+0xd4e): undefined reference to `_simd_drand48_pd64x2'
/usr/bin/ld: link errors found, deleting executable `/tmp/work/phimar/NGA_2way/bin/arts'
make[1]: *** [arts] Error 1
make[1]: Leaving directory `/autofs/na3_home1/phimar/NGA/src'
make: *** [default] Error 2
which seems to me that it has something to do with the compiler or the hypre src itself. So I tried to start from a clean version, unzip the hypre 2.6.0b zip file and then load the Intel compiler (with the newest version 13.1.3.192 on Titan). But I ended up with the same error.
Do offer your wisdom if this rings a bell. Really appreciate your help!
I am porting an application from Solaris to Linux
The object files which are linked do not have a main() defined. But compilation and linking is done properly in Solaris and executable is generated. In Linux I get this error
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
My problem is, I cannot include new .c/.o files since its a huge application and has been running for years. How can I get rid of this error?
Code extractes of makefile:
RPCAPPN = api
LINK = cc
$(RPCAPPN)_server: $(RPCAPIOBJ)
$(LINK) -g $(RPCAPIOBJ) -o $(RPCAPPN)_server $(IDALIBS) $(LIBS) $(ORALIBS) $(COMMONLIB) $(LIBAPI) $(CCLIB) $(THREADLIB) $(DBSERVERLIB) $(ENCLIB)
Try adding -nostartfiles to your linker options, i.e.
$(LINK) -nostartfiles -g ...
From the gcc documentation:
-nostartfiles
Do not use the standard system startup files when linking. The standard system libraries are used normally, unless -nostdlib or -nodefaultlibs is used.
This causes crt1.o not to be linked (it's normally linked by default) - normally only used when you implement your own _start code.
-shared link option must be used when you compile a .so
The issue for me was, I by mistake put int main() in a namespace. Make sure don't do that otherwise you will get this annoying link error.
Hope this helps anyone :)
I had similar result when trying to build a new test project with boost, and it turned out that I was missing one declaration :
#define BOOST_TEST_MODULE <yourtestName>
I had this same problem when creating my c project, and I forgot to save my main.c file, so there was no main function.
I had a similar result when compiling a Fortran program that had C++ components linked in. In my case, CMake failed to detect that Fortran should be used for the final linking. The messages returned by make then ended with
[100%] Linking CXX executable myprogram
/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
make[3]: *** [myprogram] Error 1
make[2]: *** [CMakeFiles/myprogram.dir/all] Error 2
make[1]: *** [CMakeFiles/myprogram.dir/rule] Error 2
make: *** [myprogram] Error 2
The solution was to add
set_target_properties(myprogram PROPERTIES LINKER_LANGUAGE Fortran)
to the CMakeLists.txt, so that make prints out:
[100%] Linking Fortran executable myprogram
[100%] Built target myprogram
I had the same issue with a large CMake project, after I moved some functions from one code file to another. I deleted the build folder, recreated it and rebuilt. Then it worked.
Generally, with suddenly appearing linker errors, try completely deleting your build folder and rebuilding first. That can save you the headaches from trying to hunt down an error that actually simply shouldn't be there: There might be CMake cache variables floating around that have the wrong values, or something was renamed and not deleted, ...
I had the same issue as to OP but on on FreeBSD 13.1.
What solved the issue was simply adding:
int main()
{
}
Since the .cpp file was only an object file containing definitions and declarations using:
extern "C"
{
<all definitions and declarations code goes here>
}
Every time I tried compiling this, the compiler kept throwing the same error as to OP.
So all I did was add an empty main() function all the way at the bottom and code compiled with no errors.