I am trying to use SDL2_mixer for sound but I get these errors
undefined reference to `Mix_OpenAudio'
undefined reference to `Mix_LoadWAV_RW'
undefined reference to `Mix_PlayChannelTimed'
According to Lazy Foo's tutorials undefined references mean that I have something wrong in my linker settings how every I believe I have it right. It goes as follows:
-lmingw32 -lSDL2main -lSDL2 -lSDL2_mixer -lSOIL -lOpenGL32
Additionally the search directories for the header and lib files are correct (I have triple checked) and the .dll is in the same directory as the executable. The code files also have the corresponding #include directories. There are not any more things I can think to try so any help is appreciated
I was trying to compile a 64-bit Mixer with the 32-bit SDL.
I think you've the SDL mixer runtime binaries alone extracted into a directory. However, for compiling and linking you need the development libraries which has the stub library libSDL2_mixer.dll.a file necessary for linking.
In the SDL_mixer page, you've two sections: Runtime Binaries and Development Libraries. In the second section, download SDL2_mixer-devel-2.0.0-mingw.tar.gz (MinGW 32/64-bit). Extract it to a directory and add the (/lib) directory path to C::B and pass -lSDL2_mixer and it should link just fine.
When you run the executable, make sure SDL2_mixer.dll (from the \bin directory of the download) is present in the same directory for runtime dynamic linking to work.
Related
I copied only the Octave lib and include folders from the original build folders and pasted into another (toolbox) folder. The toolbox folder has C++ code that has embedded Octave functions. The LD flags and C flags for compiling the code are-
LD flags- "-L/path/to/lib -loctave -L/path/to/lib -loctinterp -Wl,-rpath=/path/to/lib/folder"
I flags- "-I/usr/include/scilab -I/path/include/octave-4.0.3 -I/path/include/octave-4.0.3/octave/"
When I compile the C++ code, I get the error
libtool: link: warning: library `/home/fossee/Desktop/FSOIToolbox/thirdparty/linux/lib/x64/octave/4.0.3/liboctave.la' was moved.`
libtool: link: warning: library `/home/fossee/Desktop/FSOIToolbox/thirdparty/linux/lib/x64/octave/4.0.3/liboctinterp.la' was moved.
/usr/bin/ld: cannot find -liboctave.la
/usr/bin/ld: cannot find -liboctinterp.la
I understand the issue is due to copying the lib files.
How do I include .la files in the flags so that the error is resolved for my system?
I need this code to work on any system. How do I include the Octave lib and include folders in the toolbox thirdparty folder such that it works on any system. When I go through the liboctave.la file, the paths in the file refer to my system. I need to make this general.
The source code is available here- https://github.com/shamikam/FOSSEE_Scilab_Octave_Interface_Toolbox
The Octave files are in thirdparty folder.
I am trying to cross-compile apache-qpid for an arm system from a debian.
There is undefined reference to __dlopen error, but it seems that it is related to the previous warning:
using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking ...
Here is the detail:
[ 86%] Linking CXX shared library libqpidcommon.so
CMakeFiles/qpidcommon.dir/qpid/sys/posix/Shlib.cpp.o: In function
`qpid::sys::Shlib::load(char const*)':
/home/mert/qpid-cpp-0.34/src/qpid/sys/posix/Shlib.cpp:32: warning: Using
'dlopen' in statically linked applications requires at runtime the shared
libraries from the glibc version used for linking
/home/mert/IDE/cVEND/00.00.14/bin/../arm-feig-linux-
gnueabi/sysroot/usr/lib/libdl.a(dlopen.o): In function `dlopen':
dlopen.c:(.text+0xc): undefined reference to `__dlopen'
I do not know what is happening exactly and how to solve it.
Here there is a similiar thing, I tried to add -static -ldl -lc C_FLAGS but made no difference.
Any help appreciated.
EDIT :
EDIT :
I am not sure exactly what is solved the problem, but I think that -ldl was looking exactly for libdl.so, but in arm directory, it was libdl-2.19.so, thus, probably it was then looking for and finding in another directory. I have linked libdl.so to libdl-2.19.so and now it is compiling.
The linker needs the options, not the compiler. See LDFLAGS.
https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html
Extra flags to give to compilers when they are supposed to invoke the
linker, ‘ld’, such as -L. Libraries (-lfoo) should be added to the
LDLIBS variable instead.
If this error occurs during the make step try doing
make LIBS=-ldl
And make sure the library path is present in LDFLAGS
export LDFLAGS=-L<path/to/ldl>
I want to start with a simple linking usage to explain my problem. Lets assume that there is a library z which could be compiled to shared library libz.dll(D:/libs/z/shared/libz.dll) or to static library libz.a (D:/libs/z/static/libz.a).
Let I want to link against it, then I do this:
gcc -o main.exe main.o -LD:/libs/z/static -lz
According to this documentation, gcc would search for libz.a, which is
archive files whose members are object files
I also can do the following:
gcc -o main.exe main.o -LD:/libs/z/shared -lz
It is not mentioned in the documentation above that -l flag will search for lib<name>.so.
What will happen if I libz.a and libz.dll will be in the same directory? How the library will be linked with a program? Why I need the flags -Wl,-Bstatic and -Wl,-Bdynamic if -l searches both for shared and static libraries?
Why some developers provide .a files with .dll files for the same modules, if I compile a shared library distribution?
For example, Qt provides .dll files in bin directory with .a files in lib directory. Is it the same library, but built like shared and static, respectively? Or .a files are some kind of dummy libraries which provide linking with shared libraries, where there are real library implementations?
Another example is OpenGL library on Windows. Why every compiler must provide the static OpenGL lib like libopengl32.a in MingW?
What are files with .dll.a and .la extensions used for?
P.S. There are a lot of questions here, but I think each one depends on the previous one and there is no need to split them into several questions.
Please, have a look at ld and WIN32 (cygwin/mingw). Especially, the direct linking to a dll section for more information on the behavior of -l flag on Windows ports of LD. Extract:
For instance, when ld is called with the argument -lxxx it will attempt to find, in the first directory of its search path,
libxxx.dll.a
xxx.dll.a
libxxx.a
cygxxx.dll (*)
libxxx.dll
xxx.dll
before moving on to the next directory in the search path.
(*) Actually, this is not cygxxx.dll but in fact is <prefix>xxx.dll, where <prefix> is set by the ld option -dll-search-prefix=<prefix>. In the case of cygwin, the standard gcc spec file includes -dll-search-prefix=cyg, so in effect we actually search for cygxxx.dll.
NOTE: If you have ever built Boost with MinGW, you probably recall that the naming of Boost libraries exactly obeys the pattern described in the link above.
In the past there were issues in MinGW with direct linking to *.dll, so it was advised to create a static library lib*.a with exported symbols from *.dll and link against it instead. The link to this MinGW wiki page is now dead, so I assume that it should be fine to link directly against *.dll now. Furthermore, I did it myself several times with the latest MinGW-w64 distribution, and had no issues, yet.
You need link flags -Wl,-Bstatic and -Wl,-Bdynamic because sometimes you want to force static linking, for example, when the dynamic library with the same name is also present in a search path:
gcc object1.o object2.o -lMyLib2 -Wl,-Bstatic -lMyLib1 -Wl,-Bdynamic -o output
The above snippet guarantees that the default linking priority of -l flag is overridden for MyLib1, i.e. even if MyLib1.dll is present in the search path, LD will choose libMyLib1.a to link against. Notice that for MyLib2 LD will again prefer the dynamic version.
NOTE: If MyLib2 depends on MyLib1, then MyLib1 is dynamically linked too, regardless of -Wl,-Bstatic (i.e. it is ignored in this case). To prevent this you would have to link MyLib2 statically too.
I am writing a C++ program in Linux with NetBeans. I am having difficulty setting it up to use external sources/shared objects. I have the .so files from the compiled external package and the source files that go with it.
So far I have:
specified for the project to include all the source and header file directories (under Project properties->Build->C++ Compiler)
specified the .so files that correspond to the external source code (under Project properties->Build-Linker)
When I try to declare an object defined in the external sources NetBeans does not give me any syntax errors and even auto-completes the object name for me. However, when I build the program I get an error saying "undefined reference to" that object.
Am I doing something horribly wrong?
EDIT:
In response to quamrana's question, this is one of the output lines in the console when it attempts to build.
g++ -o dist/Debug/GNU-Linux-x86/JAUSTester build/Debug/GNU-Linux-x86/MainScreen.o build/Debug/GNU-Linux-x86/main.o build/Debug/GNU-Linux-x86/moc_MainScreen.o -L/usr/lib -Wl,-rpath /usr/local/lib/active /usr/local/lib/active/libcxutils.so -Wl,-rpath /usr/local/lib/active/libjauscore.so -Wl,-rpath /usr/local/lib/active/libjausextras.so -Wl,-rpath /usr/local/lib/active/libjausmobility.so -Wl,-rpath /usr/local/lib/active/libtinyxml.so -lQtGui -lQtCore -lpthread
The .so files I want to include are the ones specified there in /usr/local/lib/active/.
I have this assignment due that requires the usage of FLTK. The code is given to us and it should compile straight off of the bat, but I am having linking errors and do not know which other libraries I need to include.
I currently have "opengl32", "fltk_gl", "glu32", and "fltk" included (-l), each of which seem to reduce the number of errors. I compiled FLTK using make with no specified options. Including all of the produced library files doesn't fix the problem, and I'm convinced that it's just some Windows specific problem.
Compile log:
**** Build of configuration Debug for project CG5 ****
make all
Building target: CG5.exe
Invoking: Cygwin C++ Linker
g++ -o"CG5.exe" ./src/draw_routines.o ./src/gl_window.o ./src/my_shapes.o ./src/shape.o ./src/shapes_ui.o ./src/tesselation.o -lopengl32 -lfltk_z -lfltk_gl -lglu32 -lfltk
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libfltk_gl.a(Fl_Gl_Window.o):Fl_Gl_Window.cxx:(.text+0x197): undefined reference to `_SelectPalette#12'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libfltk_gl.a(Fl_Gl_Window.o):Fl_Gl_Window.cxx:(.text+0x1a7): undefined reference to `_RealizePalette#4'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libfltk_gl.a(Fl_Gl_Window.o):Fl_Gl_Window.cxx:(.text+0x1fe): undefined reference to `_glDrawBuffer#4'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libfltk_gl.a(Fl_Gl_Window.o):Fl_Gl_Window.cxx:(.text+0x20d): undefined reference to `_glReadBuffer#4'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libfltk_gl.a(Fl_Gl_Window.o):Fl_Gl_Window.cxx:(.text+0x23a): undefined reference to `_glGetIntegerv#8'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libfltk_gl.a(Fl_Gl_Window.o):Fl_Gl_Window.cxx:(.text+0x2c3): undefined reference to `_glOrtho#48'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libfltk_gl.a(Fl_Gl_Window.o):Fl_Gl_Window.cxx:(.text+0x2f3): undefined reference to `_SwapBuffers#4'
...and lots more
Thanks a ton for the help.
EDIT: These first few lines are obviously OpenGL related, although I'm still not sure what additional libraries need to be included.
Just a guess: your makefile was written for Linux, and on Cygwin some libraries are either missing or in a different place. You're going to have to examine the makefile, locate the missing libraries, and either move the libs to where the makefile expects them or change the makefile to look in the right place.
The libraries it needs are listed on the line starting g++ (prepend 'lib' to the names after the -l flags)
Sorry for the lack of closure, but I just booted into my Linux netbook and got it working.
-lfltk -lfltk_gl -lGLU -lGL -lXext -lX11 -lm