Using GMP in Xcode 4 -- linking problems - xcode4

I am trying to use the GMP 5.0.2 libraries in a demo C++ project in Xcode 4.0.2, but I'm having trouble getting the linking to work.
I looked at the comments in the StackOverflow post: Adding Linker Flags in Xcode,
found the GMP library and header files in /usr/local/lib and /usr/local/include and dragged them to the project target. This allowed the project to compile, but apparently not to link. The error I'm getting is
Undefined symbols for architecture x86_64:
"operator>>(std::istream&, __mpz_struct*)", referenced from:
_main in main.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Any suggestions for what I should try next? Thanks.
#include <iostream>
#include "gmp.h"
#include <stdio.h>
using namespace std;
int main (int argc, const char * argv[])
{
mpz_t x;
mpz_init(x);
cin >> x;
cout << "x = " << endl;
// insert code here...
std::cout << "Hello, World!\n";
return 0;
}

To run your program with GMP, remember to add the -lgmp flag to the linker, like so: (via Rob Keniger):
Right-click the target in the Xcode Groups and Files list and select Get Info from the contextual menu. In the Build tab, type linker into the search field and then locate the Other Linker Flags item.
Double-click the Other Linker Flags item and add -lgmp.

A couple of ideas:
1) As nes says, be sure to add the -lgmp flag to your linker call.
2) Try including "gmpxx.h" and adding -lgmpxx -lgmp to the linker. (The order can be important!) It shouldn't be necessary for straight C code...in theory...but those look more like C++ errors to me.
3) Consider the MPIR library. It is the same as GMP but with a more Windows friendly view of the world.
4) Check the manual - sometimes there are other includes you need for specific functions.

How was your GMP library compiled? Was it compiled for 32-bit architectures only by any chance? If so, you won't be able to use it in a 64-bit project; you'll have to add -arch i386 to the list of compiler flags to make XCode create a 32-bit executable.

you should do like this:
project
build phases
link binary with librarys
click "+" choose your own gmp library,like /opt/local/lib/libgmp.10.dylib (ps:I use macport to complie GMP).

If you don't need all of the features of GMP, you should be able to simply drag and drop the mini-gmp.h and mini-gmp.m files into your project and start using the basic features of the library.

Related

undefined reference to symbol 'inflateEnd'

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.

Portaudio library not working with Qt

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...

QtCreator cannot find stddef.h working on linux

