Search Results

Search found 642 results on 26 pages for 'ld so'.

Page 12/26 | < Previous Page | 8 9 10 11 12 13 14 15 16 17 18 19  | Next Page >

  • Minimal assembler program for CP/M 3.1 (z80)

    - by Andrew J. Brehm
    I seem to be losing the battle against my stupidity. This site explains the system calls under various versions of CP/M. However, when I try to use call 2 (C_WRITE, console output), nothing much happens. I have the following code. ORG 100h LD E,'a' LD C,2 CALL 5 CALL 0 I recite this here from memory. If there are typos, rest assured they were not in the original since the file did compile and I had a COM file to start. I am thinking the lines mean the following: Make sure this gets loaded at address 100h (0h to FFh being the zero page). Load ASCII 'a' into E register for system call 2. Load integer 2 into C register for system call 2. Make system call (JMP to system call is at address 5 in zero page). End program (Exit command is at address 0 in zero page). The program starts and exits with no problems. If I remove the last command, it hangs the computer (which I guess is also expected and shows that CALL 0 works). However, it does not print the ASCII character. (But it does print an extra new line, but the system might have done that.) How can I get my CP/M program to do what the system call is supposed to do? What am I doing wrong?

    Read the article

  • g++ Linking Error on Mac while compiling FFMPEG

    - by Saptarshi Biswas
    g++ on Snow Leopard is throwing linking errors on the following piece of code test.cpp #include <iostream> using namespace std; #include <libavcodec/avcodec.h> // required headers #include <libavformat/avformat.h> int main(int argc, char**argv) { av_register_all(); // offending library call return 0; } When I try to compile this using the following command g++ test.cpp -I/usr/local/include -L/usr/local/lib \ -lavcodec -lavformat -lavutil -lz -lm -o test I get the error Undefined symbols: "av_register_all()", referenced from: _main in ccUD1ueX.o ld: symbol(s) not found collect2: ld returned 1 exit status Interestingly, if I have an equivalent c code, test.c #include <stdio.h> #include <libavcodec/avcodec.h> #include <libavformat/avformat.h> int main(int argc, char**argv) { av_register_all(); return 0; } gcc compiles it just fine gcc test.c -I/usr/local/include -L/usr/local/lib \ -lavcodec -lavformat -lavutil -lz -lm -o test I am using Mac OS X 10.6.5 $ g++ --version i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664) $ gcc --version i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664) FFMPEG's libavcodec, libavformat etc. are C libraries and I have built them on my machine like thus: ./configure --enable-gpl --enable-pthreads --enable-shared \ --disable-doc --enable-libx264 make && sudo make install As one would expect, libavformat indeed contains the symbol av_register_all $ nm /usr/local/lib/libavformat.a | grep av_register_all 0000000000000000 T _av_register_all 00000000000089b0 S _av_register_all.eh I am inclined to believe g++ and gcc have different views of the libraries on my machine. g++ is not able to pick up the right libraries. Any clue?

    Read the article

  • Error when linking C executable to OpenCV

    - by Ghilas BELHADJ
    I'm compiling OpenCV under Ubuntu 13.10 using cMake. i've already compiled c++ programs and they works well. now i'm trying to compile a C file using this cMakeLists.txt cmake_minimum_required (VERSION 2.8) project (hello) find_package (OpenCV REQUIRED) add_executable (hello src/test.c) target_link_libraries (hello ${OpenCV_LIBS}) here is the test.c file: #include <stdio.h> #include <stdlib.h> #include <opencv/highgui.h> int main (int argc, char* argv[]) { IplImage* img = NULL; const char* window_title = "Hello, OpenCV!"; if (argc < 2) { fprintf (stderr, "usage: %s IMAGE\n", argv[0]); return EXIT_FAILURE; } img = cvLoadImage(argv[1], CV_LOAD_IMAGE_UNCHANGED); if (img == NULL) { fprintf (stderr, "couldn't open image file: %s\n", argv[1]); return EXIT_FAILURE; } cvNamedWindow (window_title, CV_WINDOW_AUTOSIZE); cvShowImage (window_title, img); cvWaitKey(0); cvDestroyAllWindows(); cvReleaseImage(&img); return EXIT_SUCCESS; } it returns me this error whene running cmake . then make to the project: Linking C executable hello /usr/bin/ld: CMakeFiles/hello.dir/src/test.c.o: undefined reference to symbol «lrint@@GLIBC_2.1» /lib/i386-linux-gnu/libm.so.6: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status make[2]: *** [hello] Erreur 1 make[1]: *** [CMakeFiles/hello.dir/all] Erreur 2 make: *** [all] Erreur 2

    Read the article

  • Linker error: wants C++ virtual base class destructor

    - by jdmuys
    Hi, I have a link error where the linker complains that my concrete class's destructor is calling its abstract superclass destructor, the code of which is missing. This is using GCC 4.2 on Mac OS X from XCode. I saw http://stackoverflow.com/questions/307352/g-undefined-reference-to-typeinfo but it's not quite the same thing. Here is the linker error message: Undefined symbols: "ConnectionPool::~ConnectionPool()", referenced from: AlwaysConnectedConnectionZPool::~AlwaysConnectedConnectionZPool()in RKConnector.o ld: symbol(s) not found collect2: ld returned 1 exit status Here is the abstract base class declaration: class ConnectionPool { public: static ConnectionPool* newPool(std::string h, short p, std::string u, std::string pw, std::string b); virtual ~ConnectionPool() =0; virtual int keepAlive() =0; virtual int disconnect() =0; virtual sql::Connection * getConnection(char *compression_scheme = NULL) =0; virtual void releaseConnection(sql::Connection * theConnection) =0; }; Here is the concrete class declaration: class AlwaysConnectedConnectionZPool: public ConnectionPool { protected: <snip data members> public: AlwaysConnectedConnectionZPool(std::string h, short p, std::string u, std::string pw, std::string b); virtual ~AlwaysConnectedConnectionZPool(); virtual int keepAlive(); // will make sure the connection doesn't time out. Call regularly virtual int disconnect(); // disconnects/destroys all connections. virtual sql::Connection * getConnection(char *compression_scheme = NULL); virtual void releaseConnection(sql::Connection * theConnection); }; Needless to say, all those members are implemented. Here is the destructor: AlwaysConnectedConnectionZPool::~AlwaysConnectedConnectionZPool() { printf("AlwaysConnectedConnectionZPool destructor call"); // nothing to destruct in fact } and also maybe the factory routine: ConnectionPool* ConnectionPool::newPool(std::string h, short p, std::string u, std::string pw, std::string b) { return new AlwaysConnectedConnectionZPool(h, p, u, pw, b); } I can fix this by artificially making my abstract base class concrete. But I'd rather do something better. Any idea? Thanks

    Read the article

  • Splitting a C++ class into files now won't compile.

    - by vgm64
    Hi. I am teaching myself to write classes in C++ but can't seem to get the compilation to go through. If you can help me figure out not just how, but why, it would be greatly appreciated. Thank you in advance! Here are my three files: make_pmt.C #include <iostream> #include "pmt.h" using namespace std; int main() { CPMT *pmt = new CPMT; pmt->SetVoltage(900); pmt->SetGain(2e6); double voltage = pmt->GetVoltage(); double gain= pmt->GetGain(); cout << "The voltage is " << voltage << " and the gain is " << gain << "." <<endl; return 0; } pmt.C #include "pmt.h" using namespace std; class CPMT { double gain, voltage; public: double GetGain() {return gain;} double GetVoltage() {return voltage;} void SetGain(double g) {gain=g;} void SetVoltage(double v) {voltage=v;} }; pmt.h #ifndef PMT_H #define PMT_H 1 using namespace std; class CPMT { double gain, voltage; public: double GetGain(); double GetVoltage(); void SetGain(double g); void SetVoltage(double v); }; #endif And for reference, I get a linker error (right?): Undefined symbols: "CPMT::GetVoltage()", referenced from: _main in ccoYuMbH.o "CPMT::GetGain()", referenced from: _main in ccoYuMbH.o "CPMT::SetVoltage(double)", referenced from: _main in ccoYuMbH.o "CPMT::SetGain(double)", referenced from: _main in ccoYuMbH.o ld: symbol(s) not found collect2: ld returned 1 exit status

    Read the article

  • Boost::Thread linking error on OSX?

    - by gct
    So I'm going nuts trying to figure this one out. Here's my basic setup: I'm compiling a shared library with a bunch of core functionality that uses a lot of boost stuff. We'll call this library libpf_core.so. It's linked with the boost static libraries, specifically the python, system, filesystem, thread, and program_options libraries. This all goes swimmingly. Now, I have a little test program called test_socketio which is compiled into a shared library (it's loaded as a plugin at runtime). It uses some boost stuff like boost::bind and boost::thread, and it's linked again libpf_core.so (which has the boost libraries included remember). When I go to compile test_socketio though, out of all my plugins it gives me a linking error: [ Building test_socketio ] g++ -c -pg -g -O0 -I/usr/local/include -I../include test_socketio.cc -o test_socketio.o g++ -shared test_socketio.o -lpy_core -o test_socketio.so Undefined symbols: "boost::lock_error::lock_error()", referenced from: boost::unique_lock<boost::mutex>::lock() in test_socketio.o ld: symbol(s) not found collect2: ld returned 1 exit status And I'm going crazy trying to figure out why this is. I've tried explicitly linking boost::thread into the plugin to no avail, tried ensuring that I'm using the boost headers associated with the libraries linked into libpf_core.so in case there was a conflict there. Is there something OSX specific regarding boost that I'm missing? In my searching on google I've seen a number of other people get this error but no one seems to have come up with a satisfactory solution.

    Read the article

  • pthread_create followed by pthread_detach still results in possibly lost error in Valgrind.

    - by alesplin
    I'm having a problem with Valgrind telling me I have some memory possible lost: ==23205== 544 bytes in 2 blocks are possibly lost in loss record 156 of 265 ==23205== at 0x6022879: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==23205== by 0x540E209: allocate_dtv (in /lib/ld-2.12.1.so) ==23205== by 0x540E91D: _dl_allocate_tls (in /lib/ld-2.12.1.so) ==23205== by 0x623068D: pthread_create@@GLIBC_2.2.5 (in /lib/libpthread-2.12.1.so) ==23205== by 0x758D66: MTPCreateThreadPool (MTP.c:290) ==23205== by 0x405787: main (MServer.c:317) The code that creates these threads (MTPCreateThreadPool) basically gets an index into a block of waiting pthread_t slots, and creates a thread with that. TI becomes a pointer to a struct that has a thread index and a pthread_t. (simplified/sanitized): for (tindex = 0; tindex < NumThreads; tindex++) { int rc; TI = &TP->ThreadInfo[tindex]; TI->ThreadID = tindex; rc = pthread_create(&TI->ThreadHandle,NULL,MTPHandleRequestsLoop,TI); /* check for non-success that I've omitted */ pthread_detach(&TI->ThreadHandle); } Then we have a function MTPDestroyThreadPool that loops through all the threads we created and cancels them (since the MTPHandleRequestsLoop doesn't exit). for (tindex = 0; tindex < NumThreads; tindex++) { pthread_cancel(TP->ThreadInfo[tindex].ThreadHandle); } I've read elsewhere (including other questions here on SO) that detaching a thread explicitly would prevent this possibly lost error, but it clearly isn't. Any thoughts?

    Read the article

  • How to fix Ogre3d segfault with std::_Rb_tree_insert_and_rebalance ?

    - by Balázs Béla
    Hello all. I'm working on a 3d music visualizer using Ogre3d, basically it's a spectrum analizer, a lot like the old xmms plugin: (http)://www.youtube.com/watch?v=_6NKBiwYN24 It works well, the bars are drawn and updated, there are no framerate issues, but it crashes randomly. Sometimes it can run without problems, finish the song, other times it crashes instantly, other times the music just stops, without a crash. Here is the source code for the main class : https://github.com/balazsbela/OgreVisualizer/blob/master/src/VisualizerApplication.cpp#L221 Also the crashes seem to happen less often when I display the framerate overlay from Ogre samples. Would limiting the framerate help ? The crashes are seemingly random. Is it a performance issue ? Please help me out, I'm quite lost on this one, I also posted on Ogre3d forums but I received no responses. (http)://www.ogre3d.org/forums/viewtopic.php?f=2&t=63207 I also tried stackoverflow: (http)://stackoverflow.com/questions/5050147/how-to-fix-ogre3d-segfault-with-std-rb-tree-insert-and-rebalance Thank you. Backtrace: balazsbela@darknet:~/workspace/OgreVisualizer/Release$ gdb OgreVisualizer core GNU gdb (GDB) 7.2-debian 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 "i486-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/balazsbela/workspace/OgreVisualizer/Release/OgreVisualizer...done. [New Thread 17705] [New Thread 17702] [New Thread 17703] [New Thread 17700] Reading symbols from /usr/lib/libv4l/v4l1compat.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libv4l/v4l1compat.so Reading symbols from /usr/local/lib/libOgreMain.so.1.7.1...done. Loaded symbols for /usr/local/lib/libOgreMain.so.1.7.1 Reading symbols from /usr/lib/libfftw3.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libfftw3.so.3 Reading symbols from /usr/lib/libSDL_sound-1.0.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libSDL_sound-1.0.so.1 Reading symbols from /usr/lib/libSDL-1.2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libSDL-1.2.so.0 Reading symbols from /usr/lib/libSDL_mixer-1.2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libSDL_mixer-1.2.so.0 Reading symbols from /usr/lib/libOIS-1.2.0.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libOIS-1.2.0.so Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/i686/cmov/libm.so.6...Reading symbols from /usr/lib/debug/lib/i686/cmov/libm-2.11.2.so...done. done. Loaded symbols for /lib/i686/cmov/libm.so.6 Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/i686/cmov/libc.so.6...Reading symbols from /usr/lib/debug/lib/i686/cmov/libc-2.11.2.so...done. done. Loaded symbols for /lib/i686/cmov/libc.so.6 Reading symbols from /lib/i686/cmov/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/i686/cmov/libpthread-2.11.2.so...done. done. Loaded symbols for /lib/i686/cmov/libpthread.so.0 Reading symbols from /usr/local/lib/libv4l1.so.0...done. Loaded symbols for /usr/local/lib/libv4l1.so.0 Reading symbols from /usr/lib/libfreetype.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libfreetype.so.6 Reading symbols from /usr/lib/libSM.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libSM.so.6 Reading symbols from /usr/lib/libICE.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libICE.so.6 Reading symbols from /usr/lib/libX11.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libX11.so.6 Reading symbols from /usr/lib/libXext.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXext.so.6 Reading symbols from /usr/lib/libXt.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXt.so.6 Reading symbols from /usr/lib/libXaw.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXaw.so.7 Reading symbols from /lib/i686/cmov/libdl.so.2...Reading symbols from /usr/lib/debug/lib/i686/cmov/libdl-2.11.2.so...done. done. Loaded symbols for /lib/i686/cmov/libdl.so.2 Reading symbols from /usr/lib/libboost_thread.so.1.42.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libboost_thread.so.1.42.0 Reading symbols from /usr/lib/libboost_date_time.so.1.42.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libboost_date_time.so.1.42.0 Reading symbols from /usr/lib/libfreeimage.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libfreeimage.so.3 Reading symbols from /usr/lib/libzzip-0.so.13...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libzzip-0.so.13 Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /usr/lib/libsmpeg-0.4.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libsmpeg-0.4.so.0 Reading symbols from /usr/lib/libmikmod.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libmikmod.so.2 Reading symbols from /usr/lib/libvorbis.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libvorbis.so.0 Reading symbols from /usr/lib/libvorbisfile.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libvorbisfile.so.3 Reading symbols from /usr/lib/libFLAC.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libFLAC.so.8 Reading symbols from /usr/lib/libogg.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libogg.so.0 Reading symbols from /usr/lib/sse2/libspeex.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/sse2/libspeex.so.1 Reading symbols from /usr/lib/libasound.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libasound.so.2 Reading symbols from /lib/i686/cmov/librt.so.1...Reading symbols from /usr/lib/debug/lib/i686/cmov/librt-2.11.2.so...done. done. Loaded symbols for /lib/i686/cmov/librt.so.1 Reading symbols from /usr/lib/libdirectfb-1.2.so.9...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libdirectfb-1.2.so.9 Reading symbols from /usr/lib/libfusion-1.2.so.9...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libfusion-1.2.so.9 Reading symbols from /usr/lib/libdirect-1.2.so.9...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libdirect-1.2.so.9 Reading symbols from /usr/lib/libvga.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libvga.so.1 Reading symbols from /lib/ld-linux.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.11.2.so...done. done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/local/lib/libv4l2.so.0...done. Loaded symbols for /usr/local/lib/libv4l2.so.0 Reading symbols from /lib/libuuid.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libuuid.so.1 Reading symbols from /usr/lib/libxcb.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libxcb.so.1 Reading symbols from /usr/lib/libXmu.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXmu.so.6 Reading symbols from /usr/lib/libXpm.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXpm.so.4 Reading symbols from /usr/lib/libjpeg.so.62...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /usr/lib/libmng.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libmng.so.1 Reading symbols from /usr/lib/libopenjpeg.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libopenjpeg.so.2 Reading symbols from /lib/libpng12.so.0...(no debugging symbols found)...done. Loaded symbols for /lib/libpng12.so.0 Reading symbols from /usr/lib/libIlmImf.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libIlmImf.so.6 Reading symbols from /usr/lib/libImath.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libImath.so.6 Reading symbols from /usr/lib/libHalf.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libHalf.so.6 Reading symbols from /usr/lib/libIex.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libIex.so.6 Reading symbols from /usr/lib/libIlmThread.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libIlmThread.so.6 Reading symbols from /lib/libx86.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libx86.so.1 Reading symbols from /usr/local/lib/libv4lconvert.so.0...done. Loaded symbols for /usr/local/lib/libv4lconvert.so.0 Reading symbols from /usr/lib/libXau.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXau.so.6 Reading symbols from /usr/lib/libXdmcp.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXdmcp.so.6 Reading symbols from /usr/lib/liblcms.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/liblcms.so.1 Reading symbols from /usr/local/lib/OGRE/RenderSystem_GL.so...done. Loaded symbols for /usr/local/lib/OGRE/RenderSystem_GL.so Reading symbols from /usr/lib/libGLU.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libGLU.so.1 Reading symbols from /usr/lib/libGL.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libGL.so.1 Reading symbols from /usr/lib/libXrandr.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXrandr.so.2 Reading symbols from /usr/lib/libGLcore.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libGLcore.so.1 Reading symbols from /usr/lib/tls/libnvidia-tls.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/tls/libnvidia-tls.so.1 Reading symbols from /usr/lib/libXrender.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXrender.so.1 Reading symbols from /usr/lib/libXcursor.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXcursor.so.1 Reading symbols from /usr/lib/libXfixes.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXfixes.so.3 Reading symbols from /lib/i686/cmov/libnss_compat.so.2...Reading symbols from /usr/lib/debug/lib/i686/cmov/libnss_compat-2.11.2.so...done. done. Loaded symbols for /lib/i686/cmov/libnss_compat.so.2 Reading symbols from /lib/i686/cmov/libnsl.so.1...Reading symbols from /usr/lib/debug/lib/i686/cmov/libnsl-2.11.2.so...done. done. Loaded symbols for /lib/i686/cmov/libnsl.so.1 Reading symbols from /lib/i686/cmov/libnss_nis.so.2...Reading symbols from /usr/lib/debug/lib/i686/cmov/libnss_nis-2.11.2.so...done. done. Loaded symbols for /lib/i686/cmov/libnss_nis.so.2 Reading symbols from /lib/i686/cmov/libnss_files.so.2...Reading symbols from /usr/lib/debug/lib/i686/cmov/libnss_files-2.11.2.so...done. done. Loaded symbols for /lib/i686/cmov/libnss_files.so.2 Reading symbols from /usr/lib/alsa-lib/libasound_module_rate_speexrate.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/alsa-lib/libasound_module_rate_speexrate.so Reading symbols from /usr/lib/sse2/libspeexdsp.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/sse2/libspeexdsp.so.1 Core was generated by `./OgreVisualizer'. Program terminated with signal 11, Segmentation fault. #0 0xb6dc563d in std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&) () from /usr/lib/libstdc++.so.6 (gdb) bt #0 0xb6dc563d in std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&) () from /usr/lib/libstdc++.so.6 #1 0xb73bb3c2 in std::_Rb_tree<Ogre::Node*, Ogre::Node*, std::_Identity<Ogre::Node*>, std::less<Ogre::Node*>, Ogre::STLAllocator<Ogre::Node*, Ogre::CategorisedAllocPolicy<(Ogre::MemoryCategory)0> > >::_M_insert_(std::_Rb_tree_node_base const*, std::_Rb_tree_node_base const*, Ogre::Node* const&) () from /usr/local/lib/libOgreMain.so.1.7.1 #2 0xb73b5a52 in _M_insert_unique (this=0xb6157ea0, child=0xb616aff8, forceParentUpdate=false) at /usr/include/c++/4.4/bits/stl_tree.h:1182 #3 insert (this=0xb6157ea0, child=0xb616aff8, forceParentUpdate=false) at /usr/include/c++/4.4/bits/stl_set.h:411 #4 Ogre::Node::requestUpdate (this=0xb6157ea0, child=0xb616aff8, forceParentUpdate=false) at /home/balazsbela/Downloads/ogre_src_v1-7-1/OgreMain/src/OgreNode.cpp:805 #5 0xb73b6a40 in Ogre::Node::needUpdate (this=0xb616aff8, forceParentUpdate=92) at /home/balazsbela/Downloads/ogre_src_v1-7-1/OgreMain/src/OgreNode.cpp:789 #6 0xb73b5038 in Ogre::Node::setScale (this=0x1825c, scale=...) at /home/balazsbela/Downloads/ogre_src_v1-7-1/OgreMain/src/OgreNode.cpp:638 #7 0x0805d306 in VisualizerApplication::adjustNodes (this=0x9cd4808) at ../src/VisualizerApplication.cpp:236 #8 0xb6e867f0 in ?? () from /usr/lib/libSDL_mixer-1.2.so.0 #9 0xb6e8719a in ?? () from /usr/lib/libSDL_mixer-1.2.so.0 #10 0xb6ed9b0d in ?? () from /usr/lib/libSDL-1.2.so.0 #11 0xb6ee185e in ?? () from /usr/lib/libSDL-1.2.so.0 #12 0xb6f2e0bd in ?? () from /usr/lib/libSDL-1.2.so.0 #13 0xb6bc7955 in start_thread (arg=0xb198ab70) at pthread_create.c:300 #14 0xb6ca6e7e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 (gdb) Ogre.log: (http)://pastie.org/1581790

    Read the article

  • 64-bit Archives Needed

    - by user9154181
    A little over a year ago, we received a question from someone who was trying to build software on Solaris. He was getting errors from the ar command when creating an archive. At that time, the ar command on Solaris was a 32-bit command. There was more than 2GB of data, and the ar command was hitting the file size limit for a 32-bit process that doesn't use the largefile APIs. Even in 2011, 2GB is a very large amount of code, so we had not heard this one before. Most of our toolchain was extended to handle 64-bit sized data back in the 1990's, but archives were not changed, presumably because there was no perceived need for it. Since then of course, programs have continued to get larger, and in 2010, the time had finally come to investigate the issue and find a way to provide for larger archives. As part of that process, I had to do a deep dive into the archive format, and also do some Unix archeology. I'm going to record what I learned here, to document what Solaris does, and in the hope that it might help someone else trying to solve the same problem for their platform. Archive Format Details Archives are hardly cutting edge technology. They are still used of course, but their basic form hasn't changed in decades. Other than to fix a bug, which is rare, we don't tend to touch that code much. The archive file format is described in /usr/include/ar.h, and I won't repeat the details here. Instead, here is a rough overview of the archive file format, implemented by System V Release 4 (SVR4) Unix systems such as Solaris: Every archive starts with a "magic number". This is a sequence of 8 characters: "!<arch>\n". The magic number is followed by 1 or more members. A member starts with a fixed header, defined by the ar_hdr structure in/usr/include/ar.h. Immediately following the header comes the data for the member. Members must be padded at the end with newline characters so that they have even length. The requirement to pad members to an even length is a dead giveaway as to the age of the archive format. It tells you that this format dates from the 1970's, and more specifically from the era of 16-bit systems such as the PDP-11 that Unix was originally developed on. A 32-bit system would have required 4 bytes, and 64-bit systems such as we use today would probably have required 8 bytes. 2 byte alignment is a poor choice for ELF object archive members. 32-bit objects require 4 byte alignment, and 64-bit objects require 64-bit alignment. The link-editor uses mmap() to process archives, and if the members have the wrong alignment, we have to slide (copy) them to the correct alignment before we can access the ELF data structures inside. The archive format requires 2 byte padding, but it doesn't prohibit more. The Solaris ar command takes advantage of this, and pads ELF object members to 8 byte boundaries. Anything else is padded to 2 as required by the format. The archive header (ar_hdr) represents all numeric values using an ASCII text representation rather than as binary integers. This means that an archive that contains only text members can be viewed using tools such as cat, more, or a text editor. The original designers of this format clearly thought that archives would be used for many file types, and not just for objects. Things didn't turn out that way of course — nearly all archives contain relocatable objects for a single operating system and machine, and are used primarily as input to the link-editor (ld). Archives can have special members that are created by the ar command rather than being supplied by the user. These special members are all distinguished by having a name that starts with the slash (/) character. This is an unambiguous marker that says that the user could not have supplied it. The reason for this is that regular archive members are given the plain name of the file that was inserted to create them, and any path components are stripped off. Slash is the delimiter character used by Unix to separate path components, and as such cannot occur within a plain file name. The ar command hides the special members from you when you list the contents of an archive, so most users don't know that they exist. There are only two possible special members: A symbol table that maps ELF symbols to the object archive member that provides it, and a string table used to hold member names that exceed 15 characters. The '/' convention for tagging special members provides room for adding more such members should the need arise. As I will discuss below, we took advantage of this fact to add an alternate 64-bit symbol table special member which is used in archives that are larger than 4GB. When an archive contains ELF object members, the ar command builds a special archive member known as the symbol table that maps all ELF symbols in the object to the archive member that provides it. The link-editor uses this symbol table to determine which symbols are provided by the objects in that archive. If an archive has a symbol table, it will always be the first member in the archive, immediately following the magic number. Unlike member headers, symbol tables do use binary integers to represent offsets. These integers are always stored in big-endian format, even on a little endian host such as x86. The archive header (ar_hdr) provides 15 characters for representing the member name. If any member has a name that is longer than this, then the real name is written into a special archive member called the string table, and the member's name field instead contains a slash (/) character followed by a decimal representation of the offset of the real name within the string table. The string table is required to precede all normal archive members, so it will be the second member if the archive contains a symbol table, and the first member otherwise. The archive format is not designed to make finding a given member easy. Such operations move through the archive from front to back examining each member in turn, and run in O(n) time. This would be bad if archives were commonly used in that manner, but in general, they are not. Typically, the ar command is used to build an new archive from scratch, inserting all the objects in one operation, and then the link-editor accesses the members in the archive in constant time by using the offsets provided by the symbol table. Both of these operations are reasonably efficient. However, listing the contents of a large archive with the ar command can be rather slow. Factors That Limit Solaris Archive Size As is often the case, there was more than one limiting factor preventing Solaris archives from growing beyond the 32-bit limits of 2GB (32-bit signed) and 4GB (32-bit unsigned). These limits are listed in the order they are hit as archive size grows, so the earlier ones mask those that follow. The original Solaris archive file format can handle sizes up to 4GB without issue. However, the ar command was delivered as a 32-bit executable that did not use the largefile APIs. As such, the ar command itself could not create a file larger than 2GB. One can solve this by building ar with the largefile APIs which would allow it to reach 4GB, but a simpler and better answer is to deliver a 64-bit ar, which has the ability to scale well past 4GB. Symbol table offsets are stored as 32-bit big-endian binary integers, which limits the maximum archive size to 4GB. To get around this limit requires a different symbol table format, or an extension mechanism to the current one, similar in nature to the way member names longer than 15 characters are handled in member headers. The size field in the archive member header (ar_hdr) is an ASCII string capable of representing a 32-bit unsigned value. This places a 4GB size limit on the size of any individual member in an archive. In considering format extensions to get past these limits, it is important to remember that very few archives will require the ability to scale past 4GB for many years. The old format, while no beauty, continues to be sufficient for its purpose. This argues for a backward compatible fix that allows newer versions of Solaris to produce archives that are compatible with older versions of the system unless the size of the archive exceeds 4GB. Archive Format Differences Among Unix Variants While considering how to extend Solaris archives to scale to 64-bits, I wanted to know how similar archives from other Unix systems are to those produced by Solaris, and whether they had already solved the 64-bit issue. I've successfully moved archives between different Unix systems before with good luck, so I knew that there was some commonality. If it turned out that there was already a viable defacto standard for 64-bit archives, it would obviously be better to adopt that rather than invent something new. The archive file format is not formally standardized. However, the ar command and archive format were part of the original Unix from Bell Labs. Other systems started with that format, extending it in various often incompatible ways, but usually with the same common shared core. Most of these systems use the same magic number to identify their archives, despite the fact that their archives are not always fully compatible with each other. It is often true that archives can be copied between different Unix variants, and if the member names are short enough, the ar command from one system can often read archives produced on another. In practice, it is rare to find an archive containing anything other than objects for a single operating system and machine type. Such an archive is only of use on the type of system that created it, and is only used on that system. This is probably why cross platform compatibility of archives between Unix variants has never been an issue. Otherwise, the use of the same magic number in archives with incompatible formats would be a problem. I was able to find information for a number of Unix variants, described below. These can be divided roughly into three tribes, SVR4 Unix, BSD Unix, and IBM AIX. Solaris is a SVR4 Unix, and its archives are completely compatible with those from the other members of that group (GNU/Linux, HP-UX, and SGI IRIX). AIX AIX is an exception to rule that Unix archive formats are all based on the original Bell labs Unix format. It appears that AIX supports 2 formats (small and big), both of which differ in fundamental ways from other Unix systems: These formats use a different magic number than the standard one used by Solaris and other Unix variants. They include support for removing archive members from a file without reallocating the file, marking dead areas as unused, and reusing them when new archive items are inserted. They have a special table of contents member (File Member Header) which lets you find out everything that's in the archive without having to actually traverse the entire file. Their symbol table members are quite similar to those from other systems though. Their member headers are doubly linked, containing offsets to both the previous and next members. Of the Unix systems described here, AIX has the only format I saw that will have reasonable insert/delete performance for really large archives. Everyone else has O(n) performance, and are going to be slow to use with large archives. BSD BSD has gone through 4 versions of archive format, which are described in their manpage. They use the same member header as SVR4, but their symbol table format is different, and their scheme for long member names puts the name directly after the member header rather than into a string table. GNU/Linux The GNU toolchain uses the SVR4 format, and is compatible with Solaris. HP-UX HP-UX seems to follow the SVR4 model, and is compatible with Solaris. IRIX IRIX has 32 and 64-bit archives. The 32-bit format is the standard SVR4 format, and is compatible with Solaris. The 64-bit format is the same, except that the symbol table uses 64-bit integers. IRIX assumes that an archive contains objects of a single ELFCLASS/MACHINE, and any archive containing ELFCLASS64 objects receives a 64-bit symbol table. Although they only use it for 64-bit objects, nothing in the archive format limits it to ELFCLASS64. It would be perfectly valid to produce a 64-bit symbol table in an archive containing 32-bit objects, text files, or anything else. Tru64 Unix (Digital/Compaq/HP) Tru64 Unix uses a format much like ours, but their symbol table is a hash table, making specific symbol lookup much faster. The Solaris link-editor uses archives by examining the entire symbol table looking for unsatisfied symbols for the link, and not by looking up individual symbols, so there would be no benefit to Solaris from such a hash table. The Tru64 ld must use a different approach in which the hash table pays off for them. Widening the existing SVR4 archive symbol tables rather than inventing something new is the simplest path forward. There is ample precedent for this approach in the ELF world. When ELF was extended to support 64-bit objects, the approach was largely to take the existing data structures, and define 64-bit versions of them. We called the old set ELF32, and the new set ELF64. My guess is that there was no need to widen the archive format at that time, but had there been, it seems obvious that this is how it would have been done. The Implementation of 64-bit Solaris Archives As mentioned earlier, there was no desire to improve the fundamental nature of archives. They have always had O(n) insert/delete behavior, and for the most part it hasn't mattered. AIX made efforts to improve this, but those efforts did not find widespread adoption. For the purposes of link-editing, which is essentially the only thing that archives are used for, the existing format is adequate, and issues of backward compatibility trump the desire to do something technically better. Widening the existing symbol table format to 64-bits is therefore the obvious way to proceed. For Solaris 11, I implemented that, and I also updated the ar command so that a 64-bit version is run by default. This eliminates the 2 most significant limits to archive size, leaving only the limit on an individual archive member. We only generate a 64-bit symbol table if the archive exceeds 4GB, or when the new -S option to the ar command is used. This maximizes backward compatibility, as an archive produced by Solaris 11 is highly likely to be less than 4GB in size, and will therefore employ the same format understood by older versions of the system. The main reason for the existence of the -S option is to allow us to test the 64-bit format without having to construct huge archives to do so. I don't believe it will find much use outside of that. Other than the new ability to create and use extremely large archives, this change is largely invisible to the end user. When reading an archive, the ar command will transparently accept either form of symbol table. Similarly, the ELF library (libelf) has been updated to understand either format. Users of libelf (such as the link-editor ld) do not need to be modified to use the new format, because these changes are encapsulated behind the existing functions provided by libelf. As mentioned above, this work did not lift the limit on the maximum size of an individual archive member. That limit remains fixed at 4GB for now. This is not because we think objects will never get that large, for the history of computing says otherwise. Rather, this is based on an estimation that single relocatable objects of that size will not appear for a decade or two. A lot can change in that time, and it is better not to overengineer things by writing code that will sit and rot for years without being used. It is not too soon however to have a plan for that eventuality. When the time comes when this limit needs to be lifted, I believe that there is a simple solution that is consistent with the existing format. The archive member header size field is an ASCII string, like the name, and as such, the overflow scheme used for long names can also be used to handle the size. The size string would be placed into the archive string table, and its offset in the string table would then be written into the archive header size field using the same format "/ddd" used for overflowed names.

    Read the article

  • Getting error while install mod_wsgi on centos6.3 with python 2.7

    - by user825904
    In initially installed yum install mod_wsgi and i think it was linked with python 2.6 Now is there any way to link it with 2.7 I tried configuring from the source and i get this error apxs -c -I/usr/local/include/python2.7 -DNDEBUG mod_wsgi.c -L/usr/local/lib -L/usr/local/lib/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm /usr/lib64/apr-1/build/libtool --silent --mode=compile gcc -prefer-pic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wformat-security -fno-strict-aliasing -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -pthread -I/usr/include/httpd -I/usr/include/apr-1 -I/usr/include/apr-1 -I/usr/local/include/python2.7 -DNDEBUG -c -o mod_wsgi.lo mod_wsgi.c && touch mod_wsgi.slo In file included from /usr/local/include/python2.7/Python.h:8, from mod_wsgi.c:142: /usr/local/include/python2.7/pyconfig.h:1161:1: warning: "_POSIX_C_SOURCE" redefined In file included from /usr/include/sys/types.h:26, from /usr/include/apr-1/apr-x86_64.h:127, from /usr/include/apr-1/apr.h:19, from /usr/include/httpd/ap_config.h:25, from /usr/include/httpd/httpd.h:43, from mod_wsgi.c:34: /usr/include/features.h:162:1: warning: this is the location of the previous definition In file included from /usr/local/include/python2.7/Python.h:8, from mod_wsgi.c:142: /usr/local/include/python2.7/pyconfig.h:1183:1: warning: "_XOPEN_SOURCE" redefined In file included from /usr/include/sys/types.h:26, from /usr/include/apr-1/apr-x86_64.h:127, from /usr/include/apr-1/apr.h:19, from /usr/include/httpd/ap_config.h:25, from /usr/include/httpd/httpd.h:43, from mod_wsgi.c:34: /usr/include/features.h:164:1: warning: this is the location of the previous definition mod_wsgi.c: In function ‘wsgi_server_group’: mod_wsgi.c:991: warning: unused variable ‘value’ mod_wsgi.c: In function ‘Log_isatty’: mod_wsgi.c:1665: warning: unused variable ‘result’ mod_wsgi.c: In function ‘Log_writelines’: mod_wsgi.c:1802: warning: unused variable ‘msg’ mod_wsgi.c: In function ‘Adapter_output’: mod_wsgi.c:3087: warning: unused variable ‘n’ mod_wsgi.c: In function ‘Adapter_file_wrapper’: mod_wsgi.c:4138: warning: unused variable ‘result’ mod_wsgi.c: In function ‘wsgi_python_term’: mod_wsgi.c:5850: warning: unused variable ‘tstate’ mod_wsgi.c:5849: warning: unused variable ‘interp’ mod_wsgi.c: In function ‘wsgi_python_child_init’: mod_wsgi.c:7050: warning: unused variable ‘l’ mod_wsgi.c:6948: warning: unused variable ‘interp’ mod_wsgi.c: In function ‘wsgi_add_import_script’: mod_wsgi.c:7701: warning: unused variable ‘error’ mod_wsgi.c: In function ‘wsgi_add_handler_script’: mod_wsgi.c:8179: warning: unused variable ‘dconfig’ mod_wsgi.c:8178: warning: unused variable ‘sconfig’ mod_wsgi.c: In function ‘wsgi_hook_handler’: mod_wsgi.c:9375: warning: suggest parentheses around assignment used as truth value mod_wsgi.c:9377: warning: suggest parentheses around assignment used as truth value mod_wsgi.c:9379: warning: suggest parentheses around assignment used as truth value mod_wsgi.c:9383: warning: suggest parentheses around assignment used as truth value mod_wsgi.c:9403: warning: suggest parentheses around assignment used as truth value mod_wsgi.c:9405: warning: suggest parentheses around assignment used as truth value mod_wsgi.c:9408: warning: suggest parentheses around assignment used as truth value mod_wsgi.c: In function ‘wsgi_daemon_worker’: mod_wsgi.c:10819: warning: unused variable ‘duration’ mod_wsgi.c:10818: warning: unused variable ‘start’ mod_wsgi.c: In function ‘wsgi_hook_daemon_handler’: mod_wsgi.c:13172: warning: unused variable ‘i’ mod_wsgi.c:13170: warning: unused variable ‘elts’ mod_wsgi.c:13169: warning: unused variable ‘head’ mod_wsgi.c: At top level: mod_wsgi.c:8142: warning: ‘wsgi_set_user_authoritative’ defined but not used mod_wsgi.c:15251: warning: ‘wsgi_hook_check_user_id’ defined but not used /usr/lib64/apr-1/build/libtool --silent --mode=link gcc -o mod_wsgi.la -rpath /usr/lib64/httpd/modules -module -avoid-version mod_wsgi.lo -L/usr/local/lib -L/usr/local/lib/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm /usr/bin/ld: /usr/local/lib/libpython2.7.a(abstract.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libpython2.7.a: could not read symbols: Bad value collect2: ld returned 1 exit status apxs:Error: Command failed with rc=65536 . make: *** [mod_wsgi.la] Error 1 Waiting for Graham

    Read the article

  • Unable to install rubygems in ubuntu 10.04

    - by loganathan
    I had installed the ruby 1.8.7 with patch level 253 successfully on my ubuntu 10.04, but while installing ruby gems I am facing the below error, can anybody help me on this. ruby -v ruby 1.8.7 (2010-04-19 patchlevel 253) [i686-linux], MBARI 0x8770, Ruby Enterprise Edition 2010.02 gem install mongrel *** longjmp causes uninitialized stack frame ***: /usr/bin/ruby terminated ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x50)[0x3612d0] /lib/tls/i686/cmov/libc.so.6(+0xe223a)[0x36123a] /usr/bin/ruby[0x80577b9] /usr/bin/ruby[0x80577d5] /usr/bin/ruby(rb_thread_schedule+0x9fc)[0x80652ac] /usr/bin/ruby(rb_thread_kill+0x14)[0x8066c74] /usr/bin/ruby[0x806071d] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806a869] /usr/bin/ruby[0x806a290] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806a869] /usr/bin/ruby[0x806995b] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806aaa5] /usr/bin/ruby[0x8069d54] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x805df2d] /usr/bin/ruby[0x8069581] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x806a0eb] /usr/bin/ruby[0x805e630] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806aaa5] /usr/bin/ruby[0x806a715] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806a869] /usr/bin/ruby[0x805e48b] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806aaa5] /usr/bin/ruby[0x805e58a] /usr/bin/ruby[0x805e4aa] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806a869] /usr/bin/ruby[0x805e48b] /usr/bin/ruby[0x80693f1] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x806a0eb] /usr/bin/ruby[0x805e630] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806a869] /usr/bin/ruby[0x805e48b] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x806a0eb] /usr/bin/ruby[0x805e630] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806aaa5] /usr/bin/ruby[0x805e48b] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x8060601] ======= Memory map: ======== 00110000-00112000 r-xp 00000000 08:06 3805677 /usr/lib/ruby/1.8/i686-linux/etc.so 00112000-00113000 r--p 00001000 08:06 3805677 /usr/lib/ruby/1.8/i686-linux/etc.so 00113000-00114000 rw-p 00002000 08:06 3805677 /usr/lib/ruby/1.8/i686-linux/etc.so 00114000-0012e000 r-xp 00000000 08:06 3805682 /usr/lib/ruby/1.8/i686-linux/syck.so 0012e000-0012f000 r--p 00019000 08:06 3805682 /usr/lib/ruby/1.8/i686-linux/syck.so 0012f000-00130000 rw-p 0001a000 08:06 3805682 /usr/lib/ruby/1.8/i686-linux/syck.so 00130000-00131000 r-xp 00000000 08:06 3805666 /usr/lib/ruby/1.8/i686-linux/fcntl.so 00131000-00132000 r--p 00000000 08:06 3805666 /usr/lib/ruby/1.8/i686-linux/fcntl.so 00132000-00133000 rw-p 00001000 08:06 3805666 /usr/lib/ruby/1.8/i686-linux/fcntl.so 00133000-00150000 r-xp 00000000 08:06 11403438 /lib/libgcc_s.so.1 00150000-00151000 r--p 0001c000 08:06 11403438 /lib/libgcc_s.so.1 00151000-00152000 rw-p 0001d000 08:06 11403438 /lib/libgcc_s.so.1 001e2000-00206000 r-xp 00000000 08:06 11403697 /lib/tls/i686/cmov/libm-2.11.1.so 00206000-00207000 r--p 00023000 08:06 11403697 /lib/tls/i686/cmov/libm-2.11.1.so 00207000-00208000 rw-p 00024000 08:06 11403697 /lib/tls/i686/cmov/libm-2.11.1.so 0024d000-00256000 r-xp 00000000 08:06 11403688 /lib/tls/i686/cmov/libcrypt-2.11.1.so 00256000-00257000 r--p 00008000 08:06 11403688 /lib/tls/i686/cmov/libcrypt-2.11.1.so 00257000-00258000 rw-p 00009000 08:06 11403688 /lib/tls/i686/cmov/libcrypt-2.11.1.so 00258000-0027f000 rw-p 00000000 00:00 0 0027f000-003d2000 r-xp 00000000 08:06 11403695 /lib/tls/i686/cmov/libc-2.11.1.so 003d2000-003d4000 r--p 00153000 08:06 11403695 /lib/tls/i686/cmov/libc-2.11.1.so 003d4000-003d5000 rw-p 00155000 08:06 11403695 /lib/tls/i686/cmov/libc-2.11.1.so 003d5000-003d8000 rw-p 00000000 00:00 0 0047e000-00488000 r-xp 00000000 08:06 3805680 /usr/lib/ruby/1.8/i686-linux/socket.so 00488000-00489000 r--p 00009000 08:06 3805680 /usr/lib/ruby/1.8/i686-linux/socket.so 00489000-0048a000 rw-p 0000a000 08:06 3805680 /usr/lib/ruby/1.8/i686-linux/socket.so 004f2000-00507000 r-xp 00000000 08:06 11403690 /lib/tls/i686/cmov/libpthread-2.11.1.so 00507000-00508000 r--p 00014000 08:06 11403690 /lib/tls/i686/cmov/libpthread-2.11.1.so 00508000-00509000 rw-p 00015000 08:06 11403690 /lib/tls/i686/cmov/libpthread-2.11.1.so 00509000-0050b000 rw-p 00000000 00:00 0 00524000-00525000 r-xp 00000000 00:00 0 [vdso] 00544000-00557000 r-xp 00000000 08:06 11403553 /lib/libz.so.1.2.3.3 00557000-00558000 r--p 00012000 08:06 11403553 /lib/libz.so.1.2.3.3 00558000-00559000 rw-p 00013000 08:06 11403553 /lib/libz.so.1.2.3.3 00639000-0063c000 r-xp 00000000 08:06 3805679 /usr/lib/ruby/1.8/i686-linux/thread.so 0063c000-0063d000 r--p 00002000 08:06 3805679 /usr/lib/ruby/1.8/i686-linux/thread.so 0063d000-0063e000 rw-p 00003000 08:06 3805679 /usr/lib/ruby/1.8/i686-linux/thread.so 00649000-0064d000 r-xp 00000000 08:06 11403714 /lib/tls/i686/cmov/libnss_dns-2.11.1.so 0064d000-0064e000 r--p 00004000 08:06 11403714 /lib/tls/i686/cmov/libnss_dns-2.11.1.so 0064e000-0064f000 rw-p 00005000 08:06 11403714 /lib/tls/i686/cmov/libnss_dns-2.11.1.so 00663000-006a3000 r-xp 00000000 08:06 4329500 /usr/lib/ruby/site_ruby/1.8/i686-linux/openssl.so 006a3000-006a4000 r--p 0003f000 08:06 4329500 /usr/lib/ruby/site_ruby/1.8/i686-linux/openssl.so 006a4000-006a5000 rw-p 00040000 08:06 4329500 /usr/lib/ruby/site_ruby/1.8/i686-linux/openssl.so 006a5000-006a6000 rw-p 00000000 00:00 0 0070d000-0070f000 r-xp 00000000 08:06 11403689 /lib/tls/i686/cmov/libdl-2.11.1.so 0070f000-00710000 r--p 00001000 08:06 11403689 /lib/tls/i686/cmov/libdl-2.11.1.so 00710000-00711000 rw-p 00002000 08:06 11403689 /lib/tls/i686/cmov/libdl-2.11.1.so 00711000-0084b000 r-xp 00000000 08:06 11403909 /lib/libcrypto.so.0.9.8 0084b000-00853000 r--p 00139000 08:06 11403909 /lib/libcrypto.so.0.9.8 00853000-00861000 rw-p 00141000 08:06 11403909 /lib/libcrypto.so.0.9.8 00861000-00864000 rw-p 00000000 00:00 0 00864000-00865000 ---p 00000000 00:00 0 00865000-00966000 rwxp 00000000 00:00 0 00977000-00979000 r-xp 00000000 08:06 11403476 /lib/libnss_mdns4_minimal.so.2 00979000-0097a000 r--p 00001000 08:06 11403476 /lib/libnss_mdns4_minimal.so.2 0097a000-0097b000 rw-p 00002000 08:06 11403476 /lib/libnss_mdns4_minimal.so.2 009fa000-00a04000 r-xp 00000000 08:06 11403691 /lib/tls/i686/cmov/libnss_files-2.11.1.so 00a04000-00a05000 r--p 00009000 08:06 11403691 /lib/tls/i686/cmov/libnss_files-2.11.1.so 00a05000-00a06000 rw-p 0000a000 08:06 11403691 /lib/tls/i686/cmov/libnss_files-2.11.1.so 00ac0000-00ac4000 r-xp 00000000 08:06 3805670 /usr/lib/ruby/1.8/i686-linux/stringio.so 00ac4000-00ac5000 r--p 00003000 08:06 3805670 /usr/lib/ruby/1.8/i686-linux/stringio.so 00ac5000-00ac6000 rw-p 00004000 08:06 3805670 /usr/lib/ruby/1.8/i686-linux/stringio.so 00af3000-00b0e000 r-xp 00000000 08:06 11403607 /lib/ld-2.11.1.so 00b0e000-00b0f000 r--p 0001a000 08:06 11403607 /lib/ld-2.11.1.so 00b0f000-00b10000 rw-p 0001b000 08:06 11403607 /lib/ld-2.11.1.so 00c35000-00c45000 r-xp 00000000 08:06 11403692 /lib/tls/i686/cmov/libresolv-2.11.1.so 00c45000-00c46000 r--p 00010000 08:06 11403692 /lib/tls/i686/cmov/libresolv-2.11.1.so 00c46000-00c47000 rw-p 00011000 08:06 11403692 /lib/tls/i686/cmov/libresolv-2.11.1.so 00c47000-00c49000 rw-p 00000000 00:00 0 00d51000-00d59000 r-xp 00000000 08:06 4329502 /usr/lib/ruby/site_ruby/1.8/i686-linux/zlib.so 00d59000-00d5a000 r--p 00007000 08:06 4329502 /usr/lib/ruby/site_ruby/1.8/i686-linux/zlib.so 00d5a000-00d5b000 rw-p 00008000 08:06 4329502 /usr/lib/ruby/site_ruby/1.8/i686-linux/zlib.so 00d60000-00d61000 r-xp 00000000 08:06 3805664 /usr/lib/ruby/1.8/i686-linux/rational.so 00d61000-00d62000 r--p 00000000 08:06 3805664 /usr/lib/ruby/1.8/i686-linux/rational.so 00d62000-00d63000 rw-p 00001000 08:06 3805664 /usr/lib/ruby/1.8/i686-linux/rational.so 00de6000-00de9000 r-xp 00000000 08:06 3805691 /usr/lib/ruby/1.8/i686-linux/digest.so 00de9000-00dea000 r--p 00002000 08:06 3805691 /usr/lib/ruby/1.8/i686-linux/digest.so 00dea000-00deb000 rw-p 00003000 08:06 3805691 /usr/lib/ruby/1.8/i686-linux/digest.so 00e63000-00e6a000 r-xp 00000000 08:06 11403700 /lib/tls/i686/cmov/librt-2.11.1.so 00e6a000-00e6b000 r--p 00006000 08:06 11403700 /lib/tls/i686/cmov/librt-2.11.1.so 00e6b000-00e6c000 rw-p 00007000 08:06 11403700 /lib/tls/i686/cmov/librt-2.11.1.so 00f70000-00fb4000 r-xp 00000000 08:06 11403907 /lib/libssl.so.0.9.8Aborted

    Read the article

  • Can't get Apache 2.2.21 to compile with OpenSSL support

    - by angstwad
    Alright -- having a bad couple days here compiling Apache 2.2.21 on CentOS 5.7 with the following configure commands: ./configure --enable-ssl=shared --with-ssl=/usr/local/openssl I've compiled from source OpenSSL 1.0.0e from source: ./config --prefix=/usr/local --openssldir=/usr/local/openssl shared zlib-dynamic I attempt to start Apache and it returns: httpd: Syntax error on line 54 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/mod_ssl.so into server: /usr/local/apache2/modules/mod_ssl.so: undefined symbol: SSL_get_servername If I look at how the libraries are linked, this is what I get: [root@web1 modules]# ldd mod_ssl.so libssl.so.6 => /lib64/libssl.so.6 (0x00002aaaaace4000) libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002aaaaaf30000) libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaab281000) libz.so.1 => /lib64/libz.so.1 (0x00002aaaab486000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aaaab69a000) libc.so.6 => /lib64/libc.so.6 (0x00002aaaab8b5000) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002aaaabc0e000) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002aaaabe3c000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002aaaac0d1000) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002aaaac2d4000) /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002aaaac4f9000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002aaaac702000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00002aaaac904000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00002aaaacb19000) libsepol.so.1 => /lib64/libsepol.so.1 (0x00002aaaacd32000) Basically, I've tired compiling from source OpenSSL (both 0.9.8r and 1e), having yum reinstall from the repos, done a make clean and remade both OpenSSL and Apache numerous times -- but I can't get it to compile into the apache base or dynamically as a shared object file. What am I doing wrong here? Update 1: After doing a make clean and make distclean, I've reconfigured with the same parameters as above without any effect. The config.log is at Pastebin. Update 2: Modifying the LD_LIBRARY_PATH had no effect on the lib-deps of mod_ssl.so. UPDATE 3: I've compiled and recompiled many times, and verified with ldconfig that the OpenSSL libs dir is in my path, and included in ld.so.conf. Still cannot get httpd/mod_ssl to load the library at runtime.

    Read the article

  • CentOS 6 - Make system aware of custom lib paths and missing base links

    - by Mike Purcell
    I am trying to compile libmemcached (1.0.7) on CentOS6, and keep getting the following warning: ... checking for event.h... no configure: WARNING: Unable to find libevent ... I manually compiled libevent (2.0.19) and built it using the following configure line: OPTIONS="--prefix=/usr/local/_custom/app/libevent" Everything compiled and installed fine, but I couldn't figure out how to make the system aware that the lib files are in the custom /usr/local/_custom/app/libevent/libdir. I stumbled upon an article and read that I can make the system aware of custom lib paths by adding a custom file to /etc/ld.so.conf.d/ directory: # /etc/ld.so.conf.d/customApp.conf /usr/local/_custom/app/libevent/lib Then I issued the ldconfig command and was able to confirm that libevent was included by issuing this command: ldconfig -p | ack -i libevent Seeing that libevent was now included in the ldconfig output, I figured I would be able to compile libmemcached and satisfy the aforementioned warning. Unfortunately it did not. So I took another look at the ldconfig output and noticed this: libevent_pthreads-2.0.so.5 (libc6,x86-64) => /usr/local/_custom/app/libevent/lib/libevent_pthreads-2.0.so.5 libevent_openssl-2.0.so.5 (libc6,x86-64) => /usr/local/_custom/app/libevent/lib/libevent_openssl-2.0.so.5 libevent_extra-2.0.so.5 (libc6,x86-64) => /usr/local/_custom/app/libevent/lib/libevent_extra-2.0.so.5 libevent_core-2.0.so.5 (libc6,x86-64) => /usr/local/_custom/app/libevent/lib/libevent_core-2.0.so.5 libevent-2.0.so.5 (libc6,x86-64) => /usr/local/_custom/app/libevent/lib/libevent-2.0.so.5 There are no references to the base links, for example, I would expect to see links to these (ls -la /usr/local/_custom/app/libevent/lib): libevent.so -> libevent-2.0.so.5.1.7 libevent_openssl.so -> libevent_openssl-2.0.so.5.1.7 libevent_core.so -> libevent_core-2.0.so.5.1.7 So either I am doing something wrong, or the system still does not know where to look to find libevent.so. -- Update #1 -- I wasn't able to get libmemcached to compile without the warning notice, even after trying to compile using the following configure command: ./configure --prefix=/usr/local/_custom/app/libmemcached CFLAGS="-I/usr/local/_custom/app/libevent/include" LDFLAGS="-L/usr/local/_custom/app/libevent/lib" I thought for sure this would work because I am directly passing the include and lib directories to the configure command. But it did not.

    Read the article

  • Solaris 11 /proc permission denied

    - by Damo
    I have a Solaris 11.1 server running an Oracle database. I want to read the environment of a running oracle process, as the oracle user, like this: $ id uid=100(oracle) gid=100(oinstall) $ ps -fuoracle | grep pmon oracle 1651 1 0 10:25:37 ? 0:01 ora_pmon_TESTDB $ pargs -e 1651 pargs: cannot examine 1651: permission denied $ ls -ld /proc/1651 dr-x--x--x 5 oracle oinstall 864 Nov 23 10:25 /proc/1651 How can I grant permissions for oracle to read processes that it already owns?

    Read the article

  • How can i automatically backup Nortel PBX config into subversion?

    - by user14604
    PBX: Nortel Opt 81c Connection: Analog lines through Procomm or Reflections We are thinking about backing up the Nortel PBX config and checking them into the subversion. I am wondering if anyone has found the a way to automate the pulling of the configs off the Nortel PBX. Configs would be programming listing in plain text that we can diff in subversion to see what has been changed. An example config would be to go into ld 21 and printing the RDBs.

    Read the article

  • User start daemon .pid Permission denied

    - by kornnflake
    Trying to start a unicorn daemon as a non-root user but failing hard. Unicorn gives the the following error: directory for pid=/var/run/sinatra_test/sinatra_test.pid not writable So I made the following: sudo mkdir /var/run/sinatra_test sudo chown ruby:www-data /var/run/sinatra_test sudo chmod g+w /var/run/sinatra_test ls -ld /var/run/sinatra_test returns: drwxrwxr-x 2 ruby www-data 60 Oct 27 09:55 /var/run/sinatra_test What am I missing? Still getting Permission denied errors.

    Read the article

  • Tmux installation problems

    - by RayQuang
    hI, I am trying to install the terminal multiplexer tmux on my Debian Lenny server so that I can have multiple terminals through ssh. However I have had a lot of difficulty installing it from the debian package, and by compiling it. When I try the package it says something about the wrong version of libc6, and when I compile it I get the following error: server.o: In function `server_start': server.c:(.text+0x273): undefined reference to `event_reinit' collect2: ld returned 1 exit status make: *** [tmux] Error 1 Help would be very much appreciated, RayQuang

    Read the article

  • Will modules installed by insmod command persist after rebooting?

    - by apache
    There is how the book I'm reading describe the insmod utility: The program loads the module code and data into the kernel, which, in turn, performs a function similar to that of ld, in that it links any unresolved symbol in the module to the symbol table of the kernel. Unlike the linker, however, the kernel doesn’t modify the module’s disk file, but rather an in-memory copy. It looks like it won't persist since it's in-memory, but I'm not sure.

    Read the article

  • How to run Repository Creation Utility (RCU) on 64-bit Linux

    - by Kevin Smith
    I was setting up WebCenter Content (WCC) on a new virtual box running 64-bit Linux and ran into a problem when I tried to run the Repository Creation Utility (RCU). I saw this error when trying to start RCU .../rcuHome/jdk/jre/bin/java: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory I think I remember running into this before and reading something about RCU only being supported on 32-bit Linux. I decided to try and see if I could get it to run on 64-bit Linux. I saw it was using it's own copy of java (.../rcuHome/jdk/jre/bin/java), so I decided to try and get it to use the 64-bit JRockit I had already installed. I edited the rcu script in rcuHome/bin and replaced JRE_DIR=$ORACLE_HOME/jdk/jre with JRE_DIR=/apps/java/jrockit-jdk1.6.0_29-R28.2.2-4.1.0 Sure enough that fixed it. I was able to run RCU and create the WCC schema.

    Read the article

  • Howto install google-mock on Ubuntu 12.10

    - by user1459339
    I am having hard time trying to install Google C++ Mocking Framework. I have successfully run sudo apt-get install google-mock. Then I tried to compile this sample file #include "gmock/gmock.h" int main(int argc, char** argv) { ::testing::InitGoogleMock(&argc, argv); return RUN_ALL_TESTS(); } with g++ -lgmock main.cpp and these errors have shown main.cpp:(.text+0x1e): undefined reference to `testing::InitGoogleMock(int*, char**)' main.cpp:(.text+0x23): undefined reference to `testing::UnitTest::GetInstance()' main.cpp:(.text+0x2b): undefined reference to `testing::UnitTest::Run()' collect2: error: ld returned 1 exit status I guess the linker can not find the library files. Does anybody know how to fix this?

    Read the article

  • dovecot can't compact mail folder /var/mail/username

    - by G. He
    ubuntu 11.10 32bit. Setup a dovecot imap server. Using Thunderbird on a different ubuntu machine (64bit) to access imap server. Everything else is fine, except I can not compact the deleted email in inbox, which is stored at /var/mail/username. Checking mail.log and I see this error message: Apr 3 00:10:11 autumn dovecot: imap(username): Error: file_dotlock_create(/var/mail/username) failed: Permission denied (euid=1000(username) egid=1000(username) missing +w perm: /var/mail, euid is not dir owner) (set mail_privileged_group=mail) what is wrong with the permission? Here are the permissions for the relevant files: $ ls -ld /var/mail drwxrwsr-x 2 mail mail 4096 2012-04-02 23:36 /var/mail $ ls -l /var/mail/username -rw------- 1 username mail 417 2012-04-02 23:36 /var/mail/username Anyone knows what's going on here?

    Read the article

  • what packages should I install in ubuntu 12.04 to fulfill opengl requirements for using nouveau driver?

    - by karolszk
    I try to switch from nvidia to nouveau driver via script: !/bin/bash stop gdm rmmod nvidia sed -i "s/nouveau/nvidia/" /etc/modprobe.d/blacklist-nvidia-nouveau.conf update-alternatives --set gl_conf /usr/lib/mesa/ld.so.conf ldconfig modprobe nouveau cp /etc/X11/xorg.conf{.nouveau,} start gdm and driver is loaded and X started but compiz it doesn't. In .xsession-errors I see: Compiz (opengl) - Fatal: Root visual is not a GL visual compiz (opengl) - Error: initScreen failed compiz (core) - Error: Couldn't activate plugin 'opengl' Compiz (opengl) - Fatal: Root visual is not a GL visual Compiz (opengl) - Fatal: Root visual is not a GL visual Compiz (opengl) - Fatal: Root visual is not a GL visual Compiz (opengl) - Fatal: Root visual is not a GL visual Compiz (opengl) - Fatal: Root visual is not a GL visual Compiz (opengl) - Fatal: Root visual is not a GL visual Compiz (opengl) - Fatal: Root visual is not a GL visual Compiz (opengl) - Fatal: Root visual is not a GL visual gnome-session[19075]: WARNING: App 'compiz.desktop' respawning too quickly gnome-session[19075]: WARNING: Application 'compiz.desktop' killed by signal gnome-session[19075]: WARNING: App 'compiz.desktop' respawning too quickly what I'm doing wrong??

    Read the article

  • Winetricks fails to find program files directory

    - by EgyptLovesUbuntu
    I installed a fresh copy of Ubuntu 12 desktop then: Installed WINE from the Ubuntu Software Center. Installed WineTricks from the Ubuntu Software Center. When I type the following commands in the terminal: sudo winetricks dotnet40 I get this error message: wine cmd.exe /c echo '%ProgramFiles%' returned empty string If i try the command without sudo winetricks dotnet40 The output is as follows Executing w_do_call dotnet40 Executing load_dotnet40 ------------------------------------------------------ dotnet40 does not yet fully work or install on wine. Caveat emptor. ------------------------------------------------------ Executing mkdir -p /home/vectoruser/.cache/winetricks/dotnet40 mkdir: cannot create directory `/home/vectoruser/.cache/winetricks/dotnet40': Permission denied ------------------------------------------------------ Note: command 'mkdir -p /home/vectoruser/.cache/winetricks/dotnet40' returned status 1. Aborting. ------------------------------------------------------ My current user is vectoruser which i use to logon to Ubuntu The output of ls -ld /home/vectoruser /home/vectoruser/.cache /home/vectoruser/.cache/winetricks Gives: drwxr-xr-x 32 vectoruser vectoruser 4096 Aug 2 19:26 /home/vectoruser drwx------ 19 vectoruser vectoruser 4096 Aug 2 19:25 /home/vectoruser/.cache drwxr-xr-x 2 root root 4096 Aug 2 18:09 /home/vectoruser/.cache/winetricks

    Read the article

  • Can't Log in to Lubuntu 12.04 X Server

    - by isomorphismes
    As of rebooting yesterday I can't login as myself to the X server part of 64-bit Lubuntu 12.04. Same problem as Can not get passed the login screen but that solution didn't work for me. Troubleshooting steps I already took: I can log in as guest (with whatever window manager) to the graphic (X) view of Lubuntu. log in as myself into a virtual terminal. (In fact I'm writing this from w3m for that reason.) So I know my password is correct and that most aspects of the system are working. One of the top google results for "can't log into lubuntu" mentioned a disk-full problem on netbooks; I don't have that problem. Let me know if I need to paste any messages or config files to make this question clearer and I'll do so. $ ls -l /home total 12 drwxr-xr-x 99 me me 12288 May 26 14:16 me $ ls -ld /tmp drwxrwxrwt 16 root root 4096 May 26 15:46 /tmp

    Read the article

  • Error while compiling ffmpeg during make

    - by Rahul Mehta
    I want to install ffmpeg on ubuntu. and following this article http://pasindudps.blogspot.com/2010/12/compiling-ffmpeg-in-ubuntu-1010.html but when m doing make after config Then go to the ffmpeg folder. cd ffmpeg Start the installation ./configure --enable-gpl --enable-version3 --enable-nonfree --enable-postproc \ --enable-libfaac --enable-libmp3lame --enable-libopencore-amrnb \ --enable-libopencore-amrwb --enable-libtheora --enable-libvorbis \ --enable-libvpx --enable-libx264 --enable-libxvid --enable-x11grab make giving this error /home/reach121/ffmpeg/libavcodec/x86/cabac.h:93: undefined reference to `ff_h264_norm_shift' /home/reach121/ffmpeg/libavcodec/x86/cabac.h:93: undefined reference to `ff_h264_lps_range' /home/reach121/ffmpeg/libavcodec/x86/cabac.h:93: undefined reference to `ff_h264_norm_shift' /home/reach121/ffmpeg/libavcodec/x86/cabac.h:93: undefined reference to `ff_h264_mlps_state' /home/reach121/ffmpeg/libavcodec/x86/cabac.h:93: undefined reference to `ff_h264_norm_shift' collect2: ld returned 1 exit status make: *** [ffmpeg_g] Error 1 Please suggest why this error is coming and what to do to solve this problem

    Read the article

< Previous Page | 8 9 10 11 12 13 14 15 16 17 18 19  | Next Page >