I successfully ran sudo apt-get install libncurses5-dev
Within my Eclipse window I then try to build the following HelloWord.cpp program:
#include <ncurses.h>
int main()
{
initscr(); /* Start curses mode */
printw("Hello World !!!"); /* Print Hello World */
refresh(); /* Print it on to the real screen */
getch(); /* Wait for user input */
endwin(); /* End curses mode */
return 0;
}
I get the following error:
Invoking: GCC C++ Linker
g++ -m32 -lncurses -L/opt/lib -o "Test_V" ./src/curseTest.o ./src/trajectory.o ./src/xJus-epos.o -lEposCmd
/usr/bin/ld: cannot find -lncurses
collect2: error: ld returned 1 exit status
make: *** [Test_V] Error 1
It looks like the compiler is searching for the ncurses library and can't find it? I checked /usr/lib and the library does not exist there so do I need to manually link the ncurses library there - I thought the get-apt installer would automatically do this?
g++ HelloWorld.cpp -lncurses -o HelloWolrd
If you have a 32-bit machine, gcc compile m32 auto. If you have a 64-bit machine and you want to compile 32bits you
Your arguments are not in the correct order. You must specify all source files first and then linker search directories before specifying the libraries to link with. Your command should be like this:
g++ HelloWorld.o -L/opt/lib -lncurses -o HelloWorld
Taken from comment by #ChrisDodd:
Your options are in the wrong order -- -L must be BEFORE -l and both must be after all .o
Related
I am trying to compile the mosquitto library with my custom c program. So WHat I have done is wrote a hello.c file, git cloned the latest mosquitto library from the below repository:
https://github.com/eclipse/mosquitto.git
and compiled it with the make command as below:
make
I had to remove the doc target as it was asking for some dependancy library. I don't have admin rights on this machine, hence don't want to be blocked by any dependancy lib. After the compilation what I have is the below:
src/mosquitto
./lib/libmosquitto.so.1
The I copied the libmosquitto.so.1 shared lib into a local folder called ~/hello/:
~/hello$ cp ~/mosquitto/lib/libmosquitto.so.1 .
then wrote a hello.c inside ~/hello/ which is as below:
#include <stdio.h>
int main()
{
printf("Hello World\n");
return 0;
}
I can compile the hello.c and run it as below:
gcc -o hello hello.c
./hello
Hello World
But if I try to link the binary with the mosquitto library I get an error like the below:
gcc -o hello hello.c -lmosquitto
/usr/bin/ld: cannot find -lmosquitto
collect2: error: ld returned 1 exit status
The libmosquitto.so.1 lives in the same folder as the hello.c. I don't want to install the mosquitto library, rather would like to keep in a local folder and be able to link it. I have also tried the below with the hope that the -L. would point the linker to the present directory for the shared lib file but still get the same error:
gcc -o hello hello.c -L. -lmosquitto
/usr/bin/ld: cannot find -lmosquitto
collect2: error: ld returned 1 exit status
My ultimate objective is to cross compile the library for an arm target. So really need to understand how the linking of the shared library is failing so that I can use the same experience while cross compiling and link for the target. At the moment I am doing this on a x86 platform.
Can anyone please help?
/usr/bin/ld: cannot find -lmosquitto
The linker doesn't look for libmosquitto.so.1 -- it only looks for libmosquitto.a or libmosquitto.so.
Solution: ln -s libmosquitto.so.1 libmosquitto.so
./pub: error while loading shared libraries: libmosquitto.so.1: cannot open shared object file: No such file or directory
The problem here is that the runtime loader doesn't look in the current directory for libmosquitto.so.1 -- it only looks in system-configured directories.
You could fix this by adding export LD_LIBRARY_PATH=$HOME/mosquitto/lib, but this is suboptimal -- your binary will work or not depending on the environment.
A better solution is to change your link command like so:
gcc -o hello hello.c -L. -lmosquitto -Wl,-rpath=$HOME/mosquitto/lib
I would like to debug shared library in Visual C++ Linux Development. Debugging executable file works well, but the breakpoint does not hit for shared library. How can I fix up?
Attached file is visual studio solution including .c and Makefile.
Example is very simple.
open shared library
read pointer of function in shared library
call the function.
Program works well. But Debugging shared library does not works. The breakpoint in main.c hits but the breakpoint in com.c does NOT hit.
/* main.c */
#include <stdio.h>
#include <dlfcn.h>
int main(int argc, char** argv)
{
void* dl_handle;
dl_handle = dlopen("../so/libcom.so.1", RTLD_LAZY);
if (!dl_handle) {
printf(" error : %s \n", dlerror());
return 0;
}
printf(" now call minicommon.h's function.. that is < void print_n(int n) >...\n");
void(*pFunc)(int);
pFunc = dlsym(dl_handle, "print_n");
(*pFunc)(18);
return 0;
}
/* com.c */
#include <stdio.h>
void print_n(int a)
{
printf("SO - print: [%d]\n", a);
}
/* Makefile for main.c */
all: main
main: main.o
gcc -W -Wall -gdwarf-2 -o main ../so/libcom.so.1 main.o -ldl
main.o: main.c
gcc -Wall -c -gdwarf-2 -o main.o main.c
clean:
rm -rf *.o main
/* Makefile for com.c */
all: libcom.so.1
libcom.so.1: com.o
gcc -shared -gdwarf-2 -o libcom.so.1 com.o
com.o: com.c
gcc -Wall -c -gdwarf-2 -o com.o com.c -fPIC
clean:
rm -rf *.o libcom.so.1
Before shared library is opened, can I debug it?
Environment
- Window 10
- CentOS 7 in VirtualBox
- Visual Studio 2015 update 3
- Visual C++ for linux Development 1.0.7
To be able to debug any binary (which includes shared libraries) you need the debugging symbols being available, either compiled into the binary itself, or as a separate file.
In most Linux distributions you can install the debugging symbols as separate package; Ubuntu for instance names these packages <packagename>-dbg. Check if these are available in your development environment, too.
I was trying this on my 64 bit ubuntu:
First I've got a simple program
$ cat test.c
int f(int x){
int i=(x/42);
return i;
}
int main(){
return 0;
}
Then I manually specify how it's linked:
$ gcc test.c -nostdlib /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o /usr/lib/x86_64-linux-gnu/crtn.o
I got some errors:
/usr/lib/x86_64-linux-gnu/crt1.o：In function ‘_start’中：
(.text+0x12)：unresolved reference to ‘__libc_csu_fini’
/usr/lib/x86_64-linux-gnu/crt1.o：In function ‘_start’：
(.text+0x19)： unresolved reference to ‘__libc_csu_init’
/usr/lib/x86_64-linux-gnu/crt1.o：In function ‘_start’：
(.text+0x25)： unresolved reference to ‘__libc_start_main’
collect2: error: ld returned 1 exit status
I was trying to see how gcc deals with all necessary object files and try to do it manually. How to fix it? Thanks.
How to fix it?
You are missing libc symbols, so you need to link libc:
gcc test.c -nostdlib /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o /usr/lib/x86_64-linux-gnu/crtn.o -lc
Bear in mind that if you really want to link something "manually", you will do it with ld, not gcc
I'm trying to get a "Hello World" application compiled for an ARM target. I'm cross compiling using gcc on Ubuntu/VMWare. If I compile for the host machine, it works fine. When I compile for the target, I get this error:
/root/picokernel/toolchain/arm-eabi/lib/libcs3hosted.a(hosted-sbrk.o): In function `_sbrk':
sbrk.c:(.text+0x74): undefined reference to `__cs3_heap_limit'
/root/picokernel/toolchain/arm-eabi/lib/libcs3hosted.a(hosted-sbrk.o):(.data+0x0): undefined reference to `__cs3_heap_start'
make: *** [HelloWorld] Error 1
So I think I need to link something in - perhaps my toolchain does not have the right libs? I was able to build the kernel, so I thought it was complete. Thanks! This is the target board. - runs Angstrom or Android.
makefile:
CC=$(CROSS_COMPILE)gcc
LD=$(CROSS_COMPILE)ld
CROSS_LIB1=/root/picokernel/toolchain/arm-eabi/lib
CROSS_LIB2=/root/picokernel/toolchain/lib/gcc/arm-eabi/4.2.1
CFLAGS=-Wall
LDFLAGS= -L$(CROSS_LIB1) -L$(CROSS_LIB2) -lc -lcs3hosted -lg -lgcc --entry main
HelloWorld: HelloWorld.o
$(LD) HelloWorld.o $(LDFLAGS)
clean:
rm -f HelloWorld HelloWorld.o
program:
#include <stdio.h>
int main(int argc, char **argv)
{
printf("Hello World\n");
return 0;
}
I gotta say, this is suspicious: -nostdlib
How about not using this flag?
The kernel does not use the C runtime library since the library does many—if not most—things not permitted by kernel code like file i/o and allocating memory.
Normally, you don't have to specify a library at all. gcc assumes the right thing. Try removing setting LDFLAGS altogether: I bet it works better.
Ok - finally worked this out, picked up a toolchain from the source here:
http://www.codesourcery.com/sgpp/lite/arm/portal/release1803
Hello World works great! Thanks for the suggestions
Does the toolchain you are using have a library called "lcs3arm" ? If so, try adding that to the list. You can also try "-lcs3" itself
Out of interest, which version of GCC are you using here? (i.e. which CodeSourcery release)
WHen I compile this code, it shows me linker error
#include <curses.h>
#include <ncurses.h>
int main()
{ int ch;
raw(); /* Line buffering disabled */
}
Compiler error:
/tmp/ccY9Bug1.o: In function `main':
raw.c:(.text+0x12): undefined reference to `raw'
collect2: ld returned 1 exit status
I have checked that curses.h anf ncurses.h exists in /usr/include directory and there is even man page for raw on my linux system.
Please tell me how to correct this error.
Pass "-lcurses" or "-lncurses" or something like that to the linker.
gcc foo.c -lcurses
works for me.
You need to link with curses or ncurses library:
gcc yourcode.c -lcurses -lncurses