how are you?. I have a big problem (or at least I don't know how to solve it) with Geany, using Debian jessie in a nanopi M1.
The history is like follows:
I'm trying to run some modified demo code that came with the nanopi M1 to control the GPIO ports, so, when I was tring to "Build" the program after compiled, it shows the following errors:
In the function main it says:
/tmp/ccwWOISx.o in function 'main'
...... undefined reference to 'boardinit'
...... undefined reference to 'pintoGPIO'
...... undefined reference to 'openHW'
...... undefined reference to 'selectHW'
...... undefined reference to 'readHW'
...... undefined reference to 'closeHW'
......
......
and about two or tree more errors of the same type "undefined reference" all
related a functions of the hardware
I'm using gcc, the commands came precharged in geany and are:
Compile:
gcc -Wall -c "%f"
Build:
gcc -Wall -o "%f" "%e"
so I think (if I've understood what I readed in other posts in stackoverflow) that is a linking error but don't know how to solve it.
after that, I've modified the Build command to this:
gcc -Wall -c -o "%f" "%e"
this made to not to have errors but the file generated is now of the type "object code" (this is wrong) because I need "executable" files (without extension) and terminal give the following message:
bash: ./Matrix-ir_receiver: cannot execute binary file: Exec format error
I don't have any idea of how to solve this, please help!
As I said, it was a linker problem, I needed to use the -lfahw and -lm options to build the executable. The first options one is specific for the ARM device, I think; after that the program runs flawlessly.
Related
I'm sucessfully building pulp-riscv-gnu-toolchain from this this
But when I try to compile my simple source code with builded compiler,
error occured.
My command is riscv32-unknown-elf-g++ -o hello hello.cpp
Error message is /home/jskim/test_toolchains_lib/gcc/riscv32-unknown-elf/7.1.1/../../../../riscv32-unknown-elf/bin/ld : cannot open linker script file riscv.ld : No such file or directory
So I try with this command riscv32-unknown-elf-g++ -o main main.cpp -T /home/jskim/test_toolchains/riscv32-unknown-elf-ld/lib/ldscripts/elf32lriscv.x
But following error occured : /home/jskim/test_toolchains/lib/gcc/riscv32-unknown-elf/7.1.1/../../../../riscv32-unknown-elf/lib/crt0.o: In function '.L0': (.text+0x10):undefined reference to '_fbss' collect2: error: ld returned 1 exit status
I'm using CentOS 7.6 and I try build this pulp-gcc with gcc 4.8.5 and 7.3.1 but both shows me same error. Please help me.
I resolve the problem in this way.
Actually Here is the solution.
I'm not accurate but I think the problem is that the name is not matched.
crt0, which seems to be the helper of start riscv processor has this line la a0 _fbss just basically linker can recognize this if _fbss is replaced with _edata. So i edit the assembly file which is located at pulp-riscv-gnu-toolchain/riscv-newlib/libgloss/riscv/ And rebuild the gnu toolchain. And execute your compiler with -T option like riscv32-unknown-elf-g++ -o main main.cpp -T /home/jskim/test_toolchains/riscv32-unknown-elf-ld/lib/ldscripts/elf32lriscv.x
This is the easiest solution as I think.
I'm using ubuntu 14.04 and i'm trying to install the UHD device from the github but i'm getting an error that won't allow it to build.
checking whether the Boost::System library is available... yes
checking for exit in -lboost_system... yes
checking whether the Boost::Thread library is available... yes
checking for exit in -lboost_thread... yes
checking whether the Boost::Regex library is available... yes
checking for exit in -lboost_regex... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: executing depfiles commands
willie.thompson#seb215-wks07:~/redhawk/USRP_UHD/cpp$ make
CXX USRP_UHD-USRP_UHD.o
CXX USRP_UHD-USRP_UHD_base.o
CXX USRP_UHD-main.o
CXX USRP_UHD-template_impl.o
CXXLD USRP_UHD
/usr/bin/ld: USRP_UHD-USRP_UHD.o: undefined reference to symbol 'uuid_generate_random##UUID_1.0'
//lib/x86_64-linux-gnu/libuuid.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [USRP_UHD] Error 1
seb215-wks07:~/redhawk/USRP_UHD/cpp$
Am I doing something wrong here or is the issue with Ubuntu?
For now, you can edit the Makefile.am file to fix this. At the end of the USRP_UHD_LDADD line, add -luuid, then you should be able to rebuild it successfully.
The version of g++ used in Ubuntu14 is stricter than the version used in CentOS6. Luckily, g++ is providing a good hint about what the issue is.
/usr/bin/ld: USRP_UHD-USRP_UHD.o: undefined reference to symbol 'uuid_generate_random##UUID_1.0'
//lib/x86_64-linux-gnu/libuuid.so.1: error adding symbols: DSO missing from command line
It is basically saying "What you want is here in libuuid.so.1 but you didn't put it on the command line so I'm refusing to use it". While in CentOS6 g++ is less strict and links regardless, assuming that is what you wanted.
You have two options, one is the easy way out that works quick, one is a better long term solution:
1) Run make again in verbose mode, this will show you exactly what calls are being made and you can fix the offending call. Lets do that below:
make V=1
< ... a bunch of calls to g++ that work fine or nothing if these have already run prior .... >
g++ -Wall -D__x86_64__ -D__linux__ -D__OSVERSION__=2 -DENABLE_EVENTS=1 -I/var/lib/redhawk/core/include -I/var/lib/redhawk/core/include/ossie -I/var/lib/redhawk/core/share/idl -pthread -I/usr/include -I/var/lib/redhawk/core/include/frontend -I/var/lib/redhawk/core/include/redhawk -I/var/lib/redhawk/core/include/bulkio -I/var/lib/redhawk/core/include/ossie -g -O2 -Wall -o USRP_UHD USRP_UHD-USRP_UHD.o USRP_UHD-USRP_UHD_base.o USRP_UHD-main.o USRP_UHD-template_impl.o -L/var/lib/redhawk/core/lib64 -lossiecf -lossieidl -lCOS4 -lomniDynamic4 -lomniORB4 -lomnithread -L/usr/lib/x86_64-linux-gnu -lboost_thread -lboost_regex -lboost_system -L/var/lib/redhawk/core/lib64 -lfrontend-2.2.0 -lfrontendInterfaces -lbulkio-1.10 -lbulkioInterfaces -luhd -llog4cxx
/usr/bin/ld: USRP_UHD-USRP_UHD.o: undefined reference to symbol 'uuid_generate_random##UUID_1.0'
//lib/x86_64-linux-gnu/libuuid.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [USRP_UHD] Error 1
Okay, so now we have the long ugly g++ call, we simply need to add "-luuid" to the list of linked libraries so we can tack that on at the end and voila! It will return without error. Note that we simply hand ran 1 of the g++ calls so for good measure run Make again in case there are any additional build steps; in this case there are not, it will simply say "nothing to be done"
2) A better fix! So the build files clearly need some fixing.
If we take a look at the configure.ac we see that there are calls like this one:
PKG_CHECK_MODULES([LIBUHD], [uhd >= 3.5.3])
What this is doing is saying "Check pkg-config for the module uhd, ensure it is of version >= 3.5.3 and store any build related info in a variables prefixed with LIBUHD so that I can use it later". Sounds like what we want. We can check to see if pkg-config is aware of libuuid by viewing all of the packages it knows about:
pkg-config --list-all
That will show us everything pkg-config knows about and we see that it is aware of uuid. So, lets add a line to configure.ac right below the check for the UHD driver and see what affect that has. My line looks like this:
PKG_CHECK_MODULES([LIBUUID], [uuid])
I put no version constraint. Okay, so now in order for that change to be incorporated we need to rerun the reconf script and then we can see the configure output.
./reconf
./configure
<....a bunch of stuff....>
checking for LIBUUID... yes
<....a bunch more stuff....>
That's new! We are now checking for the uuid library in our configure call and if you take a look at the config.log file, new variables have been added:
LIBUUID_CFLAGS='-I/usr/include/uuid '
LIBUUID_LIBS='-luuid '
Alright, almost there! Take a look at the Makefile.am file. These variables are used there and dictate the calls to g++. Append our newly made LIBUUID_CFLAGS and LIBUUID_LIBS variables to the end of the USRP_UHD_LDADD and USRP_UHD_CXXFLAGS variables like I've done below.
USRP_UHD_LDADD = $(PROJECTDEPS_LIBS) $(BOOST_LDFLAGS) $(BOOST_THREAD_LIB) $(BOOST_REGEX_LIB) $(BOOST_SYSTEM_LIB) $(INTERFACEDEPS_LIBS) $(redhawk_LDADD_auto) $(LIBUHD_LIBS) $(LIBUUID_LIBS)
USRP_UHD_CXXFLAGS = -Wall $(PROJECTDEPS_CFLAGS) $(BOOST_CPPFLAGS) $(INTERFACEDEPS_CFLAGS) $(redhawk_INCLUDES_auto) $(LIBUHD_FLAGS) $(LIBUUID_CFLAGS)
Since we've changed the Makefile.am files, we need to rerun ./configure. Rule of thumb is that ./reconf creates your configure script from the configure.* files and ./configure creates the Makefile's from your Makefile.* files so if you edit a downstream file you need to rerun the upstream script.
Alright, now that we've done that things should work! We've added a system check for libuuid via pkg-config using the configure.ac file, stored the outcome in a variable and used that in our makefile template.
None of this is really unique to redhawk so if you'd like more information there is loads of documentation on the autotools build system and pkg-config.
I am trying to compile a Hello World for ARM-1136J-S processor. When I compile the C source using CodeSourcery arm-none-linux-gnueabi-gcc (2008q3 edition), it executes successfully on the ARM, but when I compile same code using arm-linux-gnueabi-gcc (installed through apt-get in Ubuntu 12.01) it gives the following error:
./helloworld: line 1: syntax error: unexpected word (expecting ")")
readelf of both the executables show that the binary compiled using Ubuntu toolchain has following extra attributes:
Tag_CPU_unaligned_access: v6
Tag_DIV_use: Not allowed
How can I make it run using Ubuntu toolchain? Can anyone give some hint on that? Thanks
./helloworld: line 1: syntax error: unexpected word (expecting ")")
This doesn't look like a native code error at all - it looks like a script error. Are you sure "helloworld" is actually your compiled binary. Running compiled C code binaries does not give syntax errors ...
Check that your kernel has support for THUMB binaries:
zcat /proc/config.gz |grep THUMB
Try running 'readelf' on your executable. If the entry point address is an odd number (indicating THUMB or mixed ARM/Thumb) and your kernel lacks THUMB executable support, your binary will be rejected by the kernel, and will be attempted to be run as a shell script.
I had the same problem. The problem went away by adding "-static" to link:
arm-linux-gnueabi-gcc -c test.c -o test.o
arm-linux-gnueabi-g++ -o test test.o -static
If your code use "gethostbyname" you will get
warning: Using 'gethostbyname' in statically linked..
but that is another subject and not easily solved.
Everybody out there,
I'm writing a c code which have a strange problem when I compile it .
The source code is OK.
I compile it with following option:
$ gcc above_sample.c -I/home/hadoop/project/hadoop-0.20.2/src/c++/libhdfs -L/home/hadoop/project/hadoop-0.20.2/c++/Linux-amd64-64/lib -lhdfs -o above_sample.
But it show the out put like that:
/usr/bin/ld: warning: libjvm.so, needed by /home/hadoop/project/hadoop-0.20.2/c++/Linux-amd64-64/lib/libhdfs.so, not found (try using -rpath or -rpath-link) /home/hadoop/project/hadoop-0.20.2/c++/Linux-amd64-64/lib/libhdfs.so: undefined reference to `JNI_CreateJavaVM#SUNWprivate_1.1'
/home/hadoop/project/hadoop-0.20.2/c++/Linux-amd64-64/lib/libhdfs.so: undefined reference to `JNI_GetCreatedJavaVMs#SUNWprivate_1.1'
collect2: ld returned 1 exit status
I searched for libjvm.so i found It in my system in /usr/java/lib.
I made a symbolic link of it but did not work.
i copied the library in to several places like usr/lib check the LD_library_Path
but could not manage to compile the program it showing the same error again and again
Can any one tell me what I'm doing wrong ?
how to link .so file to gcc ?
or how .so files are linked in program?
Try adding:
-L/usr/java/lib
To your linker command, since that's the library your linker is not being able to find: I_GetCreatedJavaVMs#SUNWprivate_1.1.
A little piece of advice: it's not a good idea to mess with LD_LIBRARY_PATH. Just fix your linker command.
Linker gives a warning about not found reference to function JNI_CreateJavaVM#SUNWprivate_1.1
/usr/bin/ld: warning: libhdfs.so: undefined reference to
`JNI_CreateJavaVM#SUNWprivate_1.1'
This function name might be specific for library from Sun/Oracle HotSpot JVM. Other JVMs may have another name. For example, mine OpenJDK had only shorter name such as JNI_CreateJavaVM and linker gave me the same warning.
You may get list of the functions from your libjvm.so by running command:
readelf -s libjvm.so | grep JNI_CreateJavaVM # given that you are in catalog containing libjvm.so
If output does not contain required function, then you might want to install another JDK.
That's what worked for me:
CDH=/opt/cloudera/parcels/CDH
OS_ARCH=amd64
gcc hdfs_example.c -I$CDH/include -L$CDH/lib64 \
-L/usr/java/default/jre/lib/${OS_ARCH}/server \
-ljvm -lhdfs -o hdfs_write_test
I am attempting to install an application. During compilation it fails with the following error:
/usr/bin/ld: cannot find -lemu
I have installed the libemu library, and it now currently resides in /opt/libemu/. However, when I try and compile my application the library is not found. Is there any way to correct this?
EDIT: It also looks like the make is resulting in:
It also looks like the make file is compiling with the following:
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
build/temp.linux-x86_64-2.6/libemu_module.o
-L/opt/libemu/lib -lemu -o build/lib.linux-x86_64-2.6/libemu.so
I have tried setting my LD_LIBRARY_PATH to /opt/libemu, still doesn't work - fails with the error mentioned above.
You need to tell the linker where it is:
gcc stuff -L/opt/libemu -lemu
or:
gcc stuff /opt/libemu/libemu.a
where stuff is your normal compile/link options files etc.
You can also specify library paths in the LIBRARY_PATH environment variable:
LIBRARY_PATH=/opt/libemu
export LIBRARY_PATH
before you run your build. Yet another option is to see where gcc looks for libraries by running:
gcc --print-search-dirs
and put your library in one of the listed directories.
Edit: It is really not clear from your latest info what you are trying to build. Are you trying to turn a static library into a shared library? Most important - What is the exact filename of the library file you have copied into the /opt/libemu directory?
The environment variable LD_LIBRARY_PATH should include (but probably does not by default) /opt/libemu.
try running:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/libemu
make install