I'm trying to compile my libnet script and am getting this error:
[root#whyme]# gcc -Wall `libnet-config --defines` mysocket.cc -o mysocket `libnet-config --libs` -lpcap -lnet
/tmp/ccUPbuVg.o: In function `main':
mysocket.cc:(.text+0x1e): undefined reference to `net_init'
mysocket.cc:(.text+0x2a): undefined reference to `net_loadconfig'
mysocket.cc:(.text+0x35): undefined reference to `net_detectdrivers'
mysocket.cc:(.text+0x40): undefined reference to `net_initdrivers'
mysocket.cc:(.text+0x54): undefined reference to `net_openconn'
mysocket.cc:(.text+0x83): undefined reference to `net_listen'
mysocket.cc:(.text+0xbe): undefined reference to `net_poll_listen'
mysocket.cc:(.text+0xd2): undefined reference to `net_closeconn'
mysocket.cc:(.text+0xf1): undefined reference to `net_receive_rdm'
mysocket.cc:(.text+0x11b): undefined reference to `net_query_rdm'
I didn't paste my code because this looks like it's related to linking the objects.
I'm able to compile & execute this source file with your exact command (changing only the filenames): https://github.com/repolho/Libnet-1.1-tutorial-examples/blob/master/01_init.c
I therefore suspect the problem is in your source after all. Most libnet function names are of the form libnet_[funcname], but in your linker errors I see names of the form net_[funcname].
I also note that you've manually inserted -lnet. On my system, -lnet is the entire output of libnet-config --libs, so if you do need it specifying it manually is redundant. It's not harmful, but you can type fewer characters next time. :)
Could you check what is returned by "libnet-config --libs" ?
It might be returning something wrong, thus preventing the linker to find the libnet library. Make sure that the part saying "-L XXXX" points to the directory where libnet library is located.
Related
I've build libvpx.a and headers with MSYS (for MinGW). When I'm trying to compile an example a lot of undefined references to vpx members occurs:
g++ -m32 -static -o dist/Debug/MinGW-Windows/test1 build/Debug/MinGW-Windows/main.o -L/D/Libraries/libvpx/ -lvpx
build/Debug/MinGW-Windows/main.o: In function `main':
D:\Projects\CPP_test\Test1/main.cpp:107: undefined reference to `die'
D:\Projects\CPP_test\Test1/main.cpp:109: undefined reference to `vpx_video_reader_open'
D:\Projects\CPP_test\Test1/main.cpp:111: undefined reference to `die'
D:\Projects\CPP_test\Test1/main.cpp:114: undefined reference to `die'
D:\Projects\CPP_test\Test1/main.cpp:116: undefined reference to `vpx_video_reader_get_info'
D:\Projects\CPP_test\Test1/main.cpp:118: undefined reference to `get_vpx_decoder_by_fourcc'
D:\Projects\CPP_test\Test1/main.cpp:120: undefined reference to `die'
D:\Projects\CPP_test\Test1/main.cpp:125: undefined reference to `die_codec'
D:\Projects\CPP_test\Test1/main.cpp:127: undefined reference to `vpx_video_reader_read_frame'
D:\Projects\CPP_test\Test1/main.cpp:132: undefined reference to `vpx_video_reader_get_frame'
D:\Projects\CPP_test\Test1/main.cpp:134: undefined reference to `die_codec'
D:\Projects\CPP_test\Test1/main.cpp:137: undefined reference to `vpx_img_write'
D:\Projects\CPP_test\Test1/main.cpp:144: undefined reference to `die_codec'
D:\Projects\CPP_test\Test1/main.cpp:149: undefined reference to `vpx_video_reader_close'
All includes made, lib is linked...
So what am I doing wrong?
PS: Maybe it's not enough to link the libvpx.a file, and I also need the .c files that come with the sources (if so, I do not understand what for the .a lib file is needed)?
It looks like you just copied and pasted blindly from the example.
The functions die_codec and vpx_video_* all come from tools_common.c (https://github.com/webmproject/libvpx/blob/master/tools_common.c) and video_reader.h (https://github.com/webmproject/libvpx/blob/master/video_reader.c), which I believe is not a core part of the libvpx sdk (see here: http://www.webmproject.org/docs/webm-sdk/files.html).
In order for your example to work, you will need to copy-paste those files (both the .c and .h files) as well and include them in your main.cc file.
Overview
I am attempting to convert a C++ project from a Visual Studio solution to a makefile project (using g++), as a first step to supporting multiple platforms with ease. This project requires the Simple DirectMedia Layer 2 (SDL2) and SDL_image libraries. The project previously compiled without errors, and I have since corrected any errors halting the g++ compiler. I am still using Windows x64 and MinGW x64 at this point.
Problem
When linking, g++ throws errors as though there is something wrong with the SDL2 library, claiming that all functions of SDL2 can't be found. However, I know it is finding the libraries, because when I provide an incorrect name or path, I get an explicit error.
Here is my new makefile, apologies if it isn't up to standard:
# Source files
SRC_ENTITIES = Entity_Block.cpp Entity_Controller.cpp Entity_Cursor.cpp Entity_GreenEye.cpp Entity_Harry.cpp
SRC_ENGINE = Game.cpp Sound.cpp SoundManager.cpp Sprite.cpp Texture.cpp TextureManager.cpp Entity.cpp EntityManager.cpp
SRC_ENTRY = main.cpp
# Source and destination
SOURCE = $(SRC_ENTITIES) $(SRC_ENGINE) $(SRC_ENTRY)
DEST = crystal_engine.bin
# Compiler options
OUTPUT = -o $(DEST)
INCLUDES = -I . -I.\include\windows\SDL2-devel-2.0.4-mingw\SDL2-2.0.4\x86_64-w64-mingw32\include\SDL2 -I.\include\windows\SDL2_image-devel-2.0.1-mingw\SDL2_image-2.0.1\x86_64-w64-mingw32\include\SDL2
LIBPATHS = -L.\include\windows\SDL2-devel-2.0.4-mingw\SDL2-2.0.4\x86_64-w64-mingw32\lib -L.\include\windows\SDL2_image-devel-2.0.1-mingw\SDL2_image-2.0.1\x86_64-w64-mingw32\lib
LIBRARIES = -lSDL2 -lSDL2main -lSDL2_image
STANDARD = -std=c++0x
FLAGS = -Wall
default:
echo No task selected
compile:
g++ $(STANDARD) $(INCLUDES) $(FLAGS) $(SOURCE) $(OUTPUT) $(LIBPATHS) $(LIBRARIES)
run:
./$(DEST)
run_win:
$(DEST)
Therefor the command line currently looks like this:
g++ -std=c++0x -I . -I.\include\windows\SDL2-devel-2.0.4-mingw\SDL2-2.0.4\x86_64-w64-mingw32\include\SDL2 -I.\include\windows\SDL2_image-devel-2.0.1-mingw\SDL2_image-2.0.1\x86_64-w64-mingw32\include\SDL2 -Wall Entity_Block.cpp Entity_Controller.cpp Entity_Cursor.cpp Entity_GreenEye.cpp Entity_Harry.cpp Game.cpp Sound.cpp SoundManager.cpp Sprite.cpp Texture.cpp TextureManager.cpp Entity.cpp EntityManager.cpp main.cpp -o crystal_engine.bin -L.\include\windows\SDL2-devel-2.0.4-mingw\SDL2-2.0.4\x86_64-w64-mingw32\lib -L.\include\windows\SDL2_image-devel-2.0.1-mingw\SDL2_image-2.0.1\x86_64-w64-mingw32\lib -lSDL2 -lSDL2main -lSDL2_image
Disregarding warnings (removing -Wall), the output of the compile looks like this:
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0x169): undefined reference to `SDL_GetTicks'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0x2b4): undefined reference to `SDL_GetMouseState'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0x2c2): undefined reference to `SDL_PollEvent'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0x2d0): undefined reference to `SDL_GetTicks'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0x363): undefined reference to `SDL_GetTicks'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0x3ef): undefined reference to `SDL_GetTicks'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0x46c): undefined reference to `SDL_GetTicks'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0x4e3): undefined reference to `SDL_RenderClear'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0x4fd): undefined reference to `SDL_RenderPresent'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0x597): undefined reference to `SDL_ShowCursor'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0x5b1): undefined reference to `SDL_Init'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0x633): undefined reference to `SDL_CreateRenderer'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0x663): undefined reference to `SDL_CreateWindowAndRenderer'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0x678): undefined reference to `SDL_SetWindowTitle'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0x836): undefined reference to `SDL_SetRenderDrawColor'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0x844): undefined reference to `SDL_RenderClear'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0x852): undefined reference to `SDL_RenderPresent'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0x865): undefined reference to `SDL_SetHint'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0x881): undefined reference to `SDL_RenderSetLogicalSize'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0x895): undefined reference to `SDL_GL_SetAttribute'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0x8a3): undefined reference to `SDL_GetError'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0x8d8): undefined reference to `SDL_GL_SetAttribute'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0x8e6): undefined reference to `SDL_GetError'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0xa3d): undefined reference to `SDL_Quit'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0xaba): undefined reference to `SDL_DestroyWindow'
C:\Users\[...]\ccSkHjgE.o:Game.cpp:(.text+0xad1): undefined reference to `SDL_DestroyRenderer'
f:/mingw/mingw-4.8.1/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: C:\Users\[...]\ccSkHjgE.o: bad reloc address 0x1b in section `.text$printf[_printf]'
collect2.exe: error: ld returned 1 exit status
make: *** [compile] Error 1
Troubleshooting
I have tried a number of things from supplying exact paths to libraries to updating SDL from 2.0.3 to 2.0.4. The behavior is the same. There are two include/lib folders in the MinGW devel folder for each architecture, and changing which one I include does not make a difference.
There seems to be a lot of commotion about the order of which arguments are supplied to g++, given the three posts below:
SDL2 Undefined references to functions
Try to change the sequence of the input params:
I've stumbled over this before (on Linux)
https://askubuntu.com/questions/68922/cant-compile-program-that-uses-sdl-after-upgrade-to-11-10-undefined-reference
Ok, solved. Apparently, for some mysterious reason, the order of the gcc options now matters.
http://smf.cataclysmdda.com/index.php?topic=11028.0
It looks like the SDL2_image library is included, but the main SDL2 library is not (the references could be out of order).
Unfortunately, regardless of how I have reordered the arguments, I can't seem to change this result. Unlike with most issues, I haven't even been able to make it any worse! Any and all help is greatly appreciated.
I don't believe this has anything to do with my code, considering a compile without linking -c completes fine, but if it assists with the solution I would be more than happy to post some of it (it is a LOT of code).
Edits
Per request, here is a dump of the full compile with the -v and -Wall options. It is too large for this question so I threw it in a pastebin.
http://pastebin.com/ydET621i
When using the -DDECLSPEC=__declspec(dllimport) option, the output becomes:
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0x169): undefined reference to `_imp__SDL_GetTicks'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0x2b6): undefined reference to `_imp__SDL_GetMouseState'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0x2c6): undefined reference to `_imp__SDL_PollEvent'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0x2d6): undefined reference to `_imp__SDL_GetTicks'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0x36b): undefined reference to `_imp__SDL_GetTicks'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0x3f9): undefined reference to `_imp__SDL_GetTicks'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0x478): undefined reference to `_imp__SDL_GetTicks'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0x4f1): undefined reference to `_imp__SDL_RenderClear'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0x50d): undefined reference to `_imp__SDL_RenderPresent'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0x5a9): undefined reference to `_imp__SDL_ShowCursor'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0x5c5): undefined reference to `_imp__SDL_Init'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0x649): undefined reference to `_imp__SDL_CreateRenderer'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0x67b): undefined reference to `_imp__SDL_CreateWindowAndRenderer'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0x692): undefined reference to `_imp__SDL_SetWindowTitle'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0x852): undefined reference to `_imp__SDL_SetRenderDrawColor'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0x862): undefined reference to `_imp__SDL_RenderClear'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0x872): undefined reference to `_imp__SDL_RenderPresent'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0x887): undefined reference to `_imp__SDL_SetHint'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0x8a5): undefined reference to `_imp__SDL_RenderSetLogicalSize'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0x8bb): undefined reference to `_imp__SDL_GL_SetAttribute'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0x8cb): undefined reference to `_imp__SDL_GetError'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0x902): undefined reference to `_imp__SDL_GL_SetAttribute'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0x912): undefined reference to `_imp__SDL_GetError'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0xa6b): undefined reference to `_imp__SDL_Quit'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0xaea): undefined reference to `_imp__SDL_DestroyWindow'
C:\Users\[...]\ccZ61vi9.o:Game.cpp:(.text+0xb03): undefined reference to `_imp__SDL_DestroyRenderer'
f:/mingw/mingw-4.8.1/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: C:\Users\[...]\ccZ61vi9.o: bad reloc address 0x1b in section `.text$printf[_printf]'
collect2.exe: error: ld returned 1 exit status
make: *** [compile] Error 1
Running ar -t libSDL2.a produces the following:
SDL.o
SDL_assert.o
SDL_error.o
SDL_hints.o
SDL_log.o
SDL_atomic.o
SDL_spinlock.o
SDL_audio.o
SDL_audiocvt.o
SDL_audiodev.o
SDL_audiotypecvt.o
SDL_mixer.o
SDL_wave.o
SDL_cpuinfo.o
SDL_dynapi.o
SDL_clipboardevents.o
SDL_dropevents.o
SDL_events.o
SDL_gesture.o
SDL_keyboard.o
SDL_mouse.o
SDL_quit.o
SDL_touch.o
SDL_windowevents.o
SDL_rwops.o
SDL_haptic.o
SDL_gamecontroller.o
SDL_joystick.o
e_atan2.o
e_log.o
e_pow.o
e_rem_pio2.o
e_sqrt.o
k_cos.o
k_rem_pio2.o
k_sin.o
k_tan.o
s_atan.o
s_copysign.o
s_cos.o
s_fabs.o
s_floor.o
s_scalbn.o
s_sin.o
s_tan.o
SDL_power.o
SDL_d3dmath.o
SDL_render.o
SDL_yuv_mmx.o
SDL_yuv_sw.o
SDL_render_d3d.o
SDL_render_d3d11.o
SDL_render_gl.o
SDL_shaders_gl.o
SDL_render_gles.o
SDL_render_gles2.o
SDL_shaders_gles2.o
SDL_render_psp.o
SDL_blendfillrect.o
SDL_blendline.o
SDL_blendpoint.o
SDL_drawline.o
SDL_drawpoint.o
SDL_render_sw.o
SDL_rotate.o
SDL_getenv.o
SDL_iconv.o
SDL_malloc.o
SDL_qsort.o
SDL_stdlib.o
SDL_string.o
SDL_thread.o
SDL_timer.o
SDL_RLEaccel.o
SDL_blit.o
SDL_blit_0.o
SDL_blit_1.o
SDL_blit_A.o
SDL_blit_N.o
SDL_blit_auto.o
SDL_blit_copy.o
SDL_blit_slow.o
SDL_bmp.o
SDL_clipboard.o
SDL_egl.o
SDL_fillrect.o
SDL_pixels.o
SDL_rect.o
SDL_shape.o
SDL_stretch.o
SDL_surface.o
SDL_video.o
SDL_nullevents.o
SDL_nullframebuffer.o
SDL_nullvideo.o
SDL_diskaudio.o
SDL_dummyaudio.o
SDL_windows.o
SDL_xinput.o
SDL_windowsclipboard.o
SDL_windowsevents.o
SDL_windowsframebuffer.o
SDL_windowskeyboard.o
SDL_windowsmessagebox.o
SDL_windowsmodes.o
SDL_windowsmouse.o
SDL_windowsopengl.o
SDL_windowsopengles.o
SDL_windowsshape.o
SDL_windowsvideo.o
SDL_windowswindow.o
SDL_winmm.o
SDL_directsound.o
SDL_xaudio2.o
SDL_dinputjoystick.o
SDL_mmjoystick.o
SDL_windowsjoystick.o
SDL_xinputjoystick.o
SDL_dinputhaptic.o
SDL_windowshaptic.o
SDL_xinputhaptic.o
SDL_syspower.o
SDL_sysfilesystem.o
SDL_sysmutex.o
SDL_syssem.o
SDL_systhread.o
SDL_systls.o
SDL_syscond.o
SDL_systimer.o
SDL_sysloadso.o
Thanks to suggestions from #J.JHakala and #user657267 I have reached the conclusion that my installation of MinGW is actually 32 bit! Given that I was using the 64 bit libraries, they would read in like any other library, but the functions within them were not recognized.
For anyone else having this problem, you can download the 64 bit version of MinGW or alternatively just switch which libraries you are importing.
x86: i686-w64-mingw32
x64: x86_64-w64-mingw32
Ok, newb question here.
I'm trying to compile simple_xy_wr.f90 -- a netCDF example program -- using gfortran on Ubuntu, and I must be doing something pretty silly; I don't have much experince compiling Fortran.
First, I've got the libnetcdf-dev package installed, which includes files like
/usr/lib/libnetcdf.a
/usr/lib/libnetcdff.a
/usr/include/netcdf.mod
So, I've tried to compile the code with (various command like)
f95 -o xy -I/usr/include/ -L/usr/lib/ -lnetcdff -lnetcdf simple_xy_wr.f90
and I get the following output
/tmp/ccE6g7sr.o: In function `check.1847':
simple_xy_wr.f90:(.text+0x72): undefined reference to `__netcdf_MOD_nf90_strerror'
/tmp/ccE6g7sr.o: In function `MAIN__':
simple_xy_wr.f90:(.text+0x284): undefined reference to `__netcdf_MOD_nf90_create'
simple_xy_wr.f90:(.text+0x2b6): undefined reference to `__netcdf_MOD_nf90_def_dim'
simple_xy_wr.f90:(.text+0x2e8): undefined reference to `__netcdf_MOD_nf90_def_dim'
simple_xy_wr.f90:(.text+0x432): undefined reference to `__netcdf_MOD_nf90_def_var_manydims'
simple_xy_wr.f90:(.text+0x468): undefined reference to `__netcdf_MOD_nf90_enddef'
simple_xy_wr.f90:(.text+0x4aa): undefined reference to `__netcdf_MOD_nf90_put_var_2d_fourbyteint'
simple_xy_wr.f90:(.text+0x4cb): undefined reference to `__netcdf_MOD_nf90_close'
collect2: error: ld returned 1 exit status
I think that I'm including the right libraries. E.g. it seems that __netcdf_MOD_nf90_strerror should be there:
$ nm /usr/lib/libnetcdff.a | grep __netcdf_MOD_nf90_strerror
000000000004a100 T __netcdf_MOD_nf90_strerror
What am I doing wrong?
(FWIW, a few relevant references I've looked at are below.
undefined reference using netcdf library
Compiling problems with gfortran and NETCDF
Compiling and Running Fortran Programs - a basic guide
)
Ordering of object files and archives on the linker command line is very important on Unix systems since the default linker behaviour is to search for symbol definitions only in archives that follow the object file or archive, where an unresolved reference was found, referred to single pass linking.
This means that if your code references __netcdf_MOD_nf90_strerror, then the archive that contains the definition of this symbol (libnetcdff.a) must appear after the list of object files from your program. libnetcdff.a itself references symbols from the C library libnetcdf.a, hence it must be linked after libnetcdff.a. So the correct link order is:
/tmp/ccE6g7sr.o libnetcdff.a libnetcdf.a
where /tmp/ccE6g7sr.o is the temporary object file that the assembler produces from the compiled source file. The correct command line to compile your code is then:
f95 -o xy -I/usr/include/ simple_xy_wr.f90 -lnetcdff -lnetcdf
In this case the linker is not called directly, rather the compiler does it. GCC compilers pass all link-related things in the same order to an intermediate utility called collect2 which then calls the actual linker ld.
Note that if shared object versions of the netCDF library archives are also present (i.e. there are libnetcdff.so and libnetcdf.so), then the linker would prefer them to the static archives (unless static linking is enabled with the -static option) and the final link phase would be handled to the run-time link editor (RTLD) (/lib64/ld-linux-x86-64.so.2 on Ubuntu). In this case the same command line as in your question would actually succeed without link errors, despite the fact that both libraries are positioned before the code that references them, as the missing symbol references would be resolved by the RTLD while it is loading the executable file.
In Ubuntu 12.10, the order of the libraries is the trick (as Hristo suggested):
angelv#palas:~$ gfortran -o xy -I/usr/include/ -L/usr/lib/ -lnetcdf -lnetcdff simple_xy_wr.f90
/tmp/ccj95anF.o: In function `check.1847':
simple_xy_wr.f90:(.text+0x72): undefined reference to `__netcdf_MOD_nf90_strerror'
/tmp/ccj95anF.o: In function `MAIN__':
simple_xy_wr.f90:(.text+0x284): undefined reference to `__netcdf_MOD_nf90_create'
simple_xy_wr.f90:(.text+0x2b6): undefined reference to `__netcdf_MOD_nf90_def_dim'
simple_xy_wr.f90:(.text+0x2e8): undefined reference to `__netcdf_MOD_nf90_def_dim'
simple_xy_wr.f90:(.text+0x432): undefined reference to `__netcdf_MOD_nf90_def_var_manydims'
simple_xy_wr.f90:(.text+0x468): undefined reference to `__netcdf_MOD_nf90_enddef'
simple_xy_wr.f90:(.text+0x4aa): undefined reference to `__netcdf_MOD_nf90_put_var_2d_fourbyteint'
simple_xy_wr.f90:(.text+0x4cb): undefined reference to `__netcdf_MOD_nf90_close'
collect2: error: ld returned 1 exit status
angelv#palas:~$ gfortran -o xy -I/usr/include/ simple_xy_wr.f90 -L/usr/lib/ -lnetcdf -lnetcdff
angelv#palas:~$ ./xy
0 12 24 36
*** SUCCESS writing example file simple_xy.nc!
I'm working on a really old source code (compiled in Red Hat). Before it had lua-4.0.1 so I just compiled the latest lua (lua-5.1.4) and installed it in the same directory as the old one. The implementation isn't very big so there wasn't much to change except a few function names and I had to include "lauxlib.h" to get it to compile. It compiles without any problems but it gives these linking errors.
/usr/local/lib/liblua.a(loadlib.o): In function `ll_load':
loadlib.o(.text+0x19): undefined reference to `dlopen'
loadlib.o(.text+0x2a): undefined reference to `dlerror'
/usr/local/lib/liblua.a(loadlib.o): In function `ll_sym':
loadlib.o(.text+0x52): undefined reference to `dlsym'
loadlib.o(.text+0x63): undefined reference to `dlerror'
/usr/local/lib/liblua.a(loadlib.o): In function `ll_unloadlib':
loadlib.o(.text+0x8): undefined reference to `dlclose'
Basically all the paths are correct but I use the same flags for the compiler as the old one, I havent changed the makefile at all.
-static -lpthread -lnsl -lutil -ldl -lmysqlclient -llua -llualib -lz -lcppunit
The ldl flag is already there.
I just want to know things to try. Everything is appreciated. This is driving me insane.
Place -ldl at the end of the liner command. The order is important.
The linker searches for libraries fulfilling an unreferenced symbol only in libs which are standing more right on the command line. Your new liblua.a now uses dlopen and friends, while the older didn't. Since -ldl is left of -llua, the linker does not use libdl to link the lua references.
I'm supposed to use a data analysis program for a physics experiment. I can't get it to compile though.
The code is old, not really compatible with current GCC-versions from what I can find. To make things a bit more time-comsuming, I got the code from a guy who had modified all the makefiles to make it compile on Mac. I have no C++-experience, but with man-pages, Google and patience I have fixed a lot of errors on the way, but I'm stuck on this one, even after a week of tries and googling.
I believe the relevant error message is the following:
/usr/bin/ld: error in /home/daniel/skola/exjobb/miniballscripts
/lib/libCommandLineInterface.so(.eh_frame); no .eh_frame_hdr table will be created.`
What can be the cause, and what can be the remedy?
libCommandLineInterface.so was compiled by me before, without any apparent error messages:
$ make
g++ -g2 -O2 -I./ -c CommandLineInterface.cc -o CommandLineInterface.o
g++ -g -Wl -o /home/daniel/skola/exjobb/miniballscripts/lib/libCommandLineInterface.so
CommandLineInterface.o -lm -L/home/daniel/skola/exjobb/miniballscripts/lib -lgcc -lc
Done
My g++-version is g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3, amd64.
http://tinypaste.com/9eee9 - make output
http://tinypaste.com/ddbde - GNUmakefile
As I said, I have no experience with C++, so maybe my naive Makefile modifications have destroyed something. My lack of experience also makes me not really knowing what other information is needed to help me, but I'll be glad to reply.
Looks like you have forgotten the -shared command line option when you generate the libCommandLineInterface.so file. That would explain those multiple definition errors. If the linker thinks that the file it is generating is an executable (instead of a dynamic library), then it would link in the startup code, etc. When you try to use this .so file, those symbols coming in from the startup code will clash with those that are being added to the executable that uses the dynamic library.
It is possible that the libTransfer.so errors are related to the same flag being omitted. A shared library is allowed to have dangling references (that get resolved when the library is used), but an executable has to have all the symbols resolved at link time. This is probably an oversimplification of how things are, but I never needed to get into more details on dynamic linking in linux. :) Anyhow, adding -shared option may solve the undefined reference errors as well.
The linking errors of concern start with:
[...]/lib/libCommandLineInterface.so: In function `_start':
(.text+0x0): multiple definition of `_start'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o:(.text+0x0): first defined here
[...]/lib/libCommandLineInterface.so: In function `_fini':
(.fini+0x0): multiple definition of `_fini'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crti.o:(.fini+0x0): first defined here
[...]/lib/libCommandLineInterface.so:(.rodata+0x0): multiple definition of `_IO_stdin_used'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o:(.rodata.cst4+0x0): first defined here
[...]/lib/libCommandLineInterface.so: In function `__data_start':
(.data+0x0): multiple definition of `__data_start'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o:(.data+0x0): first defined here
[...]/lib/libCommandLineInterface.so: In function `__data_start':
(.data+0x8): multiple definition of `__dso_handle'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/crtbegin.o:(.data+0x0): first defined here
[...]/lib/libCommandLineInterface.so: In function `_edata':
(*ABS*+0x607130): multiple definition of `__bss_start'
[...]/lib/libCommandLineInterface.so: In function `_end':
(*ABS*+0x6073b8): multiple definition of `_end'
[...]/lib/libCommandLineInterface.so: In function `_edata':
(*ABS*+0x607130): multiple definition of `_edata'
[...]/lib/libCommandLineInterface.so: In function `main':
/home/daniel/skola/exjobb/miniballscripts/Common/CommandLineInterface.cc:6: multiple definition of `main'
The symbols that are multiply defined are 'standard' on Unix - and I've never needed to bother with them myself on Mac either, though I don't do GUI programming there.
You need to look at libCommandLineInterface.cc with a very prejudiced attitude and decide whether it provides anything that you need. You might be able to remove it altogether. If it contains some stuff you do need, you will need to cauterize the material that defines _start, and _end and main and so on.
You are also going to have to worry about the missing vtables:
[...]/libTransfer.so: undefined reference to `vtable for Annular'
[...]/libTransfer.so: undefined reference to `ROOT::GenerateInitInstance(Barrel const*)'
[...]/libTransfer.so: undefined reference to `ROOT::GenerateInitInstance(Annular const*)'
[...]/libTransfer.so: undefined reference to `vtable for Barrel'
[...]/libTransfer.so: undefined reference to `vtable for Crystal'
[...]/libTransfer.so: undefined reference to `vtable for Germanium'
It's solved. The eh_frame_hdr-problem was solved by this thread. The undefined references was solved by deleting libTransfer.so after the first make, and then directly afterwards running make again. Don't ask me how, but that made it compile.