cannot link glew under xcode4, macosx lion - glew

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"

Related

qmake how to add extra flags

I am using qmake to cross-compile my ARM based program on Ubuntu. I have ran into the multithreading issue as described in this thread:
C++ 11 Threads, Error Pure virtual function called
One answer suggests adding the flag to the compilation as:
g++ -pthread -std=c++11 -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_{1,2,4} thread1.cpp
I am not sure how to add this -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_{1,2,4} in my qmake project file.
I did QMAKE_CXXFLAGS += -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_{1,2,4}. My error still remains so I wanted to confirm if this is the right way to add that flag.
It's a bash glob/wildcard. Expands to
-D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4

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.

Adding module to existing Qt5 installation from source

I have an existing Qt5.3.2 installation from tar.gz source files.
When attempting to compile VTK, which has optional Qt{4,5} interface, I was informed I don't have QtWebKitWidgets by ccmake.
I don't particularly want to reinstall Qt5 on top of the existing installation, for fear of breaking other things built against it.
Can I add to my current Qt5?
Would variants on
/path/to/configure -release -prefix $existingPrefix
make -module-qtwebkit
make install
or
/path/to/configure -release -prefix $newPrefix
make -module-qtwebkit
make install
cp -rf $newPrefix/CMake/QtWebKit (or similar path) $existingPrefix/CMake/
or as above, but with symlink, work?
Qt5.3 no longer includes QtWebKit, which should now be built separately.
The WebKit package can be downloaded from the Qt Downloads website, via the separate packages repository: link for 5.3.2
This can then be installed by appropriately setting environment variables such that the relevant (Qt5.3.2) qmake is first in the path, then from the expanded source directory, typing:
qmake
make -jN (with N make jobs)
(sudo, if appropriate) make install
The download is approximately 50MB.
Edit: It's also worth noting that if your Bison version is 3.x, then you might not be able to build the snapshot for QtWebKit. Instead download from the development repositories, to avoid an error looking something like: link to bug report
g++ -c [...] -o .obj/release-shared/generated/glslang_tab.o generated/glslang_tab.cpp
generated/glslang_tab.cpp: In function 'int yyparse(TParseContext*)':
generated/glslang_tab.cpp:1785:30: error: too few arguments to function 'int yylex(YYSTYPE*, void*)'
yychar = yylex (&yylval);
^
generated/glslang_tab.cpp:279:12: note: declared here
extern int yylex(YYSTYPE* yylval_param, void* yyscanner);

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.

How a recent version of GCC (4.6) could be used together with Qt under Mac OS?

My problem is related to the one discussed here:
Is there a way that OpenMP can operate on Qt spanwed threads?
Upon trying to run my Qt-based program under Mac OS that has an OpenMP clause in a secondary thread, it crashed. After browsing through the web, now I understand that it is caused by a bug in the rather old version (4.2) of gcc supplied by Apple.
Then I downloaded the latest 4.6 version of gcc from http://hpc.sourceforge.net and tried to compile the project, but I got the following errors from g++ compiler:
unrecognized option ‘-arch’
unrecognized option ‘-Xarch_x86_64’
I learned that this is because these are options, which can be only interpreted by the custom-configured Apple-gcc compiler, but not by standard gcc.
Could anybody please help me could I overcome this issue and configure g++ 4.6 to use with Qt in order to get a bug-free OpenMP support? I admit that I'm a newbie under Mac OS platform with regard to compilers and programming and would like to port my code from Visual Studio-Qt environment.
Many thanks in advance!
If you aren't afraid of messing with your Qt installation, then change the QMAKE_CFLAGS_X86_64 entry in ~/QtSDK/Desktop/Qt/4.8.1/gcc/mkspecs/common/g++-macx.conf.
Replace ‘-Xarch_x86_64’ with ‘-arch x86_64’.
You can use your non-Apple gcc v4.6 and compile a binary for each architecture you want to build (use --target=${ARCH} should be fine for i386 and x86_64). Then once you have a binary for each of the architectures use lipo like so:
lipo -create -arch i386 binary_32bit -arch x86_64 binary_64bit -output binary_universal
This will create a fat binary (aka universal binary) named binary_universal from binary_32bit and binary_64bit.
Or you could use clang/llvm instead of gcc, which probably won't have the bug you described and (if supplied via Apple's developer tools) should be able to compile universal binaries directly.
You should run qmake woth corresponding -spec option, for example, to use gcc46 on freebsd it is needed to run qmake so:
qmake --spec=freebsd-g++46
Lipo can indeed be used to put multiple object files together into a "fat" object file, in fact it turns out this is just what apple's compiler does. Their GCC compiler is actually a driver that maps various architectures to the appropriate compiler for the architecture and then mashes the objects together using lipo.
see: http://lists.macosforge.org/pipermail/macports-dev/2011-September/016210.html
Here is the source file for that driver:
http://opensource.apple.com/source/gcc/gcc-5666.3/driverdriver.c
All one needs to do to get a new version of GCC to honor the -arch flag is to modify this driver and get it to point to a script wrapper for your version of gcc that adds the appropriate flags for the given architecture and then passes all the rest of the arguments. Something like this:
#!/bin/sh
/opt/local/bin/gcc-mp-4.6 -m32 $#
and
#!/bin/sh
/opt/local/bin/gcc-mp-4.6 -m64 $#
Here is a link that talks about how to do it, and provides a cmake project to easily get the macports version of GCC fixed up and supporting the -arch flag for the two intel architectures:
http://thecoderslife.blogspot.com/2015/07/building-with-gcc-46-and-xcode-4.html

Resources