I can't find a way to compile the following test code under Linux (part of a program developed for Mac)
#include<GL/glui.h>
void test(){
const char *name
GLint uni_loc,x,y ;
GLuint id;
glVertex2i( x, y);
uni_loc = ::glGetUniformLocation(id, name) ;
}
I tried to compile it with:
g++ -c test.cpp -lglut -lGL -lGLU
g++ -c -lglut -lGL -lGLU test.cpp
I get a linker error for the glGetUniformLocation function:
'::glGetUniformLocation' has not been declared
But don't know how to resolve it. I have no knowledge of openGl and get completely lost between the different implementations. I found the definition of the function in
/usr/include/GL/gl_mangle.h
/usr/include/GL/glew.h
/usr/include/GL/glext.h
Could it be that I have the wrong version of GL?
I have the following packages installed:
freeglut3 freeglut3-dev libglew1.5 libglew1.5-dev libglu1-mesa libglu1-mesa-dev libgl1-mesa-glx libgl1-mesa-dev mesa-common-dev
and gcc version 4.7.2 (Debian 4.7.2-5).
A portable way to get the functions defined in an extension is to use an extension wrapper like GLEW. A less robust way is to define GL_GLEXT_PROTOTYPES before including "GL/gl.h" and "GL/glext.h".
Related
I built and installed llvm/clang-3.7 from source on my Ubuntu Linux system (I'm building from source because my development environment at work does not have apt-get available). The gcc version is 4.8.2. I followed the clang build instructions at http://clang.llvm.org/get_started.html, and everything worked fine (mkdir build; cd build; cmake -G "Unix Makefiles" ../llvm; make; make install). However, I'm now finding that a program to test Block_copy fails to compile. The program is auto-generated by autoconf when I try to build gnustep-base. The part that fails is:
int
main ()
{
return _Block_copy ();
;
return 0;
}
My compile command is:
clang -o conftest -m64 -march=opteron -mno-3dnow -ggdb -O2 -Wall -I/home/build/GNUstep/Local/Library/Headers -I/home/build/GNUstep/Local/Library/Headers -I/home/build/GNUstep/System/Library/Headers -fgnu-runtime -x objective-c -m64 -L/home/build/GNUstep/Local/Library/Libraries -L/home/build/GNUstep/Local/Library/Libraries -L/home/build/GNUstep/System/Library/Libraries conftest.c -lrt -ldl -lpthread -rdynamic -m64 -fgnu-runtime -L/home/build/GNUstep/Library/Libraries -L/home/build/GNUstep/Local/Library/Libraries -L/home/build/GNUstep/System/Library/Libraries -lobjc -lm
Do I need to build clang with a special option to enable blocks, or should I be linking with another library?
Do I need to build clang with a special option to enable blocks
No. But you may need -fblocks option using the clang binary.
-fblocks
Enable the "Blocks" language feature.
should I be linking with another library?
AFAIK, Yes.
_Block_copy is a part of BlocksRuntime.
BlocksRuntime Block.h
BlocksRuntime runtime.c
Have you compiled compiler-rt? It includes BlocksRuntime. The document explains how to build compiler-rt.
I'm trying to compile a simple test program using static OpenCV libraries that have been compiled using an ARM compiler. But when I try to compile it with the command
$arm-linux-gnueabihf-g++ `pkg-config --static opencv` -I/usr/local/include -L<path to static libary> -lopencv_imgproc -lopencv_core ARMtest2.cpp -o ARMtest2
This gives
/tmp/ccxNeUbK.o: In function main':
ARMtest2.cpp:(.text+0x8a): undefined reference tocv::Mat::ones(int, int, int)'
/tmp/ccxNeUbK.o: In function cv::Mat::~Mat()':
ARMtest2.cpp:(.text._ZN2cv3MatD2Ev[_ZN2cv3MatD5Ev]+0x20): undefined reference tocv::fastFree(void*)'
/tmp/ccxNeUbK.o: In function cv::Mat::release()':
ARMtest2.cpp:(.text._ZN2cv3Mat7releaseEv[_ZN2cv3Mat7releaseEv]+0x30): undefined reference tocv::Mat::deallocate()'
collect2: error: ld returned 1 exit status
The code itself is just some simple test code that prints a Mat type variable.
I compiled the static OpenCV library with cmake-gui. I selected UNIX Makefile and then selected 'specify options for cross-compiling' where I gave the path to the ARM (arm-linux-gnueabihf) gcc and g++ compiler. Then I unticked BUILD_SHARED_LIB so it compiled static libraries. It seemed to compile fine without errors. After that I did make & sudo make install.
I also tried it with shared libraries and that worked fine on the ARM board (once I copied the libraries to the board and exported the library path).
The static .a files landed nicely in the build folder. Apparently it can also find it when I -L link to it. I have tried reversing the order of the libraries, but to no avail.
So I'm a bit at a loss what is going wrong.
I solved it. Using the normal --static pkg-config command to compile with OpenCV libraries;
`pkg-config --libs --static opencv`
Of course I installed the static libraries also to the folder /usr/local/lib where libraries get installed first. But still i don't know what I missed in the command line I tried to use. I had a look in the config file /usr/local/lib/pkgconfig/opencv.pc
Here is whats in it:
# Package Information for pkg-config
prefix=/usr/local
exec_prefix=${prefix}
libdir=
includedir_old=${prefix}/include/opencv
includedir_new=${prefix}/include
Name: OpenCV
Description: Open Source Computer Vision Library
Version: 2.4.9
Libs: ${exec_prefix}/lib/libopencv_calib3d.so ${exec_prefix}/lib/libopencv_contrib.so ${exec_prefix}/lib/libopencv_core.so ${exec_prefix}/lib/libopencv_features2d.so ${exec_prefix}/lib/libopencv_flann.so ${exec_prefix}/lib/libopencv_gpu.so ${exec_prefix}/lib/libopencv_highgui.so ${exec_prefix}/lib/libopencv_imgproc.so ${exec_prefix}/lib/libopencv_legacy.so ${exec_prefix}/lib/libopencv_ml.so ${exec_prefix}/lib/libopencv_nonfree.so ${exec_prefix}/lib/libopencv_objdetect.so ${exec_prefix}/lib/libopencv_ocl.so ${exec_prefix}/lib/libopencv_photo.so ${exec_prefix}/lib/libopencv_stitching.so ${exec_prefix}/lib/libopencv_superres.so ${exec_prefix}/lib/libopencv_ts.a ${exec_prefix}/lib/libopencv_video.so ${exec_prefix}/lib/libopencv_videostab.so -lrt -lpthread -lm -ldl
Cflags: -I${includedir_old} -I${includedir_new}
I believe this is what is being called with the pkg-config <--something_or_other> opencv line.
And saw some other things that probably get linked when compiling -lrt -lpthread -lm -ldl Not really sure though as I tried it ina normal command line and I apparently still missed somethings.
But it worked, so didn't really bother too much with it much further :)
In your command:
*$arm-linux-gnueabihf-g++ `pkg-config --static opencv` -I/usr/local/include -L<path to static libary> -lopencv_imgproc -lopencv_core ARMtest2.cpp -o ARMtest2*
The cflags was missing.
Try with:
$arm-linux-gnueabihf-g++ `pkg-config --cflags --static opencv` -I/usr/local/include -L<path to static cross-compiled libary> -lopencv_imgproc -lopencv_core ARMtest2.cpp -o ARMtest2
Assuming here that your cross-compiled headers are saved in /usr/local/include (as you specified).
I successfully ran sudo apt-get install libncurses5-dev
Within my Eclipse window I then try to build the following HelloWord.cpp program:
#include <ncurses.h>
int main()
{
initscr(); /* Start curses mode */
printw("Hello World !!!"); /* Print Hello World */
refresh(); /* Print it on to the real screen */
getch(); /* Wait for user input */
endwin(); /* End curses mode */
return 0;
}
I get the following error:
Invoking: GCC C++ Linker
g++ -m32 -lncurses -L/opt/lib -o "Test_V" ./src/curseTest.o ./src/trajectory.o ./src/xJus-epos.o -lEposCmd
/usr/bin/ld: cannot find -lncurses
collect2: error: ld returned 1 exit status
make: *** [Test_V] Error 1
It looks like the compiler is searching for the ncurses library and can't find it? I checked /usr/lib and the library does not exist there so do I need to manually link the ncurses library there - I thought the get-apt installer would automatically do this?
g++ HelloWorld.cpp -lncurses -o HelloWolrd
If you have a 32-bit machine, gcc compile m32 auto. If you have a 64-bit machine and you want to compile 32bits you
Your arguments are not in the correct order. You must specify all source files first and then linker search directories before specifying the libraries to link with. Your command should be like this:
g++ HelloWorld.o -L/opt/lib -lncurses -o HelloWorld
Taken from comment by #ChrisDodd:
Your options are in the wrong order -- -L must be BEFORE -l and both must be after all .o
I have an autotools project that compiles just fine on the Mac, but under Linux (Ubuntu 12.04.1 LTS) the command lines passed to gcc have the libraries out of order relative to the object files. For example, autotools generates the following command to compile my code, a single file named test.c into a binary named test:
gcc -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -O2 -lglib-2.0 -o test test-test.o
This command line fails with:
/home/user/glib-test/test.c:4: undefined reference to `g_malloc`
/home/user/glib-test/test.c:5: undefined reference to `g_free`
However, if I compile from the command line and switch it up so the library reference is after the object files it works just fine:
gcc -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -O2 -o test test-test.o -lglib-2.0
The challenge is that I can't figure out how to force Autotools to generate the command line in the right order. For the sake of clarity, I've reproduced the simple test case here. First up is configure.ac:
dnl Process this file with autoconf to produce a configure script.
AC_PREREQ(2.59)
AC_INIT(glib-test, 1.0)
AC_CANONICAL_SYSTEM
AM_INIT_AUTOMAKE()
AC_PROG_CC
AM_PROG_CC_C_O
PKG_CHECK_MODULES(GLIB, glib-2.0 > 2.0)
AC_CONFIG_FILES(Makefile)
AC_OUTPUT
Next is the simple Makefile.am:
CFLAGS=-Wall
bin_PROGRAMS=test
test_CFLAGS=$(GLIB_CFLAGS)
test_LDFLAGS=$(GLIB_LIBS)
test_SOURCES=test.c
Finally, the source code to this minimal test case, test.c:
#include <glib.h>
int main(int argc, char **argv) {
gchar *foo = g_malloc(100);
g_free(foo);
return 0;
}
Compilation is then achieved using the following series of commands:
touch NEWS README AUTHORS ChangeLog
aclocal
autoconf
automake --add-missing
./configure
make
I should be clear, I understand why my code won't compile, I'm just wondering how to get automake to put the libraries at the end of the command line so gcc will execute and link properly. It should be noted that gcc on Mac OS X Lion doesn't seem to have this problem.
The solution turned out to be the difference between LDFLAGS and LDADD. In short LDFLAGS is added before the object files on the command line and LDADD is added afterwards. Thus, changing Makefile.am to the following solved the problem:
CFLAGS=-Wall
bin_PROGRAMS=test
test_CFLAGS=$(GLIB_CFLAGS)
test_LDADD=$(GLIB_LIBS)
test_SOURCES=test.c
It only took tracking down a GCC developer at work to solve. Also, this example I provided is rather poor because test has a defined meaning in some contexts of autotools.
I solved a similar problem. The ./configure script in question was unable to complete a check for presence of a function due to a missing symbol. If I added the correct library to $LDFLAGS or such like, it was added before the .c file and the library was ignored.
The names of functions to check are first added to ac_func_list and then there is a loop in the body of the ./configure that for each of them calls ac_fn_c_check_func () and that in turns calls ac_fn_c_try_link ()
the checking function ac_fn_c_try_link () uses a command of this pattern:
ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS \
$LDFLAGS conftest.$ac_ext $LIBS >&5'
$LDADD is completely ignored here. Therefore the only solution here is to add the -l flags to variable $LIBS.
I am trying to compile OpenCV with icc on Linux, in order to profile the execution with intel tools.
I installed the last version of icc with default options. I tried both "user" (icc is installed in my home) and "sudo" (icc is intalled in /opt) installs. The version of icc is 11.1 20090630
I also thought to source iccvars.sh, adding needed paths to PATH and LD_LIBRARY_PATH
I also tried several versions of OpenCV:
- the main one: pre1.1. configure does not recognize icc at all
- the 'latest_tested_snapshot' and the 'trunk' versions: icc is well recognized by configure (--enable-openmp produce -openmp option, and not -fopenmp)
When I make, everything seems all right until the middle of the compilation. Then come a lot of warnings (maybe a hundred) always about 'operator'. Here an example:
../include/opencv/cxcore.hpp(335): warning #597: "cv::Size_<_Tp>::operator cv::Size_<float>() const [with
_Tp=float]" will not be called for implicit or explicit conversions
operator Size_<float>() const;
^
detected during instantiation of class "cv::Size_<_Tp> [with _Tp=float]" at line 394
And finnally the error:
/bin/bash ../../../libtool --tag=CXX --mode=compile icpc -DHAVE_CONFIG_H -I. -I../../.. -I../../../include/opencv -I. -DCV_NO_BACKWARD_COMPATIBILITY -fPIC -I/usr/include/python2.6 -g -O2 -MT _highgui_la-pyhelpers.lo -MD -MP -MF .deps/_highgui_la-pyhelpers.Tpo -c -o _highgui_la-pyhelpers.lo `test -f 'pyhelpers.cpp' || echo './'`pyhelpers.cpp
_ml.cpp(36134): error: argument of type "uchar={unsigned char} *" is incompatible with parameter of type "int *"
result = (int)(arg1)->get_ord_var_data(arg2,arg3,arg4,arg5,(float const **)arg6,(uchar const **)arg7);
^
_ml.cpp(36134): error: argument of type "const uchar={unsigned char} **" is incompatible with parameter of type "const int **"
result = (int)(arg1)->get_ord_var_data(arg2,arg3,arg4,arg5,(float const **)arg6,(uchar const **)arg7);
^
compilation aborted for _ml.cpp (code 2)
make[4]: *** [_ml_la-_ml.lo] Erreur 1
I anyone succeded to compile OpenCV with icc, let me know!
Ok, I finally compiled OpenCV with ICC. OpenCV is close to Intel, as Intel is highly involved in this project. Since version 1.1, OpenCV is supposed to natively support icc compiler. When you specify CC=icc in configure, there are some subtle changes as the -fopenmp (gcc style) in transformed into -openmp (icc style). However, between the release of OpenCV 1.1 (which is the latest stable) and now, icc has evolved. I think it used to compile with previous version of icc.
It comile with the latest tested version on svn:
https://opencvlibrary.svn.sourceforge.net/svnroot/opencvlibrary/tags/latest_tested_snapshot/opencv/
As the svn evolve, it could change, but at this time (27 august) it works. The warnings are still here (don't be affraid, there are a lot). Here my configure bash line:
./configure --prefix=/home/user/opencv/icc CC=icc CXX=icpc --enable-openmp --disable-apps --disable-optimization --disable-sse
I disabled optimizations and sse instructions, as it generates some conflicts with icc.
Your issue may result from using a different version from ICC used to create that library. You must ask the library provider which version to use.