gcc dialog library not linking - dialog

I'm trying to develop a small utility using the dialog library in C (the dialog command in linux).
On fedora linux works fine, but if i try to compile it on debian with the command:
gcc -ldialog -lncurses -I/usr/include dialog_test.c
I get the following error:
vetinari#ankhmorpork:~/Projects/Other/test$ gcc -ldialog -I/usr/include dialog_test.c
/usr/bin/ld: /tmp/ccX6fPYB.o: warning: relocation against `dialog_vars' in read-only section `.text'
/usr/bin/ld: /tmp/ccX6fPYB.o: in function `main':
dialog_test.c:(.text+0x5c): undefined reference to `init_dialog'
/usr/bin/ld: dialog_test.c:(.text+0x79): undefined reference to `dialog_yesno'
/usr/bin/ld: dialog_test.c:(.text+0xae): undefined reference to `dialog_menu'
/usr/bin/ld: dialog_test.c:(.text+0xbc): undefined reference to `dialog_vars'
/usr/bin/ld: dialog_test.c:(.text+0xc5): undefined reference to `end_dialog'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE
collect2: error: ld returned 1 exit status
The dialog command works fine.
Anyone has any idea why it isn't working on debian?

(Answer for the wiki sake, in case someone comes by here later)
You have to put the libraries you want to link at the end of the gcc command, like this:
gcc dialog_test.c -ldialog -lncurses
The reason is explained here: The way the linker looks up symbols it has to first see the reference, and then the library prodiving the symbol
Additionally, the dialog library might have other dependencies than ncurses. There is explanation how to find out what to include and what to link here, in short: dialog-config should tell you about it.
In this specific case, what worked for me (ubuntu 20.04) was linking ncursesw instead of ncurses.
After that, I was left with an
undefined reference to `sqrt'
linker error, which can be solved by linking the match library using -lm.
So, in total, this command works:
gcc dialog_test.c -ldialog -lncursesw -lm

Related

Question about compiling sources code with HDF5 and mpi

When I am trying to compile the source code by 'make', the first steps that creating the '.o' files are running fine, and all '.o' files could be compiled normally. However, when compiling the executable file:
mpifort -fopenmp -O3 -o MyEXE sth.o main.o -L/usr/local/share/fftw-3.3.8/lib -lfftw3_mpi -lfftw3 -lm -L/usr/local/share/mpich-3.2/lib -lmpi -lz -L/usr/local/share/hdf5-1.8.18/lib -lhdf5_fortran -lhdf5hl_fortran -lhdf5_hl -lhdf5 -fPIC
it gots the following error:
/usr/bin/ld: /usr/local/share/hdf5-1.8.18/lib/libhdf5.a(H5PL.o): undefined reference to symbol 'dlclose##GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libdl.so.2: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
How could I solve this problem? Some pages suggest that it is due to the '-ldl- flag when calling c++ compiler, but I couldn't find a way to make it suitable for my cases.
The pages were right. Your HDF5 library libhdf5.a uses the function dlclose, which is defined in the library libdl. To use it, you need to simply add -ldl at the end of your mpifort command line.

Linker is unable to locate curl_global_init

I am compiling a C++ application on Ubuntu 18.04.
The linker is unable to pickup the required functions from the library or it is not locating the right library
I have libcurl.so located at /usr/local/lib
nm -D lists all the functions I need with T prefix. Yet when I compile as follows
g++ -std=c++17 -lcurl tz.o main.o
I get
/usr/bin/ld: tz.o: in function 'date::curl_global()':
tz.cpp:(.text+0x9aef): undefined reference to 'curl_global_init'
I tried installing openssl-dev. No joy. So I uninstalled it.
try
g++ -std=c++17 tz.o main.o -lcurl
instead... g++ is shit in some ways, like argument ordering. (all i did was to make -lcurl the last argument instead of argument #3)

(g++ 4.8.2) Why do I need to specify -pthread to link sem_post?

In g++ 4.8.2 apparently one has to specify -pthread flag to include the reference to sem_post.
/usr/bin/ld: obj/loader.o: undefined reference to symbol 'sem_post##GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
Why is that? What if one wants to explicitly not have to link that library to ensure no threads are ever run?
Has anything changed?
Thanks!

linux linker: '-lpng' inhibits '-lz'?

On ubuntu-13.04, I got an error when building an executable from shared libraries, using GCC-4.7.3 provided by the linux distribution.
I guess the problem is between libpng and zlib (the former uses the latter), but I don't know why.
First, my command is:
$ gfortran -o test_muesli_config_fml test_muesli_config_fml.o -fopenmp
-Wl,--rpath,/usr/local/lib/muesli /usr/local/lib/muesli/libfml.so -lstdc++
-Wl,--rpath,/usr/lib /usr/lib/liblapack.so -Wl,--rpath,/usr/lib /usr/lib/libblas.so
-lpng -lz -lpthread -lreadline -lhistory
which gives the following error:
/usr/local/lib/muesli/libfml.so: undefined reference to `gzwrite'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzopen'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzclose'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzread'
collect2: error: ld returned 1 exit status
But note that -lz is present. After that, I added the linker option --trace-symbol= in order to get more information:
$ gfortran -o test_muesli_config_fml test_muesli_config_fml.o -fopenmp
-Wl,--rpath,/usr/local/lib/muesli /usr/local/lib/muesli/libfml.so -lstdc++
-Wl,--rpath,/usr/lib /usr/lib/liblapack.so -Wl,--rpath,/usr/lib /usr/lib/libblas.so
-lpng -lz -lpthread -lreadline -lhistory -Wl,--trace-symbol=gzwrite
which in turn gives the results:
/usr/local/lib/muesli/libfml.so: reference to gzwrite
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libz.so: definition of gzwrite
/usr/local/lib/muesli/libfml.so: undefined reference to `gzwrite'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzopen'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzclose'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzread'
collect2: error: ld returned 1 exit status
so, gzwrite is found in libz.so but the linker don't use it!
By chance, I thought to remove the -lpng option (actually, the libpng library is not used) and my problem is solved! Why?
Secondly, I compile my whole code with another version of GCC-4.7.3 (compiled by myself -- I am used to test many versions of the compiler), and the error didn't occur, even using both -lpng and -lz!
Any idea?
In addition, a different try with another program (which USE libpng) leads to a successful build.
Edited on 2013-10-08
I'm pretty sure now that it is a bug in ubuntu-13.04: I've tried two other linux distros (Fedora 16 -- Ubuntu-10.04) and the linker behavior is standard, not as described above in the first part of my message.
I plan to report this problem on ubuntu community. Regards.
Edited on 2013-10-09
The bug has been reported to https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1237270
Two possible fixes (until ubuntu doesn't repair itself):
Try to compile in libpng.a and libz.a as a static library (it can be only a temporary solution, because static libs are evil in most cases).
Recompile libpng from the original source, and compile libz.a as static herein.

Using DMD in two separate steps: Linking 64-bit (Linux)

I'm running on 64-bit Ubuntu, and trying to get DMD v2.052 to work with Code::Blocks. The problem is, Code::Blocks does compiling and linking in two separate steps, and I can't seem to get around that. My compiler flags (for this project) are -m64, and my linker flags are all the ones supplied in dmd.conf. However, I get errors when I try to do this, like
Linking console executable: bin/Debug/Gossamer
/usr/bin/ld: skipping incompatible /home/me/devl/sfml2/bindings/d/lib/libdsfml-system.a when searching for -ldsfml-system
/usr/bin/ld: cannot find -ldsfml-system
/usr/bin/ld: skipping incompatible /home/me/devl/sfml2/bindings/d/lib/libdsfml-graphics.a when searching for -ldsfml-graphics
/usr/bin/ld: cannot find -ldsfml-graphics
/usr/bin/ld: skipping incompatible /home/me/devl/sfml2/bindings/d/lib/libdsfml-audio.a when searching for -ldsfml-audio
/usr/bin/ld: cannot find -ldsfml-audio
/usr/bin/ld: skipping incompatible /home/me/devl/sfml2/bindings/d/lib/libdsfml-window.a when searching for -ldsfml-window
/usr/bin/ld: cannot find -ldsfml-window
collect2: ld returned 1 exit status
I compiled the DSFML libs myself, using dmd -m64 -lib [library source code files], and there it wasn't in two steps, so I know they're fine. It seems ld doesn't like them, for some reason. Can somebody help?
Try doing the compile from the command line using just DMD. If that works I think there is a flag that will cause DMD to print the command line for the link command. From that you should be able to tell what you need Code::Blocks to do differently.

Resources