I just freshly installed Qt Creator 4.1.0
Based on Qt 5.7.0 (GCC 4.9.1 20140922 (Red Hat 4.9.1-10), 64 bit)
This error drives me crazy after I fixed all kit errors, actually I spent some time on google looking for proper compiler. This could be something with compiler version I think:
/usr/include/c++/5.3.1/cstddef:45: error: stddef.h: No such file or
directory
I saw solutions for windows everywhere but could not find for linux, does anyone has experience how to fix it?
Screenshots
rpm -qa | grep devel | sort
expat-devel-2.1.0-10.fc22.x86_64
fontconfig-devel-2.11.94-4.fc22.x86_64
freetype-devel-2.5.5-2.fc22.x86_64
gdbm-devel-1.11-4.fc22.x86_64
glibc-devel-2.21-13.fc22.i686
glibc-devel-2.21-13.fc22.x86_64
java-1.8.0-openjdk-devel-1.8.0.65-3.b17.fc22.x86_64
kernel-debug-devel-4.2.5-201.fc22.x86_64
kernel-debug-devel-4.2.6-200.fc22.x86_64
kernel-devel-4.2.6-200.fc22.x86_64
libdb-devel-5.3.28-12.fc22.x86_64
libdrm-devel-2.4.61-3.fc22.x86_64
libICE-devel-1.0.9-2.fc22.x86_64
libpng-devel-1.6.16-3.fc22.x86_64
libSM-devel-1.2.2-2.fc22.x86_64
libstdc++-devel-5.3.1-6.fc22.i686
libstdc++-devel-5.3.1-6.fc22.x86_64
libXau-devel-1.0.8-4.fc22.x86_64
libxcb-devel-1.11-8.fc22.x86_64
libXcursor-devel-1.1.14-4.fc22.x86_64
libXdamage-devel-1.1.4-6.fc22.x86_64
libXext-devel-1.3.3-2.fc22.x86_64
libXfixes-devel-5.0.1-4.fc22.x86_64
libXft-devel-2.3.2-2.fc22.x86_64
libXi-devel-1.7.4-2.fc22.x86_64
libXinerama-devel-1.1.3-4.fc22.x86_64
libXrandr-devel-1.4.2-2.fc22.x86_64
libXrender-devel-0.9.9-1.fc22.x86_64
libxshmfence-devel-1.2-1.fc22.x86_64
libXt-devel-1.1.4-10.fc22.x86_64
libXv-devel-1.0.10-2.fc22.x86_64
libXxf86vm-devel-1.1.4-1.fc22.x86_64
libX11-devel-1.6.3-1.fc22.x86_64
mesa-libGL-devel-10.6.9-1.20151008.fc22.x86_64
mesa-libGLU-devel-9.0.0-7.fc22.x86_64
perl-devel-5.20.3-328.fc22.x86_64
python3-devel-3.4.2-6.fc22.x86_64
qt-devel-4.8.7-4.fc22.x86_64
systemtap-devel-2.9-1.fc22.x86_64
systemtap-sdt-devel-2.9-1.fc22.x86_64
xorg-x11-proto-devel-7.7-12.fc21.noarch
zlib-devel-1.2.8-7.fc22.x86_64
I had this problem as well, and for me I had to disable ClangCodeModel plugin. To do this, I went to Help->About Plugins...->Uncheck ClangCodeModel (under C++ category). After restarting QT Creator, everything was working fine. I found this solution on QT Forums
If the compiler works from a terminal, it should work from QtCreator. So first make it work from the terminal.
From a terminal, create a file main.cpp with:
#include <cstddef>
int main()
{
return 0;
}
Then type the command:
gcc -H main.cpp -o main
If the compilation works, there must be a problem in your kit definition in QtCreator. Possibly make sure the folder where stddef.h is in the include file list of your kit. But you should not need to do that. Temporarily, you can add the include path to your project (see How to add include path in Qt Creator?) to check this is really the problem. Then you'll need to find a way to fix the kit for good.
If the compilation does not work, fix your environment (possibly using sashoalm's commented link). QtCreator is just and IDE, if you run it with a broken compiler it won't fix it for you. The compilation output will show where files (cstddef and then stddef.h) are picked from (-H option). Try cpp -v to see where included files are searched.
On my machine, compilation output gives me:
. /usr/include/c++/4.8/cstddef ..
/usr/include/x86_64-linux-gnu/c++/4.8/bits/c++config.h ...
/usr/include/x86_64-linux-gnu/c++/4.8/bits/os_defines.h ....
/usr/include/features.h .....
/usr/include/x86_64-linux-gnu/sys/cdefs.h ......
/usr/include/x86_64-linux-gnu/bits/wordsize.h .....
/usr/include/x86_64-linux-gnu/gnu/stubs.h ......
/usr/include/x86_64-linux-gnu/gnu/stubs-64.h ...
/usr/include/x86_64-linux-gnu/c++/4.8/bits/cpu_defines.h ..
/usr/lib/gcc/x86_64-linux-gnu/4.8/include/stddef.h Multiple include
guards may be useful for: /usr/include/c++/4.8/cstddef
/usr/include/x86_64-linux-gnu/bits/wordsize.h
/usr/include/x86_64-linux-gnu/gnu/stubs-64.h
/usr/include/x86_64-linux-gnu/gnu/stubs.h
/usr/lib/gcc/x86_64-linux-gnu/4.8/include/stddef.h
see stddef.h was found in /usr/lib/gcc/x86_64-linux-gnu/4.8/include
And cpp -v gives:
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/4.8/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
Note: If you created the kit manually, I would recommend that you uninstall QtCreator. Make gcc work from a terminal and then reinstall QtCreator. This one should create the kits automatically and they should then work.
This is a common problem with QT I experience a lot with all versions of Fedora, the problem is that the path to "/usr/lib64/qt5/bin" is missing from the user environment.
To check for the path at a command line what the path is present set to enter the following: echo $PATH
You should see the "/usr/lib64/qt5/bin" listed somewhere in the response if it is not present then edit the .bashrc file in the root of your home directory as follows: -
Add QT5 build environment
if! [[ "$PATH" =~ "/usr/lib64/qt5/bin" ]]
then
PATH="/usr/lib64/qt5/bin:$PATH"
fi
Just above the "export PATH" statement
You will need to log off and on again for the changes to take effect.

mingw ignores '-L' flag

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.

cannot link glew under xcode4, macosx lion

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"

Resources