I am trying to use opengl to render objects. Although the simple tutorial example http://www.videotutorialsrock.com/opengl_tutorial/get_opengl_setup_linux/text.phpcompiles without error when I attempt to execute the program it crashes i.e. the dreaded segmentation fault.
System
Suse Linux 11.2 64 bit
g++ (SUSE Linux) 4.4.1 [gcc-4_4-branch revision 150839]
Eclipse IDE Build id: 20100218-1602
according to yast 64bit freeglut and freeglut-devel are installed:
090301-3.1
libglut.so.3()(64bit)
mesaglut
freeglut = 090301-3.1
freeglut(x86-64) = 090301-3.1
Is this a 64 bit vs 32 bit issue? I have had the same example program working under suse 11.1 32bit.
Any help would be appreciated
Okay .Car has been pushed back up the hill and loose nut tightened.
Below is output from gdb:
~/workspaceNew/cubetest/Default> gdb
GNU gdb (GDB) SUSE (6.8.91.20090930-2.4)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) run ./cubetest
Starting program: /home/mark/workspaceNew/cubetest/Default/cubetest ./cubetest
Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2
Try: zypper install -C "debuginfo(build-id)=591af1afa33f255704fb6a60859b93d00e205302"
Missing separate debuginfo for /usr/lib64/libglut.so.3
Try: zypper install -C "debuginfo(build-id)=768ca903dcb7f43b3a9f4cdc368d9469e44c14f7"
Missing separate debuginfo for /usr/lib64/libGLU.so.1
Try: zypper install -C "debuginfo(build-id)=a76155345771ffa204fc8a1cf63b3eca7ce1ae86"
Missing separate debuginfo for /usr/lib64/libstdc++.so.6
Try: zypper install -C "debuginfo(build-id)=62220ad5c8941afb5d332c0c47d32f8beec8ac50"
Missing separate debuginfo for /lib64/libm.so.6
Try: zypper install -C "debuginfo(build-id)=57fc1891d8d9f419fb8c7fc06a8285563b53a47e"
Missing separate debuginfo for /lib64/libgcc_s.so.1
Try: zypper install -C "debuginfo(build-id)=0206e11fa8ca0db0633073adcbf1349a7871e1dc"
Missing separate debuginfo for /lib64/libc.so.6
Try: zypper install -C "debuginfo(build-id)=b5ded0f18b9b11c5cd6b26387426ead562c332f8"
Missing separate debuginfo for /usr/lib64/libGL.so.1
Try: zypper install -C "debuginfo(build-id)=cb5a2f35ed226cb1c92f063d03b204ec24b100a6"
Missing separate debuginfo for /usr/lib64/libX11.so.6
Try: zypper install -C "debuginfo(build-id)=5fa84adc30db95abcbaea20ed7ec1c8dd94dfff2"
Missing separate debuginfo for /usr/lib64/libXxf86vm.so.1
Try: zypper install -C "debuginfo(build-id)=4ffef26febce96a31b2d5df10538bb6dba112e3b"
Missing separate debuginfo for /usr/lib64/libXext.so.6
Try: zypper install -C "debuginfo(build-id)=79d5f89d13f43ff26518ec8dd46fecfad911f968"
Missing separate debuginfo for /usr/lib64/libXdamage.so.1
Try: zypper install -C "debuginfo(build-id)=650d88fdf900daadd8ba1c9134c21b4e68b560bc"
Missing separate debuginfo for /usr/lib64/libXfixes.so.3
Try: zypper install -C "debuginfo(build-id)=6495446f04c2f9a4fa3021f7322d6f12c4017305"
Missing separate debuginfo for /usr/lib64/libdrm.so.2
Try: zypper install -C "debuginfo(build-id)=dc7d692fb4a36fa25fc513b2e36a614f5e4efc48"
Missing separate debuginfo for /lib64/libpthread.so.0
Try: zypper install -C "debuginfo(build-id)=7bcbabc9da24424f1f5ef7be77b575fd3d796288"
[Thread debugging using libthread_db enabled]
Missing separate debuginfo for /lib64/libdl.so.2
Try: zypper install -C "debuginfo(build-id)=44e66ebae672563bd496f290e08d316bc3bf0ac7"
Missing separate debuginfo for /usr/lib64/libxcb.so.1
Try: zypper install -C "debuginfo(build-id)=54a77c10d44b40080d6d8e65d277ccb7ab2a5b4a"
Missing separate debuginfo for /lib64/librt.so.1
Try: zypper install -C "debuginfo(build-id)=c663e79551b37d4c0c9bc93b252b917bfdedb150"
Missing separate debuginfo for /usr/lib64/libXau.so.
Try: zypper install -C "debuginfo(build-id)=72341bb9d8a1ad2ca2bbced007f3a785121aac28"
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7bbeaf7 in fgOpenWindow () from /usr/lib64/libglut.so.3
(gdb) bt
#0 0x00007ffff7bbeaf7 in fgOpenWindow () from /usr/lib64/libglut.so.3
#1 0x00007ffff7bbd0fc in fgCreateWindow () from /usr/lib64/libglut.so.3
#2 0x00007ffff7bbe3d2 in glutCreateWindow () from /usr/lib64/libglut.so.3
#3 0x0000000000402c45 in main (argc=2, argv=<value optimized out>) at ../cube/main.cpp:191
Well, all I can say is that the example compiles and runs on Ubuntu 10.04 x64. I did have to add -lGLU to LIBS in the makefile, but since it already compiles for you, I guess that's not very helpful.
Your debug info does not provide a lot of insight; try installing -dbg packages for the relevant libraries.
Related
I'm trying to use valgrind on a program which is the output of the make command using this makefile:
# Intlist makefile
P = intlist
C = g++
F = -m32 -g -O0 -Wall
O = IntListTest.o IntList.o
$(P): $(O)
$(C) $(F) -o $(P) $(O)
IntListTest.o: IntListTest.cpp IntList.h
$(C) $(F) -c IntListTest.cpp
IntList.o: IntList.cpp IntList.h
$(C) $(F) -c IntList.cpp
clean:
rm $(P) $(O)
When I run valgrind on intlist, it generates this:
==130929== Memcheck, a memory error detector
==130929== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==130929== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==130929== Command: intlist
==130929==
valgrind: Fatal error at startup: a function redirection
valgrind: which is mandatory for this platform-tool combination
valgrind: cannot be set up. Details of the redirection are:
valgrind:
valgrind: A must-be-redirected function
valgrind: whose name matches the pattern: strlen
valgrind: in an object with soname matching: ld-linux.so.2
valgrind: was not found whilst processing
valgrind: symbols from the object with soname: ld-linux.so.2
valgrind:
valgrind: Possible fixes: (1, short term): install glibc's debuginfo
valgrind: package on this machine. (2, longer term): ask the packagers
valgrind: for your Linux distribution to please in future ship a non-
valgrind: stripped ld.so (or whatever the dynamic linker .so is called)
valgrind: that exports the above-named function using the standard
valgrind: calling conventions for this platform. The package you need
valgrind: to install for fix (1) is called
valgrind:
valgrind: On Debian, Ubuntu: libc6-dbg
valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo
valgrind:
valgrind: Note that if you are debugging a 32 bit process on a
valgrind: 64 bit system, you will need a corresponding 32 bit debuginfo
valgrind: package (e.g. libc6-dbg:i386).
valgrind:
valgrind: Cannot continue -- exiting now. Sorry.
I feel like there's something wrong with my makefile, but I'm not sure what it is. Any ideas are greatly appreciated. However, This takes place on a college-owned server where I don't have permission to install anything, so that isn't a solution in my case.
You are building a 32bit executable (the -m32 option in your compile/link lines) but from the output valgrind provides, you don't have all the support libraries available to run valgrind on a 32bit executable.
Do you really need your program to be 32bit? If not the simplest thing to do is remove the -m32 option and clean and rebuild everything.
If you really have to have a 32bit binary then read the output valgrind provides above carefully to determine what extra 32bit libraries you're missing and need to install.
When I make my program with -larmadillo, I get an executable which wants two versions of it:
$ ldd ./a.out | grep armadillo
$ libarmadillo.so.7 => /usr/lib/x86_64-linux-gnu/libarmadillo.so.7 (0x00007fd5e29a0000)
$ libarmadillo.so.4 => not found
Can anyone point me in the right direction? This isn't making any sense to me!
Background: I initially installed libarmadillo via sudo apt-get install libarmadillo-dev, then I realised I needed to build it with a specific parameter (64 bit words enabled), so I uninstalled it via sudo apt-get remove libarmadillo-dev then downloaded the latest version, configured and make/make installed it. Presumably I only have one version of libarmadillo on my system - I do not see any old libraries in the usual places.
Thanks
EDIT:
My Makefile is:
CC= g++
CFLAGS= -Lcontrib/armadillo-7.400.1 -L/usr/include -Lcontrib/mlpack-2.0.1/build/lib -fpermissive -std=c++11 -O0 -g -Wall
LDFLAGS= -lmlpack -larmadillo
The verbose output of ldd is interesting, I think?
$ ldd -v ./a.out | grep armadillo
$ libarmadillo.so.7 => /usr/lib/x86_64-linux-gnu/libarmadillo.so.7 (0x00007fd5e29a0000)
$ libarmadillo.so.4 => not found
$ /usr/lib/x86_64-linux-gnu/libarmadillo.so.7:
The latter section (which lists dependences for libarmadillo.so.7) is:
/usr/lib/x86_64-linux-gnu/libarmadillo.so.7:
ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
There is no mention of the 'missing' libarmadillo.so.4 in the verbose output, which I find quite strange.
I think I've figured it out, but the results aren't particularly comforting.
I reinstalled mlpack which has a dependency into libarmadillo, and then rebuilt, and the requirement for libarmadillo.so.4 is gone.
The process that I think happened is I:
Installed old version of libarmadillo
Installed libmlpack configured with old version
Realised I needed a newer version of libarmadillo, so uninstalled old libarmadillo and installed a new one.
Rebuilt mlpack using cmake / make but did not make install
Made my executable
Now have an executable which is is pointing to mlpack which requires the old libarmadillo, but it also points to the new libarmadillo
Once I make install the rebuilt mlpack, my problems go away. I am surprised that the verbose output of ldd didn't flag any reason as to why it was looking for libarmadillo.so.4 (namely that there was a dependency from libmlpack on the old library) - should ldd be able to do this?
Sometimes linux creates many symbolic link of one dynamic library. I don't know why but no matter as there is no inconvenient for that. So, you can just create a new symbolic link like this : ln -s path_to_my_so_lib/my_lib.so /usr/lib/x86_64-linux-gnu/libarmadillo.so.4
I have been trying to compile a simple hello world program in c++ using clang. Now in the past I have been able to do this using the command:
clang -lc++ hello.cpp -o hello
When I try this I get the error:
/usr/bin/ld: cannot find -lc++
Clang: error : linker command failed with exit code 1
If I use g++ it compiles without errors. Why is this problem occurring with clang?
You need to install libc++ library.
Try if are using ubuntu:
sudo bash -c "cat >> /etc/apt/sources.list" << LLVMAPT
# LLVM
deb http://llvm.org/apt/trusty/ llvm-toolchain-trusty main
deb-src http://llvm.org/apt/trusty/ llvm-toolchain-trusty main
# 3.5
deb http://llvm.org/apt/trusty/ llvm-toolchain-trusty-3.5 main
deb-src http://llvm.org/apt/trusty/ llvm-toolchain-trusty-3.5 main
# 3.6
deb http://llvm.org/apt/trusty/ llvm-toolchain-trusty-3.6 main
deb-src http://llvm.org/apt/trusty/ llvm-toolchain-trusty-3.6 main
LLVMAPT
wget -O - http://llvm.org/apt/llvm-snapshot.gpg.key|sudo apt-key add -
sudo apt-get update -y
sudo apt-get install -y clang-3.6 lldb-3.6 libc++-dev libc++abi-dev
If the script above doesnt work or you do not use ubuntu then please check this websites to download that library:
http://libcxx.llvm.org/
http://libcxx.llvm.org/docs/BuildingLibcxx.html
Clang compiles C language and Clang++ compiles C++. Those are different languages, so you need a separate compiler for each of them.
Some time ago I was having trouble with this as well. I tried linking loads of libraries (-lstdc++ etc), building stdlib from source, etc, but nothing worked. This was a judge problem until I realized that I had to use clang++.
So you too, you need clang++, not clang.
here is my CPP program
#include <iostream>
int main(int argc, char *argv[]){
return 0;
}
compiling and executing this, causes a seg fault:
[18:08 ~] > g++ test.cpp
[18:09 ~] > ./a.out
Segmentation fault
Does anybody have an idea about this issue please?
Thanks a lot for your help.
Here are some details that might be useful:
[18:13 ~] > ldd a.out
linux-vdso.so.1 => (0x00007fff3fdff000)
libstdc++.so.6 => /usr/lib/gcc/x86_64-redhat-linux/3.4.6/libstdc++.so.6 (0x00007fc8f4a53000)
libm.so.6 => /lib64/libm.so.6 (0x00007fc8f47ce000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc8f45b8000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc8f4225000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc8f4ca5000)
and also gdb:
[18:15 ~] > gdb ./a.out
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from ...done.
(gdb) run
Starting program: a.out
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7bd48ec in std::ios_base::Init::Init() () from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/libstdc++.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.107.el6.x86_64 libgcc-4.4.7-3.el6.x86_64
(gdb) bt
#0 0x00007ffff7bd48ec in std::ios_base::Init::Init() () from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/libstdc++.so.6
#1 0x0000000000400831 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/iostream:77
#2 0x0000000000400873 in global constructors keyed to main() () at test.cpp:7
#3 0x0000000000400976 in __do_global_ctors_aux ()
#4 0x00000000004005a3 in _init ()
#5 0x00007fffffffe448 in ?? ()
#6 0x0000000000400905 in __libc_csu_init ()
#7 0x00007ffff7385c70 in __libc_start_main () from /lib64/libc.so.6
#8 0x0000000000400659 in _start ()
(gdb)
g++
[10:14 ~] > g++ -v
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,f77 --disable-libgcj --host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-19.el6)
and last thing
[10:25 ~] > ls /usr/lib/gcc/x86_64-redhat-linux
3.4.6
Thank you.
So apparently your problem is that your g++ installation is broken. I see from the messages that you have RHEL6, but somehow have version 3.4.6 of libstdc++.
My RHEL6 system has version 4.4.6 of gcc, libstdc++, etc. I assume that this older version of libstdc++ is related to your problem.
What versions do you have installed of gcc, g++, and libstdc++? From the other messages, it looks like you have 4.4.7, but do you happen to have multiple versions or mixed versions?
rpm -q gcc g++ libstdc++
Also, what other directories do you have under /usr/lib/gcc/x86_64-redhat-linux?
ls /usr/lib/gcc/x86_64-redhat-linux
i think that you miss something while installing g++
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.107.el6.x86_64 libgcc-4.4.7-3.el6.x86_64
I need to use C++ 11, so I updated my GCC from 4.1 to 4.7. I compile the source code and make install it. gcc -version will show 4.7.0 (everything looks good). I compiled my program using:
g++ -O2 -std=c++11 -o wdSer wdSer.cpp
After that I run my program ./wdSer, there are some information as follows:
./wdSer: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./wdSer)
./wdSer: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.5' not found (required by ./wdSer)
./wdSer: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.10' not found (required by ./wdSer)
./wdSer: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./wdSer)
Who can tell me how to solve it?
First try this:
LD_LIBRARY_PATH=/usr/local/lib64:$LD_LIBRARY_PATH ./wdSer
/usr/local/lib64 is the default library directory for a 64bit build of gcc .
Setting LD_LIBRARY_PATH to contain that directory tells the linker to look in that directory for library files.
If that does not work, look at the output of g++ -v
On my system, I get this:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.8.2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8.2/configure --prefix=/usr/local/gcc-4.8.2 --with-isl=/usr/local/isl-0.12.2 --with-cloog=/usr/local/cloog-0.18.1
Thread model: posix
gcc version 4.8.2 (GCC)
In this output, you are looking for a directory following --prefix. Add /lib64 to the end of that prefix, and you'll have your library directory.
On my system, it's /usr/local/gcc-4.8.2 , so I need the linker to look in /usr/local/gcc-4.8.2/lib64 to find my libstdc++ .
So I run programs like this:
LD_LIBRARY_PATH=/usr/local/gcc-4.8.2/lib64:$LD_LIBRARY_PATH ./a.out
If you don't want to set your LD_LIBRARY_PATH before running your programs, you should build them with -Wl,-rpath= , like this:
$ g++ -std=c++11 -o wdSer -Wl,-rpath=/usr/local/lib64/ wdSer.cc
You can use ldd on a program to see where the shared libraries it is linked to are found:
$ ldd a.out
linux-vdso.so.1 => (0x00007fff8a506000)
libstdc++.so.6 => /usr/local/gcc-4.8.2/lib64/libstdc++.so.6 (0x00007fa3c6aaf000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa3c6811000)
libgcc_s.so.1 => /usr/local/gcc-4.8.2/lib64/libgcc_s.so.1 (0x00007fa3c67fa000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa3c646f000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa3c6bbc000)
Here, a.out is a program I built with the option -Wl,-rpath=/usr/local/gcc-4.8.2/lib64 , so the linker looks there first, and finds the libstdc++ that goes with my gcc 4.8.2 install.
Please see the documention for the -v flag: http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Overall-Options.html#Overall-Options (and search for -v )
the -Wl flag : http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Link-Options.html#Link-Options (and scroll down to the bottom)
and the -rpath flag: https://sourceware.org/binutils/docs-2.24/ld/Options.html#Options (and search for -rpath)