I'm using Qt Creator 4.11.0-beta2 (4.10.83) in a project.
Wanted to add CUPS for printing abilities.
Added library libcups.a in the projects *.pro file :
LIBS += \ /usr/lib/x86_64-linux-gnu/libcups.a
When linking I get the error.
:-1: error: /usr/lib/x86_64-linux-gnu/libcups.a(file.o): undefined reference to symbol 'inflateEnd'
Investigations indicate the problem lies in the dependence zlib1g (>=1:1.2.0)
(I have version zlib1g 1:1.2.11.dfsg-1+b1)
Someone (google) has suggested it happens because linker try to use libzip instead of zlib
I do not know how to solve this problem.
Related
I have successfully installed and used the Portaudio library for real time sound output on Ubuntu, with some C++ code.
But my main project is on Windows under Qt Creator. I have tried to build Portaudio with MinGW which seems to have worked because when I run the example "bin/paex_sine" it outputs a sine, but I can't use it in Qt.
I have linked the library by adding
LIBS += -LC:/MinGW/lib/ -lportaudio.dll
as advised there, but I get errors of this type :
undefined reference to mingw_initcharmax crtexe.c
I also tried to use the flag "--enable-cxx" when running ./configure, but then the make returns the following error :
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\cwtype:89:11: error: '::iswblank' has not been declared
using ::iswblank;
^
I don't really know what I did wrong and how I should proceed...
I need to install the real time proccess library "rtaudio-4.1.1" on windows in order to use it in C++ projet.
I'd try to compile the library project given by MIT website with QTCreator. I opened the qt project RTaudio and click on compile and the output is:
In function `newDrvStruct` (in asiolist.o):
undefined reference to `_imp__CLSIDFromString#8' in asiolist.cpp
In function `ZN14AsioDriverListC2Ev` (in asiolist.o):
undefined reference to `_imp__CoInitialize#4' in asiolist.cpp
Some research on the subject leads me to accuse the linker configuration but I didn't know very well what's the problem and how to solve it. :'(
So, i'm calling you to give me some hope !
Thanks by advance ! =)
The "ole32.dll" lib is missing. Try to add this to your .pro file:
LIBS += -lole32 -lwinmm -luuid -lksuser
I'm building my program with clang and its using an external library. I've been developing for a while with the binaries they provided (/usr/lib/libary.so), but I now want to move over to a more current version.
I downloaded the source code and built it, resulting in an include file and a new library (in my ~/library/build directory).
When compiling my code, I use
clang++ main.cpp -I ~/library/include -L ~/library/build/lib -llibrary
This includes the up to date header, and finds the correct library (I know it finds the correct library, because without the -L flag, I get an error saying 'undefined reference to NewlyIntroducedFunction').
However, when I try to run a.out, I get the error:
./a.out: symbol lookup error: ./a.out: undefined symbol: NewlyIntroducedFunction
Running ldd on ./a.out shows me the line:
library.so => /usr/lib/library.so
So I assume that, although at compile time the correct library is being used, at runtime it isn't. I added ~/library/build to the start of PATH and that didn't work.
What do I do to get the correct version of library.so found?
Your LD_LIBRARY_PATH variable (library search path) is probably not correct
I am getting linker failures under MinGW, however I cannot see why. This is the link command:
g++ -shared -mthreads
-Wl,--out-implib,C:\Users\camm\Syren\libs\libSy_polyMesh.a -o C:\Users\camm\Syren\libs\Sy_polyMesh.dll debug/Sy_polyMesh.o
debug/moc_Sy_polyMesh.o debug/qrc_Sy_polyMesh.o -L"c:\Qt\4.8.4\lib"
-lglu32 -lopengl32 -lgdi32 -luser32 -LC:\Users\camm\Syren/libs -lSyren -lglew32 -lboost_system -lQtSvgd4 -lQtSqld4 -lQtOpenGLd4 -lQtGuid4 -lQtCored4
The undefined reference errors come from the Syren dll (I should state the command was automatically generated by qmake). The -LC:\Users\camm\Syren/libs looks malformed to me because of the mix of forward and backslashes, but if I manually set them to all one way or the other - it does not change the compiler output.
I had earlier problems with 3rd party libraries I needed (GLEW and Boost specifically), but because they were relatively 'constant' I didn't have a problem putting them in my C:\MinGW\lib directory. But that is really not an option for my plugins.
What I find is that the MinGW docs state in a few locations:
...since suitable search paths may always be specified using -L
options.
...but that GCC itself furnishes the effective defaults, by supplying
appropriate -L options.
However, C:\Users\camm\Syren\libs is where Syren.dll resides!
Edit: Here are the LIBS declarations in my .pro file:
LIBS += -L$(SYREN_PATH)/libs \
-lSyren
win32 {
LIBS += -lglew32 \
-lboost_system
}
And $(SYREN_PATH) expands to C:\Users\camm\Syren. Also I can see to the 'missing' symbols in Syren.dll, for example:
C:\Users\camm\Documents\Syren\Sy_polyMesh_debug/../Sy_polyMesh/src/Sy_polyMesh.cpp:341:
undefined reference to `Sy_GLBuffer::unbind()'
Can be seen listed as:
6c500bd6 T _ZN11Sy_GLBuffer6unbindEv
Edit2
After adding a verbose flag to the linker stage I noticed that the linker was iterating through each search path and then through each library naming convention, and using the first one it could open.
attempt to open C:\Users\camm\Syren/libs/libSyren.dll.a failed
attempt to open C:\Users\camm\Syren/libs/Syren.dll.a failed
attempt to open C:\Users\camm\Syren/libs/libSyren.a succeeded
Hypothesizing that the libSyren.a may be broken, I renamed it to force the linker to use the .dll:
attempt to open C:\Users\camm\Syren/libs/libSyren.dll.a failed
attempt to open C:\Users\camm\Syren/libs/Syren.dll.a failed
attempt to open C:\Users\camm\Syren/libs/libSyren.a failed
attempt to open C:\Users\camm\Syren/libs/Syren.lib failed
attempt to open C:\Users\camm\Syren/libs/libSyren.dll failed
attempt to open C:\Users\camm\Syren/libs/Syren.dll succeeded
But I still get exactly the same error messages!
If you are linking the right DLL and the linker isn't complaining about a missing file, the dll might be missing exports to allow linking.
The MinGW linker can link directly to a DLL if it properly exports the symbols, although it is still recommended to link to the import library (which should be created in a qmake build) which is named lib*.a or lib*.dll.a. I believe the linker looks for variants with and without the libprefix, but I am unsure and should test this myself.
You can check what symbols a DLL exports by using objdump and/or nm.
If the linker doesn't complain about not being able to load Syren dll, it means that the file is correctly loaded... The symbols are just missing into the Syren dll (not exported ?)... Why it's hard to tell without more information
When you built the Syren lib, did you have any warning about missing prototypes ?
What is used by Syren lib, nothing not portable or requiring a Windows dll ?
Could you give the list of missing symbols ?
Edit : How do you compile the Syren.dll ? Did you use Mingw ? What option did you pass to the compiler / linker ?
I suggest to read these 2 links :
http://www.mingw.org/wiki/sampleDLL
http://www.mingw.org/wiki/CreateImportLibraries
If you are exporting C++ function you must use the same compiler between the program and the DLL. Or you could use a C-style wrapper functions to encapsulate the C++ ABI.
A very good article about this subject : http://www.codeproject.com/Articles/28969/HowTo-Export-C-classes-from-a-DLL
What happens when you replace $(SYREN_PATH) with $${SYREN_PATH}?
Because the former notation $() means the contents of an environment variable at the time Makefile is executed.
See the qmake variable reference.
Using glew, I'm trying to link the simple program
#include </usr/include/GL/glew.h>
int main (int argc, const char * argv[])
{
glewInit();
return 0;
}
in XCode 4, under OSX Lion, which reports the error:
ld: library not found for -lGLEW.1.7.0
Command /Developer/usr/bin/clang++ failed with exit code 1
however, the error output also reports the following flags for the linker
-mmacosx-version-min=10.7 -L/usr/lib -lGLEW.1.7.0 -lglfw -framework OpenGL -framework Cocoa
and indeed, libGLEW.1.7.0 does reside in /usr/lib
Moreover, if I try to build the program by hand, with
gcc -L/usr/lib -lGLEW.1.7.0 main.cpp
I get an a.out file without any errors reported (which if run causes a segmentation fault, but maybe that's to be expected)
Any ideas on what might be causing XCode to produce this error and how it could be avoided?
Built and installed GLEW myself and had the same issue with plain gcc inside a makefile on OS X with compilation of code from https://github.com/jckarter/hello-gl
The following steps resolved the issue:
I found my GLEW libs (libGLEW.a and libGLEW.dylib) installed in /usr/lib directory (it definitely was there owned by root with r permissions for others). Tried to change GLEW_LIB variable from the makefile to /usr/lib but still got ld: library not found for -lGLEW
after that I tried to link compiled program against static library directly (without -l flag) - for that I removed -lGLEW from gcc command and changed it to direct link t library /usr/lib/libGLEW.a - it compiled and linked fine
Ok - it's a work around to try first
Then I created two links to my libraries with the following commands:
ln -s /usr/lib/libGLEW.a /usr/local/lib/libGLEW.a
ln -s /usr/lib/libGLEW.dylib /usr/local/lib/libGLEW.dylib
and finally got it working with original makefile (only changed GLEW_LIB variable to /usr/local/lib).
Probably GLEW's make install should place libraries to /usr/local/lib directly.
(I have removed this from an edit to the question and posted it as an answer, as per leppie's suggestion)
I might have found the answer in some details I had considered unimportant in my original post. So here goes, in case others might encounter a similar problem.
Apparently, XCode4 projects use clang++ by default, which in the link phase accepts a parameter -isysroot (which apparently ld does not accept).
Now, if in your build settings (as was my case) your Base SDK has been defined as something other than Current Mac OS, the parameter -isysroot will be introduced with the value of a directory pointing to that SDK, thus (this is my guess) prepending this to all other lib directories you might be including with -L.
In my case, -L/usr/lib was effectively turning into -L/Developer/SDKs/MacOSX10.7.sdk/usr/lib which does exist and did not contain libGLEW, hence the error "library not found"