Search Results

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

Page 1/26 | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

  • G++ Compiling errors

    - by egn56
    Attempting to do some compiling with g++ and when I run g++ test.cpp this is what I get. I am in the correct directory and I have even messed with the permission settings to make those directories chmod 777 as a test, still nothing. Tried running it as sudo g++ test.cpp and getting nothing. It can compile and create a .o if i run g++ -c test.cpp but it can't seem to link it and create the .out. Any suggestions? /usr/bin/ld: 1: /usr/bin/ld: /bin: Permission denied /usr/bin/ld: 2: /usr/bin/ld: test.cpp: not found /usr/bin/ld: 3: /usr/bin/ld: test.cpp: not found /usr/bin/ld: 4: /usr/bin/ld: test.cpp: not found /usr/bin/ld: 5: /usr/bin/ld: test.cpp: not found /usr/bin/ld: 6: /usr/bin/ld: test.cpp: not found /usr/bin/ld: 7: /usr/bin/ld: test.cpp: not found /usr/bin/ld: 8: /usr/bin/ld: test.cpp: not found /usr/bin/ld: 9: /usr/bin/ld: test.cpp: not found /usr/bin/ld: 10: /usr/bin/ld: test.cpp: not found /usr/bin/ld: 11: /usr/bin/ld: test.cpp: not found /usr/bin/ld: 12: /usr/bin/ld: Syntax error: "(" unexpected collect2: ld returned 2 exit status

    Read the article

  • ld cannot find -limf -lsvml -lipgo -ldecimal -lirc

    - by Jaguaraci Silva
    I have installed the ICC recently, the XE composer 2013 version and I don't get success for running it because I have some errors to find libs that I don't know, however, I think that the artifact ia32-libs don't be found on the Ubuntu 12.04.1 can be the reason!. Thus, I got these dependencies: sudo apt-get install rpm build-essential sudo apt-get install libstdc++6 but these don't sudo apt-get install ia32-libs* or sudo apt-get install ia32-libs-multiarch I got this error always I'm trying compile on ICC: ld: cannot find -limf ld: cannot find -lsvml ld: cannot find -lipgo ld: cannot find -ldecimal ld: cannot find -lirc ld: cannot find -lsvml Thanks in advantage.

    Read the article

  • My nVidia GeForce 8600M GT card stopped working: "extension GLX missing on display 0:0"

    - by Wolter Hellmund
    So I turned on my computer and log into my gnome-shell session to find that the shell is gone, and there is instead a very thick panel with a vertically repeated pattern of the gradient the Unity panel displays. I ran some tests and found out that my graphic acceleration was failing. I have attached some outputs of some commands to help helpers help me: Some command outputs Video card: nVidia GeForce 8600M GT (note that it is not an Optimus card). Output of lspci | grep VGA: 01:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600M GT] (rev a1) Output of glxinfo: Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". Error: couldn't find RGB GLX visual or fbconfig Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". Contents of /var/log/Xorg.0.log: NVIDIA: Failed to load the NVIDIA kernel module. Please check your NVIDIA: system's kernel log for additional error messages. UnloadModule: "nvidia" Unloading nvidia Failed to load module "nvidia" (module-specific error, 0) If I use the Aditional Drivers system application, I see none of the drivers active, and when I try to activate any, I get an error telling me to check the jockey.log file. The contents of /var/log/jockey.log are: 2012-09-20 23:11:32,690 DEBUG: NVidia(nvidia_173).enabled(): target_alt None current_alt /usr/lib/nvidia-current/ld.so.conf other target alt None other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:11:32,690 DEBUG: nvidia_173 is not the alternative in use 2012-09-20 23:11:34,606 DEBUG: BroadcomWLHandler enabled(): kmod disabled, bcm43xx: blacklisted, b43: enabled, b43legacy: enabled 2012-09-20 23:11:34,657 DEBUG: NVidia(nvidia_173_updates).enabled(): target_alt None current_alt /usr/lib/nvidia-current/ld.so.conf other target alt None other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:11:34,657 DEBUG: nvidia_173_updates is not the alternative in use 2012-09-20 23:11:36,647 DEBUG: NVidia(nvidia_current).enabled(): target_alt /usr/lib/nvidia-current/ld.so.conf current_alt /usr/lib/nvidia-current/ld.so.conf other target alt /usr/lib/nvidia-current/alt_ld.so.conf other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:11:36,648 DEBUG: KMH enabled: False 2012-09-20 23:11:38,642 DEBUG: NVidia(nvidia_current_updates).enabled(): target_alt None current_alt /usr/lib/nvidia-current/ld.so.conf other target alt None other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:11:38,642 DEBUG: nvidia_current_updates is not the alternative in use 2012-09-20 23:11:40,546 DEBUG: NVidia(nvidia_173).enabled(): target_alt None current_alt /usr/lib/nvidia-current/ld.so.conf other target alt None other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:11:40,546 DEBUG: nvidia_173 is not the alternative in use 2012-09-20 23:11:40,620 DEBUG: NVidia(nvidia_173).enabled(): target_alt None current_alt /usr/lib/nvidia-current/ld.so.conf other target alt None other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:11:40,620 DEBUG: nvidia_173 is not the alternative in use 2012-09-20 23:11:40,629 DEBUG: BroadcomWLHandler enabled(): kmod disabled, bcm43xx: blacklisted, b43: enabled, b43legacy: enabled 2012-09-20 23:11:40,698 DEBUG: NVidia(nvidia_173_updates).enabled(): target_alt None current_alt /usr/lib/nvidia-current/ld.so.conf other target alt None other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:11:40,698 DEBUG: nvidia_173_updates is not the alternative in use 2012-09-20 23:11:40,759 DEBUG: NVidia(nvidia_current).enabled(): target_alt /usr/lib/nvidia-current/ld.so.conf current_alt /usr/lib/nvidia-current/ld.so.conf other target alt /usr/lib/nvidia-current/alt_ld.so.conf other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:11:40,760 DEBUG: KMH enabled: False 2012-09-20 23:11:40,826 DEBUG: NVidia(nvidia_current_updates).enabled(): target_alt None current_alt /usr/lib/nvidia-current/ld.so.conf other target alt None other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:11:40,826 DEBUG: nvidia_current_updates is not the alternative in use 2012-09-20 23:11:45,415 DEBUG: NVidia(nvidia_current).enabled(): target_alt /usr/lib/nvidia-current/ld.so.conf current_alt /usr/lib/nvidia-current/ld.so.conf other target alt /usr/lib/nvidia-current/alt_ld.so.conf other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:11:45,415 DEBUG: KMH enabled: False 2012-09-20 23:11:47,367 DEBUG: NVidia(nvidia_current).enabled(): target_alt /usr/lib/nvidia-current/ld.so.conf current_alt /usr/lib/nvidia-current/ld.so.conf other target alt /usr/lib/nvidia-current/alt_ld.so.conf other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:11:47,367 DEBUG: KMH enabled: False 2012-09-20 23:11:55,961 WARNING: modinfo for module nvidia_current failed: ERROR: modinfo: could not find module nvidia_current 2012-09-20 23:11:55,962 ERROR: XorgDriverHandler.enable(): package or module not installed, aborting 2012-09-20 23:12:27,780 DEBUG: NVidia(nvidia_current).enabled(): target_alt /usr/lib/nvidia-current/ld.so.conf current_alt /usr/lib/nvidia-current/ld.so.conf other target alt /usr/lib/nvidia-current/alt_ld.so.conf other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:12:27,781 DEBUG: KMH enabled: False 2012-09-20 23:12:27,840 DEBUG: NVidia(nvidia_current).enabled(): target_alt /usr/lib/nvidia-current/ld.so.conf current_alt /usr/lib/nvidia-current/ld.so.conf other target alt /usr/lib/nvidia-current/alt_ld.so.conf other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:12:27,840 DEBUG: KMH enabled: False 2012-09-20 23:12:43,196 DEBUG: NVidia(nvidia_173).enabled(): target_alt None current_alt /usr/lib/nvidia-current/ld.so.conf other target alt None other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:12:43,197 DEBUG: nvidia_173 is not the alternative in use 2012-09-20 23:12:43,208 DEBUG: BroadcomWLHandler enabled(): kmod disabled, bcm43xx: blacklisted, b43: enabled, b43legacy: enabled 2012-09-20 23:12:43,269 DEBUG: NVidia(nvidia_173_updates).enabled(): target_alt None current_alt /usr/lib/nvidia-current/ld.so.conf other target alt None other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:12:43,269 DEBUG: nvidia_173_updates is not the alternative in use 2012-09-20 23:12:43,333 DEBUG: NVidia(nvidia_current).enabled(): target_alt /usr/lib/nvidia-current/ld.so.conf current_alt /usr/lib/nvidia-current/ld.so.conf other target alt /usr/lib/nvidia-current/alt_ld.so.conf other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:12:43,333 DEBUG: KMH enabled: False 2012-09-20 23:12:43,393 DEBUG: NVidia(nvidia_current).enabled(): target_alt /usr/lib/nvidia-current/ld.so.conf current_alt /usr/lib/nvidia-current/ld.so.conf other target alt /usr/lib/nvidia-current/alt_ld.so.conf other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:12:43,394 DEBUG: KMH enabled: False 2012-09-20 23:12:43,465 DEBUG: NVidia(nvidia_current_updates).enabled(): target_alt None current_alt /usr/lib/nvidia-current/ld.so.conf other target alt None other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:12:43,465 DEBUG: nvidia_current_updates is not the alternative in use 2012-09-20 23:12:43,531 DEBUG: NVidia(nvidia_current).enabled(): target_alt /usr/lib/nvidia-current/ld.so.conf current_alt /usr/lib/nvidia-current/ld.so.conf other target alt /usr/lib/nvidia-current/alt_ld.so.conf other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:12:43,531 DEBUG: KMH enabled: False 2012-09-20 23:12:43,587 DEBUG: NVidia(nvidia_current).enabled(): target_alt /usr/lib/nvidia-current/ld.so.conf current_alt /usr/lib/nvidia-current/ld.so.conf other target alt /usr/lib/nvidia-current/alt_ld.so.conf other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:12:43,587 DEBUG: KMH enabled: False 2012-09-20 23:12:43,663 DEBUG: NVidia(nvidia_173).enabled(): target_alt None current_alt /usr/lib/nvidia-current/ld.so.conf other target alt None other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:12:43,663 DEBUG: nvidia_173 is not the alternative in use 2012-09-20 23:12:43,672 DEBUG: BroadcomWLHandler enabled(): kmod disabled, bcm43xx: blacklisted, b43: enabled, b43legacy: enabled 2012-09-20 23:12:43,738 DEBUG: NVidia(nvidia_173_updates).enabled(): target_alt None current_alt /usr/lib/nvidia-current/ld.so.conf other target alt None other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:12:43,739 DEBUG: nvidia_173_updates is not the alternative in use 2012-09-20 23:12:43,803 DEBUG: NVidia(nvidia_current).enabled(): target_alt /usr/lib/nvidia-current/ld.so.conf current_alt /usr/lib/nvidia-current/ld.so.conf other target alt /usr/lib/nvidia-current/alt_ld.so.conf other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:12:43,803 DEBUG: KMH enabled: False 2012-09-20 23:12:43,863 DEBUG: NVidia(nvidia_current).enabled(): target_alt /usr/lib/nvidia-current/ld.so.conf current_alt /usr/lib/nvidia-current/ld.so.conf other target alt /usr/lib/nvidia-current/alt_ld.so.conf other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:12:43,863 DEBUG: KMH enabled: False 2012-09-20 23:12:43,930 DEBUG: NVidia(nvidia_current_updates).enabled(): target_alt None current_alt /usr/lib/nvidia-current/ld.so.conf other target alt None other current alt /usr/lib/nvidia-current/alt_ld.so.conf 2012-09-20 23:12:43,930 DEBUG: nvidia_current_updates is not the alternative in use 2012-09-20 23:24:16,305 DEBUG: Shutting down Things I have tried Checked the video card on a Windows session. Reran nvidia-xconfig. Purged all nvidia software from my computer, and reinstall it. Run nvidia-xconfig. Tried a different kernel.

    Read the article

  • FreeBSD 8.1 64bit logrotate - ELF interpreter /libexec/ld-elf-so.1 not found

    - by Richard Knop
    I am trying to get logrotate running on a FreeBSD 8.1 virtual machine. I installed the logrotate with pkg_add, I have created the logrotate.config file and also run: mkdir /var/lib/ touch /var/lib/logrotate.status Now when I do: /usr/local/sbin/logrotate -d /usr/local/etc/logrotate.conf I get this error: ELF interpreter /libexec/ld-elf-so.1 not found Abort The file ld-elf-so.1 exists: locate ld-elf.so.1 /libexec/ld-elf.so.1 /usr/libexec/ld-elf.so.1 /usr/share/man/man1/ld-elf.so.1.1.gz

    Read the article

  • glui /usr/bin/ld: cannot find -lXmu

    - by Myx
    Hello: I have downloaded the latest GLUI source code and now I am trying to compile it. When I do so, I get the following error: g++ -O0 -Wall -pedantic -I./ -I./include -I/usr/X11R6/include -o bin/example1 example/example1.cpp -L./lib -lglui -L/usr/X11R6/lib/libXdmcp.a -lglut -lGLU -lGL -lXmu -lXext -lX11 -lXi -lm /usr/bin/ld: cannot find -lXmu collect2: ld returned 1 exit status When I did a locate libXmu, I get the following output: > %:~/src/GLUI/src$ locate libXmu > /usr/lib/libXmu.so.6 > /usr/lib/libXmu.so.6.2.0 > /usr/lib/libXmuu.so.1 > /usr/lib/libXmuu.so.1.0.0 Do I get the error because I don't have a /usr/lib/libXmu.so? If this is the case, how can I make one? (I am not experienced with linking at all). Thanks!

    Read the article

  • GNU ld removes section

    - by Jonatan
    I'm writing a boot script for an ARM-Cortex M3 based device. If I compile the assembler boot script and the C application code and then combine the object files and transfer them to my device everything works. However, if I use ar to create an archive (libboot.a) and combine that archive with the C application there is a problem: I've put the boot code in a section: .section .boot, "ax" .global _start _start: .word 0x10000800 /* Initial stack pointer (FIXME!) */ .word start .word nmi_handler .word hard_fault_handler ... etc ... I've found that ld strips this from the final binary (the section "boot" is not available). This is quite natural as there is no dependency on it that ld knows about, but it causes the device to not boot correctly. So my question is: what is the best way to force this code to be included?

    Read the article

  • GCC (ld) option to strip unreferenced data/functions

    - by legends2k
    I've written an program which uses a library which has numerous functuions, but I only limited functions from it. GCC is the compiler I use. Once I've created a binary, when I used nm to see the symbols in it, it shows all the unwanted (unreferenced) functions which are never used. How do I removed those unreferenced functions and data from the executable? Is the -s option right? I'm tols that it strips all symbol table and relocation data from the binary, but does this remove the function and data too? I'm not sure on how to verify this too, since after using -s nm doesn't work since it's stripped all sym. table data too.

    Read the article

  • nvidia driver problem after update

    - by baltasar
    I know there are a lot of posts about nvdia driver, but I am not able to solve this. I updated my configuration yesterday, September 27th, and it seems that a new nvidia driver was involved. The updated completed with an error, and invited me to send a bug report automatically. I send it, but it finally said that there was no place to send the bug report to. Today I updated again, and a new kernel was there. Then I rebooted. I found a desktop in 640x480 with a horrible, unreadable font. I run jockey and tried to go back to another version of the nvidia driver, but it seems that none of the drivers listed there are suddenly valid. I have the x-swat repository enabled, because I remember that I had a similar issue in the past that was only to be solved with the newest driver. jockey log: 2012-09-28 11:22:24,747 DEBUG: Selecting previously unselected package nvidia-173. (Reading database ... 536311 files and directories currently installed.) Unpacking nvidia-173 (from .../nvidia-173_173.14.35-0ubuntu0.2_i386.deb) ... Processing triggers for man-db ... Setting up nvidia-173 (173.14.35-0ubuntu0.2) ... Loading new nvidia-173-173.14.35 DKMS files... Building only for 3.2.0-32-generic-pae Building for architecture i686 Building initial module for 3.2.0-32-generic-pae Error! Bad return status for module build on kernel: 3.2.0-32-generic-pae (i686) Consult /var/lib/dkms/nvidia-173/173.14.35/build/make.log for more information. Processing triggers for bamfdaemon ... Rebuilding /usr/share/applications/bamf.index... 2012-09-28 11:22:25,143 WARNING: modinfo for module nvidia_173 failed: ERROR: modinfo: could not find module nvidia_173 2012-09-28 11:22:25,143 ERROR: XorgDriverHandler.enable(): package or module not installed, aborting 2012-09-28 11:22:53,613 DEBUG: NVidia(nvidia_173).enabled(): target_alt /usr/lib/nvidia-173/ld.so.conf current_alt /usr/lib/nvidia-173/ld.so.conf other target alt /usr/lib/nvidia-173/alt_ld.so.conf other current alt /usr/lib/nvidia-173/alt_ld.so.conf 2012-09-28 11:22:53,613 DEBUG: KMH enabled: False 2012-09-28 11:22:53,629 DEBUG: NVidia(nvidia_173).enabled(): target_alt /usr/lib/nvidia-173/ld.so.conf current_alt /usr/lib/nvidia-173/ld.so.conf other target alt /usr/lib/nvidia-173/alt_ld.so.conf other current alt /usr/lib/nvidia-173/alt_ld.so.conf 2012-09-28 11:22:53,629 DEBUG: KMH enabled: False 2012-09-28 11:23:01,943 DEBUG: NVidia(nvidia_173).enabled(): target_alt /usr/lib/nvidia-173/ld.so.conf current_alt /usr/lib/nvidia-173/ld.so.conf other target alt /usr/lib/nvidia-173/alt_ld.so.conf other current alt /usr/lib/nvidia-173/alt_ld.so.conf 2012-09-28 11:23:01,943 DEBUG: KMH enabled: False 2012-09-28 11:23:01,962 DEBUG: NVidia(nvidia_173).enabled(): target_alt /usr/lib/nvidia-173/ld.so.conf current_alt /usr/lib/nvidia-173/ld.so.conf other target alt /usr/lib/nvidia-173/alt_ld.so.conf other current alt /usr/lib/nvidia-173/alt_ld.so.conf 2012-09-28 11:23:01,963 DEBUG: KMH enabled: False 2012-09-28 11:23:01,998 DEBUG: NVidia(nvidia_173_updates).enabled(): target_alt None current_alt /usr/lib/nvidia-173/ld.so.conf other target alt None other current alt /usr/lib/nvidia-173/alt_ld.so.conf 2012-09-28 11:23:01,998 DEBUG: nvidia_173_updates is not the alternative in use 2012-09-28 11:23:02,044 DEBUG: NVidia(nvidia_current).enabled(): target_alt /usr/lib/nvidia-current/ld.so.conf current_alt /usr/lib/nvidia-173/ld.so.conf other target alt /usr/lib/nvidia-current/alt_ld.so.conf other current alt /usr/lib/nvidia-173/alt_ld.so.conf 2012-09-28 11:23:02,044 DEBUG: nvidia_current is not the alternative in use 2012-09-28 11:23:02,066 DEBUG: NVidia(nvidia_current).enabled(): target_alt /usr/lib/nvidia-current/ld.so.conf current_alt /usr/lib/nvidia-173/ld.so.conf other target alt /usr/lib/nvidia-current/alt_ld.so.conf other current alt /usr/lib/nvidia-173/alt_ld.so.conf 2012-09-28 11:23:02,066 DEBUG: nvidia_current is not the alternative in use 2012-09-28 11:23:02,106 DEBUG: NVidia(nvidia_current_updates).enabled(): target_alt None current_alt /usr/lib/nvidia-173/ld.so.conf other target alt None other current alt /usr/lib/nvidia-173/alt_ld.so.conf 2012-09-28 11:23:02,106 DEBUG: nvidia_current_updates is not the alternative in use 2012-09-28 11:23:02,157 DEBUG: NVidia(nvidia_173).enabled(): target_alt /usr/lib/nvidia-173/ld.so.conf current_alt /usr/lib/nvidia-173/ld.so.conf other target alt /usr/lib/nvidia-173/alt_ld.so.conf other current alt /usr/lib/nvidia-173/alt_ld.so.conf 2012-09-28 11:23:02,157 DEBUG: KMH enabled: False 2012-09-28 11:23:02,177 DEBUG: NVidia(nvidia_173).enabled(): target_alt /usr/lib/nvidia-173/ld.so.conf current_alt /usr/lib/nvidia-173/ld.so.conf other target alt /usr/lib/nvidia-173/alt_ld.so.conf other current alt /usr/lib/nvidia-173/alt_ld.so.conf 2012-09-28 11:23:02,178 DEBUG: KMH enabled: False 2012-09-28 11:23:02,245 DEBUG: NVidia(nvidia_173).enabled(): target_alt /usr/lib/nvidia-173/ld.so.conf current_alt /usr/lib/nvidia-173/ld.so.conf other target alt /usr/lib/nvidia-173/alt_ld.so.conf other current alt /usr/lib/nvidia-173/alt_ld.so.conf 2012-09-28 11:23:02,245 DEBUG: KMH enabled: False 2012-09-28 11:23:02,272 DEBUG: NVidia(nvidia_173).enabled(): target_alt /usr/lib/nvidia-173/ld.so.conf current_alt /usr/lib/nvidia-173/ld.so.conf other target alt /usr/lib/nvidia-173/alt_ld.so.conf other current alt /usr/lib/nvidia-173/alt_ld.so.conf 2012-09-28 11:23:02,273 DEBUG: KMH enabled: False 2012-09-28 11:23:02,303 DEBUG: NVidia(nvidia_173_updates).enabled(): target_alt None current_alt /usr/lib/nvidia-173/ld.so.conf other target alt None other current alt /usr/lib/nvidia-173/alt_ld.so.conf 2012-09-28 11:23:02,303 DEBUG: nvidia_173_updates is not the alternative in use 2012-09-28 11:23:02,330 DEBUG: NVidia(nvidia_current).enabled(): target_alt /usr/lib/nvidia-current/ld.so.conf current_alt /usr/lib/nvidia-173/ld.so.conf other target alt /usr/lib/nvidia-current/alt_ld.so.conf other current alt /usr/lib/nvidia-173/alt_ld.so.conf 2012-09-28 11:23:02,410 DEBUG: nvidia_current is not the alternative in use 2012-09-28 11:23:02,427 DEBUG: NVidia(nvidia_current).enabled(): target_alt /usr/lib/nvidia-current/ld.so.conf current_alt /usr/lib/nvidia-173/ld.so.conf other target alt /usr/lib/nvidia-current/alt_ld.so.conf other current alt /usr/lib/nvidia-173/alt_ld.so.conf 2012-09-28 11:23:02,428 DEBUG: nvidia_current is not the alternative in use 2012-09-28 11:23:02,457 DEBUG: NVidia(nvidia_current_updates).enabled(): target_alt None current_alt /usr/lib/nvidia-173/ld.so.conf other target alt None other current alt /usr/lib/nvidia-173/alt_ld.so.conf 2012-09-28 11:23:02,458 DEBUG: nvidia_current_updates is not the alternative in use

    Read the article

  • "/usr/bin/ld: cannot find -lboost_python-mt" error when installing pycuda 2011.2.2

    - by maxrider11
    I am installing pycuda2011.2.2 on ubuntu 11.10, but can't complete it. When i do pycuda-2011.2.2 $ make -j 4 I get this error: /usr/bin/ld: cannot find -lboost_python-mt , /usr/bin/ld: cannot find -lcuda I got 1 exact problem match in google search and solution as well : $ sudo ln -s /usr/lib/libboost_python-mt-py26 /usr/lib/libboost_python-mt But booooom, My problem doesn't vanish. It makes me wonder that why there are no relavant results in google search, as if only I have this problem. What is wrong ? Any help is appreciated. Thanks,

    Read the article

  • Nagging As A Strategy For Better Linking: -z guidance

    - by user9154181
    The link-editor (ld) in Solaris 11 has a new feature that we call guidance that is intended to help you build better objects. The basic idea behind guidance is that if (and only if) you request it, the link-editor will issue messages suggesting better options and other changes you might make to your ld command to get better results. You can choose to take the advice, or you can disable specific types of guidance while acting on others. In some ways, this works like an experienced friend leaning over your shoulder and giving you advice — you're free to take it or leave it as you see fit, but you get nudged to do a better job than you might have otherwise. We use guidance to build the core Solaris OS, and it has proven to be useful, both in improving our objects, and in making sure that regressions don't creep back in later. In this article, I'm going to describe the evolution in thinking and design that led to the implementation of the -z guidance option, as well as give a brief description of how it works. The guidance feature issues non-fatal warnings. However, experience shows that once developers get used to ignoring warnings, it is inevitable that real problems will be lost in the noise and ignored or missed. This is why we have a zero tolerance policy against build noise in the core Solaris OS. In order to get maximum benefit from -z guidance while maintaining this policy, I added the -z fatal-warnings option at the same time. Much of the material presented here is adapted from the arc case: PSARC 2010/312 Link-editor guidance The History Of Unfortunate Link-Editor Defaults The Solaris link-editor is one of the oldest Unix commands. It stands to reason that this would be true — in order to write an operating system, you need the ability to compile and link code. The original link-editor (ld) had defaults that made sense at the time. As new features were needed, command line option switches were added to let the user use them, while maintaining backward compatibility for those who didn't. Backward compatibility is always a concern in system design, but is particularly important in the case of the tool chain (compilers, linker, and related tools), since it is a basic building block for the entire system. Over the years, applications have grown in size and complexity. Important concepts like dynamic linking that didn't exist in the original Unix system were invented. Object file formats changed. In the case of System V Release 4 Unix derivatives like Solaris, the ELF (Extensible Linking Format) was adopted. Since then, the ELF system has evolved to provide tools needed to manage today's larger and more complex environments. Features such as lazy loading, and direct bindings have been added. In an ideal world, many of these options would be defaults, with rarely used options that allow the user to turn them off. However, the reality is exactly the reverse: For backward compatibility, these features are all options that must be explicitly turned on by the user. This has led to a situation in which most applications do not take advantage of the many improvements that have been made in linking over the last 20 years. If their code seems to link and run without issue, what motivation does a developer have to read a complex manpage, absorb the information provided, choose the features that matter for their application, and apply them? Experience shows that only the most motivated and diligent programmers will make that effort. We know that most programs would be improved if we could just get you to use the various whizzy features that we provide, but the defaults conspire against us. We have long wanted to do something to make it easier for our users to use the linkers more effectively. There have been many conversations over the years regarding this issue, and how to address it. They always break down along the following lines: Change ld Defaults Since the world would be a better place the newer ld features were the defaults, why not change things to make it so? This idea is simple, elegant, and impossible. Doing so would break a large number of existing applications, including those of ISVs, big customers, and a plethora of existing open source packages. In each case, the owner of that code may choose to follow our lead and fix their code, or they may view it as an invitation to reconsider their commitment to our platform. Backward compatibility, and our installed base of working software, is one of our greatest assets, and not something to be lightly put at risk. Breaking backward compatibility at this level of the system is likely to do more harm than good. But, it sure is tempting. New Link-Editor One might create a new linker command, not called 'ld', leaving the old command as it is. The new one could use the same code as ld, but would offer only modern options, with the proper defaults for features such as direct binding. The resulting link-editor would be a pleasure to use. However, the approach is doomed to niche status. There is a vast pile of exiting code in the world built around the existing ld command, that reaches back to the 1970's. ld use is embedded in large and unknown numbers of makefiles, and is used by name by compilers that execute it. A Unix link-editor that is not named ld will not find a majority audience no matter how good it might be. Finally, a new linker command will eventually cease to be new, and will accumulate its own burden of backward compatibility issues. An Option To Make ld Do The Right Things Automatically This line of reasoning is best summarized by a CR filed in 2005, entitled 6239804 make it easier for ld(1) to do what's best The idea is to have a '-z best' option that unchains ld from its backward compatibility commitment, and allows it to turn on the "best" set of features, as determined by the authors of ld. The specific set of features enabled by -z best would be subject to change over time, as requirements change. This idea is more realistic than the other two, but was never implemented because it has some important issues that we could never answer to our satisfaction: The -z best proposal assumes that the user can turn it on, and trust it to select good options without the user needing to be aware of the options being applied. This is a fallacy. Features such as direct bindings require the user to do some analysis to ensure that the resulting program will still operate properly. A user who is willing to do the work to verify that what -z best does will be OK for their application is capable of turning on those features directly, and therefore gains little added benefit from -z best. The intent is that when a user opts into -z best, that they understand that z best is subject to sometimes incompatible evolution. Experience teaches us that this won't work. People will use this feature, the meaning of -z best will change, code that used to build will fail, and then there will be complaints and demands to retract the change. When (not if) this occurs, we will of course defend our actions, and point at the disclaimer. We'll win some of those debates, and lose others. Ultimately, we'll end up with -z best2 (-z better), or other compromises, and our goal of simplifying the world will have failed. The -z best idea rolls up a set of features that may or may not be related to each other into a unit that must be taken wholesale, or not at all. It could be that only a subset of what it does is compatible with a given application, in which case the user is expected to abandon -z best and instead set the options that apply to their application directly. In doing so, they lose one of the benefits of -z best, that if you use it, future versions of ld may choose a different set of options, and automatically improve the object through the act of rebuilding it. I drew two conclusions from the above history: For a link-editor, backward compatibility is vital. If a given command line linked your application 10 years ago, you have every reason to expect that it will link today, assuming that the libraries you're linking against are still available and compatible with their previous interfaces. For an application of any size or complexity, there is no substitute for the work involved in examining the code and determining which linker options apply and which do not. These options are largely orthogonal to each other, and it can be reasonable not to use any or all of them, depending on the situation, even in modern applications. It is a mistake to tie them together. The idea for -z guidance came from consideration of these points. By decoupling the advice from the act of taking the advice, we can retain the good aspects of -z best while avoiding its pitfalls: -z guidance gives advice, but the decision to take that advice remains with the user who must evaluate its merit and make a decision to take it or not. As such, we are free to change the specific guidance given in future releases of ld, without breaking existing applications. The only fallout from this will be some new warnings in the build output, which can be ignored or dealt with at the user's convenience. It does not couple the various features given into a single "take it or leave it" option, meaning that there will never be a need to offer "-zguidance2", or other such variants as things change over time. Guidance has the potential to be our final word on this subject. The user is given the flexibility to disable specific categories of guidance without losing the benefit of others, including those that might be added to future versions of the system. Although -z fatal-warnings stands on its own as a useful feature, it is of particular interest in combination with -z guidance. Used together, the guidance turns from advice to hard requirement: The user must either make the suggested change, or explicitly reject the advice by specifying a guidance exception token, in order to get a build. This is valuable in environments with high coding standards. ld Command Line Options The guidance effort resulted in new link-editor options for guidance and for turning warnings into fatal errors. Before I reproduce that text here, I'd like to highlight the strategic decisions embedded in the guidance feature: In order to get guidance, you have to opt in. We hope you will opt in, and believe you'll get better objects if you do, but our default mode of operation will continue as it always has, with full backward compatibility, and without judgement. Guidance suggestions always offers specific advice, and not vague generalizations. You can disable some guidance without turning off the entire feature. When you get guidance warnings, you can choose to take the advice, or you can specify a keyword to disable guidance for just that category. This allows you to get guidance for things that are useful to you, without being bothered about things that you've already considered and dismissed. As the world changes, we will add new guidance to steer you in the right direction. All such new guidance will come with a keyword that let's you turn it off. In order to facilitate building your code on different versions of Solaris, we quietly ignore any guidance keywords we don't recognize, assuming that they are intended for newer versions of the link-editor. If you want to see what guidance tokens ld does and does not recognize on your system, you can use the ld debugging feature as follows: % ld -Dargs -z guidance=foo,nodefs debug: debug: Solaris Linkers: 5.11-1.2275 debug: debug: arg[1] option=-D: option-argument: args debug: arg[2] option=-z: option-argument: guidance=foo,nodefs debug: warning: unrecognized -z guidance item: foo The -z fatal-warning option is straightforward, and generally useful in environments with strict coding standards. Note that the GNU ld already had this feature, and we accept their option names as synonyms: -z fatal-warnings | nofatal-warnings --fatal-warnings | --no-fatal-warnings The -z fatal-warnings and the --fatal-warnings option cause the link-editor to treat warnings as fatal errors. The -z nofatal-warnings and the --no-fatal-warnings option cause the link-editor to treat warnings as non-fatal. This is the default behavior. The -z guidance option is defined as follows: -z guidance[=item1,item2,...] Provide guidance messages to suggest ld options that can improve the quality of the resulting object, or which are otherwise considered to be beneficial. The specific guidance offered is subject to change over time as the system evolves. Obsolete guidance offered by older versions of ld may be dropped in new versions. Similarly, new guidance may be added to new versions of ld. Guidance therefore always represents current best practices. It is possible to enable guidance, while preventing specific guidance messages, by providing a list of item tokens, representing the class of guidance to be suppressed. In this way, unwanted advice can be suppressed without losing the benefit of other guidance. Unrecognized item tokens are quietly ignored by ld, allowing a given ld command line to be executed on a variety of older or newer versions of Solaris. The guidance offered by the current version of ld, and the item tokens used to disable these messages, are as follows. Specify Required Dependencies Dynamic executables and shared objects should explicitly define all of the dependencies they require. Guidance recommends the use of the -z defs option, should any symbol references remain unsatisfied when building dynamic objects. This guidance can be disabled with -z guidance=nodefs. Do Not Specify Non-Required Dependencies Dynamic executables and shared objects should not define any dependencies that do not satisfy the symbol references made by the dynamic object. Guidance recommends that unused dependencies be removed. This guidance can be disabled with -z guidance=nounused. Lazy Loading Dependencies should be identified for lazy loading. Guidance recommends the use of the -z lazyload option should any dependency be processed before either a -z lazyload or -z nolazyload option is encountered. This guidance can be disabled with -z guidance=nolazyload. Direct Bindings Dependencies should be referenced with direct bindings. Guidance recommends the use of the -B direct, or -z direct options should any dependency be processed before either of these options, or the -z nodirect option is encountered. This guidance can be disabled with -z guidance=nodirect. Pure Text Segment Dynamic objects should not contain relocations to non-writable, allocable sections. Guidance recommends compiling objects with Position Independent Code (PIC) should any relocations against the text segment remain, and neither the -z textwarn or -z textoff options are encountered. This guidance can be disabled with -z guidance=notext. Mapfile Syntax All mapfiles should use the version 2 mapfile syntax. Guidance recommends the use of the version 2 syntax should any mapfiles be encountered that use the version 1 syntax. This guidance can be disabled with -z guidance=nomapfile. Library Search Path Inappropriate dependencies that are encountered by ld are quietly ignored. For example, a 32-bit dependency that is encountered when generating a 64-bit object is ignored. These dependencies can result from incorrect search path settings, such as supplying an incorrect -L option. Although benign, this dependency processing is wasteful, and might hide a build problem that should be solved. Guidance recommends the removal of any inappropriate dependencies. This guidance can be disabled with -z guidance=nolibpath. In addition, -z guidance=noall can be used to entirely disable the guidance feature. See Chapter 7, Link-Editor Quick Reference, in the Linker and Libraries Guide for more information on guidance and advice for building better objects. Example The following example demonstrates how the guidance feature is intended to work. We will build a shared object that has a variety of shortcomings: Does not specify all it's dependencies Specifies dependencies it does not use Does not use direct bindings Uses a version 1 mapfile Contains relocations to the readonly allocable text (not PIC) This scenario is sadly very common — many shared objects have one or more of these issues. % cat hello.c #include <stdio.h> #include <unistd.h> void hello(void) { printf("hello user %d\n", getpid()); } % cat mapfile.v1 # This version 1 mapfile will trigger a guidance message % cc hello.c -o hello.so -G -M mapfile.v1 -lelf As you can see, the operation completes without error, resulting in a usable object. However, turning on guidance reveals a number of things that could be better: % cc hello.c -o hello.so -G -M mapfile.v1 -lelf -zguidance ld: guidance: version 2 mapfile syntax recommended: mapfile.v1 ld: guidance: -z lazyload option recommended before first dependency ld: guidance: -B direct or -z direct option recommended before first dependency Undefined first referenced symbol in file getpid hello.o (symbol belongs to implicit dependency /lib/libc.so.1) printf hello.o (symbol belongs to implicit dependency /lib/libc.so.1) ld: warning: symbol referencing errors ld: guidance: -z defs option recommended for shared objects ld: guidance: removal of unused dependency recommended: libelf.so.1 warning: Text relocation remains referenced against symbol offset in file .rodata1 (section) 0xa hello.o getpid 0x4 hello.o printf 0xf hello.o ld: guidance: position independent (PIC) code recommended for shared objects ld: guidance: see ld(1) -z guidance for more information Given the explicit advice in the above guidance messages, it is relatively easy to modify the example to do the right things: % cat mapfile.v2 # This version 2 mapfile will not trigger a guidance message $mapfile_version 2 % cc hello.c -o hello.so -Kpic -G -Bdirect -M mapfile.v2 -lc -zguidance There are situations in which the guidance does not fit the object being built. For instance, you want to build an object without direct bindings: % cc -Kpic hello.c -o hello.so -G -M mapfile.v2 -lc -zguidance ld: guidance: -B direct or -z direct option recommended before first dependency ld: guidance: see ld(1) -z guidance for more information It is easy to disable that specific guidance warning without losing the overall benefit from allowing the remainder of the guidance feature to operate: % cc -Kpic hello.c -o hello.so -G -M mapfile.v2 -lc -zguidance=nodirect Conclusions The linking guidelines enforced by the ld guidance feature correspond rather directly to our standards for building the core Solaris OS. I'm sure that comes as no surprise. It only makes sense that we would want to build our own product as well as we know how. Solaris is usually the first significant test for any new linker feature. We now enable guidance by default for all builds, and the effect has been very positive. Guidance helps us find suboptimal objects more quickly. Programmers get concrete advice for what to change instead of vague generalities. Even in the cases where we override the guidance, the makefile rules to do so serve as documentation of the fact. Deciding to use guidance is likely to cause some up front work for most code, as it forces you to consider using new features such as direct bindings. Such investigation is worthwhile, but does not come for free. However, the guidance suggestions offer a structured and straightforward way to tackle modernizing your objects, and once that work is done, for keeping them that way. The investment is often worth it, and will replay you in terms of better performance and fewer problems. I hope that you find guidance to be as useful as we have.

    Read the article

  • javaws crashes, error in ld-linux-x86-64.so.2

    - by user54214
    I am running Ubuntu 11.10 64 bit client as Dom0 and Xen. I am having problems getting java up and running. Java itself seems to work fine, however I get strange errors, for example when I start javaws. I tried different versions and always get the same errors. I tried openjdk 1.6 and 1.7 as well as sunjava6 and 7. I alway get an error in the same lib All other applications are working fine, so it seems ld-linux-x86-64.so.2 is working fine. Any hints what could be wrong? Ubuntu01:~$ javaws # # A fatal error has been detected by the Java Runtime Environment: # # SIGILL (0x4) at pc=0x00007f4e74c5ad10, pid=7974, tid=139974945277696 # # JRE version: 6.0_23-b23 # Java VM: OpenJDK 64-Bit Server VM (20.0-b11 mixed mode linux-amd64 compressedoops) # Derivative: IcedTea6 1.11pre # Distribution: Ubuntu 11.10, package 6b23~pre11-0ubuntu1.11.10.2 # Problematic frame: # C [ld-linux-x86-64.so.2+0x14d10] _dl_make_stack_executable+0x2b70 # # An error report file with more information is saved as: # /home/r/hs_err_pid7974.log # # If you would like to submit a bug report, please include # instructions how to reproduce the bug and visit: # https://bugs.launchpad.net/ubuntu/+source/openjdk-6/ # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Aborted

    Read the article

  • sql query --need some suggestions

    - by benjamin button
    I have a table with list of cycle codes.CYCLE_DEFINITION. each and every cycle_code has 12 months entries in another table(PM1_CYCLE_STATE). Each and every month has a cycle_start_date and a cycle_close_date. i will check with a particular date(lets say sysdate) and check what is the current month of every cycle.additionally i will also get the list of future 3 more months of that particular cycle. the query i have written is as below: SELECT cycd,cm,sd,ed,ld FROM (SELECT pcs.cycle_code CYCD,LTRIM(pcs.cycle_month,'0')+0 CM, pcs.cycle_start_date SD,pcs.cycle_close_date ED,ld.logical_date LD FROM pm1_cycle_state pcs,logical_date ld WHERE ld.logical_date BETWEEN pcs.cycle_start_date AND pcs.cycle_close_date and ld.logical_date_type='B') UNION SELECT cycd,cm,sd,ed,ld FROM (SELECT pcs.cycle_code CYCD,DECODE(LTRIM(pcs.cycle_month,'0')+1,13,1,14,2,15,3,LTRIM(pcs.cycle_month,'0')+1) CM ,pcs.cycle_start_date SD,pcs.cycle_close_date ED,ld.logical_date LD FROM pm1_cycle_state pcs,logical_date ld WHERE ld.logical_date BETWEEN pcs.cycle_start_date AND pcs.cycle_close_date and ld.logical_date_type='B') UNION SELECT cycd,cm,sd,ed,ld FROM (SELECT pcs.cycle_code CYCD,DECODE(LTRIM(pcs.cycle_month,'0')+2,13,1,14,2,15,3,LTRIM(pcs.cycle_month,'0')+2) CM ,pcs.cycle_start_date SD,pcs.cycle_close_date ED,ld.logical_date LD FROM pm1_cycle_state pcs,logical_date ld WHERE ld.logical_date BETWEEN pcs.cycle_start_date AND pcs.cycle_close_date and ld.logical_date_type='B') UNION SELECT cycd,cm,sd,ed,ld FROM (SELECT pcs.cycle_code CYCD,DECODE(LTRIM(pcs.cycle_month,'0')+3,13,1,14,2,15,3,LTRIM(pcs.cycle_month,'0')+3) CM ,pcs.cycle_start_date SD,pcs.cycle_close_date ED,ld.logical_date LD FROM pm1_cycle_state pcs,logical_date ld WHERE ld.logical_date BETWEEN pcs.cycle_start_date AND pcs.cycle_close_date and ld.logical_date_type='B') This query is running perfectly fine. This will result in all the cycle_codes with exactly 4 rows for current month and future 3 months. Now the requirement is if any of the month is missing.how could i show it? for eg: the output of the above query is cycd cm 102 1 102 10 102 11 102 12 103 1 103 10 103 11 103 12 104 1 104 10 104 11 104 12 Now lets say the row with cycd=104 and cm=11 is not present in the table,then the above query will not get the row 104 11. I want to display only those rows. how could i do it?

    Read the article

  • Updating FGLRX driver fails & deactivates FGLRX driver

    - by Edwin
    I have an ATI/AMD graphics card in my computer. However, every time I try to install the post-release updates, it always fails and deactivates the graphics driver. I've pasted the last few messages following the ldconfig deferred processing now taking place message from the installation log from /var/log/jockey.log below; if you're interested, I have pasted the full output here. WARNING: /sys/module/fglrx_updates/drivers does not exist, cannot rebind fglrx_updates driver DEBUG: fglrx.enabled(fglrx_updates): target_alt None current_alt /usr/lib/fglrx/ld.so.conf other target alt None other current alt /usr/lib/fglrx/alt_ld.so.conf DEBUG: fglrx_updates is not the alternative in use DEBUG: fglrx.enabled(fglrx_updates): target_alt None current_alt /usr/lib/fglrx/ld.so.conf other target alt None other current alt /usr/lib/fglrx/alt_ld.so.conf DEBUG: fglrx_updates is not the alternative in use DEBUG: fglrx.enabled(fglrx_updates): target_alt None current_alt /usr/lib/fglrx/ld.so.conf other target alt None other current alt /usr/lib/fglrx/alt_ld.so.conf DEBUG: fglrx_updates is not the alternative in use DEBUG: fglrx.enabled(fglrx_updates): target_alt None current_alt /usr/lib/fglrx/ld.so.conf other target alt None other current alt /usr/lib/fglrx/alt_ld.so.conf DEBUG: fglrx_updates is not the alternative in use DEBUG: fglrx.enabled(fglrx): target_alt /usr/lib/fglrx/ld.so.conf current_alt /usr/lib/fglrx/ld.so.conf other target alt /usr/lib/fglrx/alt_ld.so.conf other current alt /usr/lib/fglrx/alt_ld.so.conf DEBUG: XorgDriverHandler(%s, %s).enabled(): No X.org driver set, not checking DEBUG: fglrx.enabled(fglrx_updates): target_alt None current_alt /usr/lib/fglrx/ld.so.conf other target alt None other current alt /usr/lib/fglrx/alt_ld.so.conf DEBUG: fglrx_updates is not the alternative in use DEBUG: fglrx.enabled(fglrx_updates): target_alt None current_alt /usr/lib/fglrx/ld.so.conf other target alt None other current alt /usr/lib/fglrx/alt_ld.so.conf DEBUG: fglrx_updates is not the alternative in use DEBUG: fglrx.enabled(fglrx_updates): target_alt None current_alt /usr/lib/fglrx/ld.so.conf other target alt None other current alt /usr/lib/fglrx/alt_ld.so.conf DEBUG: fglrx_updates is not the alternative in use DEBUG: fglrx.enabled(fglrx_updates): target_alt None current_alt /usr/lib/fglrx/ld.so.conf other target alt None other current alt /usr/lib/fglrx/alt_ld.so.conf DEBUG: fglrx_updates is not the alternative in use DEBUG: fglrx.enabled(fglrx): target_alt /usr/lib/fglrx/ld.so.conf current_alt /usr/lib/fglrx/ld.so.conf other target alt /usr/lib/fglrx/alt_ld.so.conf other current alt /usr/lib/fglrx/alt_ld.so.conf DEBUG: XorgDriverHandler(%s, %s).enabled(): No X.org driver set, not checking DEBUG: fglrx.enabled(fglrx): target_alt /usr/lib/fglrx/ld.so.conf current_alt /usr/lib/fglrx/ld.so.conf other target alt /usr/lib/fglrx/alt_ld.so.conf other current alt /usr/lib/fglrx/alt_ld.so.conf DEBUG: XorgDriverHandler(%s, %s).enabled(): No X.org driver set, not checking DEBUG: fglrx.enabled(fglrx_updates): target_alt None current_alt /usr/lib/fglrx/ld.so.conf other target alt None other current alt /usr/lib/fglrx/alt_ld.so.conf DEBUG: fglrx_updates is not the alternative in use DEBUG: fglrx.enabled(fglrx_updates): target_alt None current_alt /usr/lib/fglrx/ld.so.conf other target alt None other current alt /usr/lib/fglrx/alt_ld.so.conf DEBUG: fglrx_updates is not the alternative in use DEBUG: fglrx.enabled(fglrx): target_alt /usr/lib/fglrx/ld.so.conf current_alt /usr/lib/fglrx/ld.so.conf other target alt /usr/lib/fglrx/alt_ld.so.conf other current alt /usr/lib/fglrx/alt_ld.so.conf DEBUG: XorgDriverHandler(%s, %s).enabled(): No X.org driver set, not checking DEBUG: fglrx.enabled(fglrx_updates): target_alt None current_alt /usr/lib/fglrx/ld.so.conf other target alt None other current alt /usr/lib/fglrx/alt_ld.so.conf DEBUG: fglrx_updates is not the alternative in use DEBUG: fglrx.enabled(fglrx_updates): target_alt None current_alt /usr/lib/fglrx/ld.so.conf other target alt None other current alt /usr/lib/fglrx/alt_ld.so.conf DEBUG: fglrx_updates is not the alternative in use DEBUG: fglrx.enabled(fglrx): target_alt /usr/lib/fglrx/ld.so.conf current_alt /usr/lib/fglrx/ld.so.conf other target alt /usr/lib/fglrx/alt_ld.so.conf other current alt /usr/lib/fglrx/alt_ld.so.conf DEBUG: XorgDriverHandler(%s, %s).enabled(): No X.org driver set, not checking What's going on? Is ldconfig corrupted, or has the driver package just not been properly installed, despite reporting to the "Additional Drivers" panel that it is?

    Read the article

  • collect2: ld returned 1 exit status error in Xcode

    - by user573949
    Hello, Im getting the error Command /Developer/usr/bin/gcc-4.2 failed with exit code 1 and when the full log is opened, the error is more accurately listed as: collect2: ld returned 1 exit status from this simple Cocoa script: #import "Controller.h" @implementation Controller int skillcheck (int level, int modifer, int difficulty) { if (level + modifer >= difficulty) { return 1; } if (level + modifer <= difficulty) { return 0; } } int main () { skillcheck(10, 2, 10); } @end the .h file is this: // // Controller.h // // Created by Duo Oratar on 15/01/2011. // Copyright 2011 __MyCompanyName__. All rights reserved. // #import <Cocoa/Cocoa.h> @interface Controller : NSObject { int skillcheck; int contestcheck; } @end and no line was specified that the error came from, does anyone know what the source of this error is, and more importantly, how to fix it? EDIT: I removed the class so now I have this: // // Controller.m // // Created by Duo Oratar on 15/01/2011. // Copyright 2011 __MyCompanyName__. All rights reserved. // #import "Controller.h" int skillcheck (int level, int modifer, int difficulty) { if (level + modifer >= difficulty) { return 1; } if (level + modifer <= difficulty) { return 0; } } int main () { skillcheck(10, 2, 10); } and for the .h file: // // Controller.h // // Created by Duo Oratar on 15/01/2011. // Copyright 2011 __MyCompanyName__. All rights reserved. // #import <Cocoa/Cocoa.h> and the log says: (thanks to the guy who said how to open it) Ld build/Debug/Calculator.app/Contents/MacOS/Calculator normal x86_64 cd /Users/kids/Desktop/Calculator setenv MACOSX_DEPLOYMENT_TARGET 10.6 /Developer/usr/bin/gcc-4.2 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -L/Users/kids/Desktop/Calculator/build/Debug -F/Users/kids/Desktop/Calculator/build/Debug -filelist /Users/kids/Desktop/Calculator/build/Calculator.build/Debug/Calculator.build/Objects-normal/x86_64/Calculator.LinkFileList -mmacosx-version-min=10.6 -framework Cocoa -o /Users/kids/Desktop/Calculator/build/Debug/Calculator.app/Contents/MacOS/Calculator ld: duplicate symbol _main in /Users/kids/Desktop/Calculator/build/Calculator.build/Debug/Calculator.build/Objects-normal/x86_64/Controller.o and /Users/kids/Desktop/Calculator/build/Calculator.build/Debug/Calculator.build/Objects-normal/x86_64/main.o collect2: ld returned 1 exit status Command /Developer/usr/bin/gcc-4.2 failed with exit code 1 ld: duplicate symbol _main in /Users/kids/Desktop/Calculator/build/Calculator.build/Debug/Calculator.build/Objects-normal/x86_64/Controller.o and /Users/kids/Desktop/Calculator/build/Calculator.build/Debug/Calculator.build/Objects-normal/x86_64/main.o Command /Developer/usr/bin/gcc-4.2 failed with exit code 1

    Read the article

  • Using 32 bit g++ to build 64bit binaries on AIX

    - by Thumbeti
    I am trying to build a 64 bit binary from C++ code using 32bit g++ compiler. I am getting the following errors while building: ============================================================================= => /usr/local/bin/g++ -shared -maix64 -fPIC -Wl,-bM:SRE -Wl,-bnoentry -Wl,-bE:gcc_shr_lib.so.exp -o gcc_shr_lib.so gcc_shr_lib.o -L/usr/local/lib ld: 0711-319 WARNING: Exported symbol not defined: gcc_whereAmI ld: 0711-317 ERROR: Undefined symbol: typeinfo for std::bad_alloc ld: 0711-317 ERROR: Undefined symbol: __gxx_personality_v0 ld: 0711-317 ERROR: Undefined symbol: vtable for std::exception ld: 0711-317 ERROR: Undefined symbol: vtable for std::bad_alloc ld: 0711-317 ERROR: Undefined symbol: .std::ios_base::Init::Init() ld: 0711-317 ERROR: Undefined symbol: .std::ios_base::Init::~Init() ld: 0711-317 ERROR: Undefined symbol: .operator new(unsigned long) ld: 0711-317 ERROR: Undefined symbol: .operator delete(void*) ld: 0711-317 ERROR: Undefined symbol: ._Unwind_Resume ld: 0711-317 ERROR: Undefined symbol: .__cxa_get_exception_ptr ld: 0711-317 ERROR: Undefined symbol: .__cxa_begin_catch ld: 0711-317 ERROR: Undefined symbol: std::cout ld: 0711-317 ERROR: Undefined symbol: .std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*) ld: 0711-317 ERROR: Undefined symbol: std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&) ld: 0711-317 ERROR: Undefined symbol: .std::basic_ostream<char, std::char_traits<char> >::operator<<(std::basic_ostream<char, std::char_traits<char> >& (*)(std::basic_ostream<char, std::char_traits<char> >&)) ld: 0711-317 ERROR: Undefined symbol: .std::bad_alloc::~bad_alloc() ld: 0711-317 ERROR: Undefined symbol: .__cxa_end_catch ld: 0711-317 ERROR: Undefined symbol: .__register_frame_info_table ld: 0711-317 ERROR: Undefined symbol: .__deregister_frame_info ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status ============================================================================= It seems I need 64bit libstdc++ available on my build system. Could you please throw some light to solve this. Q1) Is it ok to build 64 bit binaries using 32 bit g++ compiler on AIX 5.2 Q2) Where should I get 64 bit libstdc++? Will this 64 bit libstdc++ work with 32bit g++ compiler?

    Read the article

  • /usr/bin/ld: cannot find -llibeststring.a

    - by Peeyush
    I am using festival TTS c++ API in my program.I have downloaded all files from http://www.cstr.ed.ac.uk/downloads/festival/2.0.95/ and install festival and speech_tools successfully on my UBUNTU 10.04 now when compile my c++ programme gcc gives error: g++ -L/usr/lib -L/home/peeyush/Desktop/festival/src/lib -L/home/peeyush/Desktop/speech_tools/lib -o"peeyush" ./src/peeyush.o -llibeststring.a -llibestbase.a -llibestools.a -llibFestival.a /usr/bin/ld: cannot find -llibeststring.a collect2: ld returned 1 exit status make: *** [peeyush] Error 1 so please help me to sort out this error. -Thanks Peeyush Chandel(INDIA)

    Read the article

  • autoconf libtool library linker path incorrect (need drive-letter) for MinGW ld.exe in Cygwin

    - by Tam Toucan
    I use autoconf and when the target is mingw I was using the -mno-cygwin flag. This has been removed so I'm trying to using the mingw tool chain. The problem is the linker isn't finding my libraries /bin/sh ../../../libtool --tag=CXX --mode=link mingw32-g++ -g -Wall -pedantic -DNOMINMAX -D_REENTRANT -DWIN32 -I /usr/local/include/w32api -L/usr/local/lib/w32api -o testRandom.exe testRandom.o -L../../../lib/Random -lRandom libtool: link: mingw32-g++ -g -Wall -pedantic -DNOMINMAX -D_REENTRANT -DWIN32 -I /usr/local/include/w32api -o .libs/testRandom.exe testRandom.o -L/usr/local/lib/w32api -L/home/Tam/src/3DS_Games/lib/Random -lRandom D:\cygwin\opt\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot find -lRandom To link this from the command line using the mingw linker the -L path needs the drive letter i.e mingw32-ld testRandom.o -LD:/home/Tam/src/3DS_Games/lib/Random -lRandom works. The -L path is generated from the makefile.am's which have LDADD = -L$(top_builddir)/lib/Random -lRandom However I can't find how to set top_builddir to a relative path or to start it with the drive letter (my autoconf skills are weak). As a tempoary "solution" I have removed the use of libtool. I could hack a $(DRIVE_LETTER) infront of every -L option, but I'd like to find something better.

    Read the article

  • Linux, GNU GCC, ld, version scripts and the ELF binary format -- How does it work??

    - by themoondothshine
    Hey all, I'm trying to learn more about library versioning in Linux and how to put it all to work. Here's the context: -- I have two versions of a dynamic library which expose the same set of interfaces, say libsome1.so and libsome2.so. -- An application is linked against libsome1.so. -- This application uses libdl.so to dynamically load another module, say libmagic.so. -- Now libmagic.so is linked against libsome2.so. Obviously, without using linker scripts to hide symbols in libmagic.so, at run-time all calls to interfaces in libsome2.so are resolved to libsome1.so. This can be confirmed by checking the value returned by libVersion() against the value of the macro LIB_VERSION. -- So I try next to compile and link libmagic.so with a linker script which hides all symbols except 3 which are defined in libmagic.so and are exported by it. This works... Or at least libVersion() and LIB_VERSION values match (and it reports version 2 not 1). -- However, when some data structures are serialized to disk, I noticed some corruption. In the application's directory if I delete libsome1.so and create a soft link in its place to point to libsome2.so, everything works as expected and the same corruption does not happen. I can't help but think that this may be caused due to some conflict in the run-time linker's resolution of symbols. I've tried many things, like trying to link libsome2.so so that all symbols are alised to symbol@@VER_2 (which I am still confused about because the command nm -CD libsome2.so still lists symbols as symbol and not symbol@@VER_2)... Nothing seems to work!!! Help!!!!!! Edit: I should have mentioned it earlier, but the app in question is Firefox, and libsome1.so is libsqlite3.so shipped with it. I don't quite have the option of recompiling them. Also, using version scripts to hide symbols seems to be the only solution right now. So what really happens when symbols are hidden? Do they become 'local' to the SO? Does rtld have no knowledge of their existence? What happens when an exported function refers to a hidden symbol?

    Read the article

  • Compile a binary file for linking OSX

    - by Satpal
    I'm trying to compile a binary file into a MACH_O object file so that it can be linked it into a dylib. The dylib is written in c/c++. On linux the following command is used: ld -r -b binary -o foo.o foo.bin I have tried various option on OSX but to no avail: ld -r foo.bin -o foo.o gives: ld: warning: -arch not specified ld: warning: ignoring file foo.bin, file was built for unsupported file format which is not the architecture being linked (x86_64) An empty .o file is created ld -arch x86_64 -r foo.bin -o foo.o ld: warning: ignoring file foo.bin, file was built for unsupported file format which is not the architecture being linked (x86_64) Again and empty .o file is created. Checking the files with nm gives: nm foo.o nm: no name list The binary file is actually, firmware that will be downloaded to an external device. Thanks for looking

    Read the article

  • How to build glibc 2.11.2 on RHEL5?

    - by netvope
    Using gcc-4.4.4 or 4.5.0, I'm unable to make glibc-2.11.2 on RHEL 5.5: .././scripts/mkinstalldirs /dev/shm/glibc-2.11.2-build/sunrpc/rpcsvc CPP='gcc -B/home/klaw/share/rhel5/ -E -x c-header' /dev/shm/glibc-2.11.2-build/elf/ld-linux-x86-64.so.2 --library-path /dev/shm/glibc-2.11.2-build:/dev/shm/glibc-2.11.2-build/math:/dev/shm/glibc-2.11.2-build/elf:/dev/shm/glibc-2.11.2-build/dlfcn:/dev/shm/glibc-2.11.2-build/nss:/dev/shm/glibc-2.11.2-build/nis:/dev/shm/glibc-2.11.2-build/rt:/dev/shm/glibc-2.11.2-build/resolv:/dev/shm/glibc-2.11.2-build/crypt:/dev/shm/glibc-2.11.2-build/nptl /dev/shm/glibc-2.11.2-build/sunrpc/rpcgen -Y ../scripts -c rpcsvc/bootparam_prot.x -o /dev/shm/glibc-2.11.2-build/sunrpc/xbootparam_prot.T Inconsistency detected by ld.so: dynamic-link.h: 209: elf_get_dynamic_info: Assertion `info[15] == ((void *)0)' failed! make[2]: *** [/dev/shm/glibc-2.11.2-build/sunrpc/xnlm_prot.stmp] Error 127 make[2]: Leaving directory `/dev/shm/glibc-2.11.2/sunrpc' make[1]: *** [sunrpc/others] Error 2 make[1]: Leaving directory `/dev/shm/glibc-2.11.2' make: *** [all] Error 2 The error comes from the ld.so made by glibc: $ elf/ld.so Inconsistency detected by ld.so: dynamic-link.h: 209: elf_get_dynamic_info: Assertion `info[15] == ((void *)0)' failed! $ I got similar error with glibc-2.11.1 (only the line number of dynamic-link.h is different). Any ideas how I can fix this? gcc-4.4.4 and 4.5.0 were compiled with: binutils-2.20.1 gmp-5.0.1 mpc-0.8.2 mpfr-2.4.2

    Read the article

  • link to a different libc file

    - by bobby
    I want to supply the shared libs along with my program rather than using the system's: ldd says my program uses these shared libs: linux-gate.so.1 = (0xf7ef0000)(made by kernel) libc.so.6 = /lib32/libc.so.6 (0xf7d88000)(libc-2.7.so) /lib/ld-linux.so.2 (0xf7ef1000)(ld-2.7.so) I have successfully linked ld-xxx.so by compiling like this: gcc -std=c99 -D_POSIX_C_SOURCE=200112L -O2 -m32 -s -Wl,-dynamic-linker,ld-2.7.so myprogram.c But I have not managed to successfuly link libc-xxx.so. How can I do that ?

    Read the article

  • Removing/modifying LDAP objectclasses/attributes using olc

    - by Foezjie
    I'm having trouble using openldap's olc to modify a schema without shutting down the server. To test some things out, I made the following schema: objectIdentifier tests orgUlyssisOID:4 objectIdentifier testAttribute tests:1 objectIdentifier testObjectClass tests:2 attributeType ( testAttribute:1 NAME 'attr1' DESC 'attribuut 1' SYNTAX '1.3.6.1.4.1.1466.115.121.1.40' ) attributeType ( testAttribute:2 NAME 'attr2' DESC 'attribuut 2' SUP userPassword SINGLE-VALUE ) objectclass ( testObjectClass:1 NAME 'class1' DESC 'objectclass 1' SUP top STRUCTURAL MUST (attr1 $ attr2 ) ) And added it to a new schema called test. (cn={9}test.ldif in cn=schema). Now I can't seem to figure out how to delete class1 from that schema. I use the following LDIF (and tried lots of variations too, to no avail) dn : cn={9}test,cn=schema,cn=config changetype: modify delete: olcObjectClasses olcObjectClasses: ( testObjectClass:1 NAME 'class1' DESC 'objectclass 1' SUP top STRUCTURAL MUST ( attr1 $ attr2 ) ) Running ldapmodify -x -W -D cn=admin,cn=config -f test.ldif -d 0 gives no output. -d 1 gives this: ldap_create ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:389 ldap_new_socket: 4 ldap_prepare_socket: 4 ldap_connect_to_host: Trying 127.0.0.1:389 ldap_pvt_connect: fd: 4 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 38 bytes to sd 4 ldap_result ld 0x7f2a8ccf3430 msgid 1 wait4msg ld 0x7f2a8ccf3430 msgid 1 (infinite timeout) wait4msg continue ld 0x7f2a8ccf3430 msgid 1 all 1 ** ld 0x7f2a8ccf3430 Connections: * host: localhost port: 389 (default) refcnt: 2 status: Connected last used: Mon Sep 10 11:29:57 2012 ** ld 0x7f2a8ccf3430 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x7f2a8ccf3430 request count 1 (abandoned 0) ** ld 0x7f2a8ccf3430 Response Queue: Empty ld 0x7f2a8ccf3430 response count 0 ldap_chkResponseList ld 0x7f2a8ccf3430 msgid 1 all 1 ldap_chkResponseList returns ld 0x7f2a8ccf3430 NULL ldap_int_select read1msg: ld 0x7f2a8ccf3430 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x7f2a8ccf3430 msgid 1 message type bind ber_scanf fmt ({eAA) ber: read1msg: ld 0x7f2a8ccf3430 0 new referrals read1msg: mark request completed, ld 0x7f2a8ccf3430 msgid 1 request done: ld 0x7f2a8ccf3430 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 4 ldap_free_connection: actually freed So no real indication of an error. Where am I doing it wrong? Bonus question: If I have some entries of a certain objectclass, can I modify it (add/remove attributeTypes) without removing the entries? Thanks in advance for all help.

    Read the article

  • ld: symbol(s) not found with OpenSSL (libssl)

    - by Benjamin
    Hi all, I'm trying to build TorTunnel on my mac. I've successfully installed the Boost library and its development files. TorTunnel also requires the OpenSSL and its development files. I've got them installed in /usr/lib/libssl.dylib and /usr/include/openssl/. When I run the make command this is the error i'm getting: g++ -ggdb -g -O2 -lssl -lboost_system-xgcc42-mt-1_38 -o torproxy TorProxy.o HybridEncryption.o Connection.o Cell.o Directory.o ServerListing.o Util.o Circuit.o CellEncrypter.o RelayCellDispatcher.o CellConsumer.o ProxyShuffler.o CreateCell.o CreatedCell.o TorTunnel.o SocksConnection.o Network.o Undefined symbols: "_BN_hex2bn", referenced from: Circuit::initializeDhParameters() in Circuit.o "_BN_free", referenced from: Circuit::~Circuit()in Circuit.o Circuit::~Circuit()in Circuit.o CreatedCell::getKeyMaterial(unsigned char**, unsigned char**)in CreatedCell.o "_DH_generate_key", referenced from: Circuit::initializeDhParameters() in Circuit.o "_PEM_read_bio_RSAPublicKey", referenced from: ServerListing::getOnionKey() in ServerListing.o "_BIO_s_mem", referenced from: Connection::initializeSSL() in Connection.o Connection::initializeSSL() in Connection.o "_DH_free", referenced from: Circuit::~Circuit()in Circuit.o "_BIO_ctrl_pending", referenced from: Connection::writeFromBuffer(boost::function)in Connection.o "_RSA_size", referenced from: HybridEncryption::encryptInSingleChunk(unsigned char*, int, unsigned char**, int*, rsa_st*)in HybridEncryption.o HybridEncryption::encryptInHybridChunk(unsigned char*, int, unsigned char**, int*, rsa_st*)in HybridEncryption.o HybridEncryption::encrypt(unsigned char*, int, unsigned char**, int*, rsa_st*)in HybridEncryption.o "_RSA_public_encrypt", referenced from: HybridEncryption::encryptInSingleChunk(unsigned char*, int, unsigned char**, int*, rsa_st*)in HybridEncryption.o HybridEncryption::encryptInHybridChunk(unsigned char*, int, unsigned char**, int*, rsa_st*)in HybridEncryption.o "_BN_num_bits", referenced from: CreateCell::CreateCell(unsigned short, dh_st*, rsa_st*)in CreateCell.o CreatedCell::getKeyMaterial(unsigned char**, unsigned char**)in CreatedCell.o CreatedCell::getKeyMaterial(unsigned char**, unsigned char**)in CreatedCell.o CreatedCell::isValid() in CreatedCell.o "_SHA1", referenced from: CellEncrypter::expandKeyMaterial(unsigned char*, int, unsigned char*, int)in CellEncrypter.o "_BN_bn2bin", referenced from: CreateCell::CreateCell(unsigned short, dh_st*, rsa_st*)in CreateCell.o "_BN_bin2bn", referenced from: CreatedCell::getKeyMaterial(unsigned char**, unsigned char**)in CreatedCell.o "_DH_compute_key", referenced from: CreatedCell::getKeyMaterial(unsigned char**, unsigned char**)in CreatedCell.o "_BIO_new", referenced from: Connection::initializeSSL() in Connection.o Connection::initializeSSL() in Connection.o "_BIO_new_mem_buf", referenced from: ServerListing::getOnionKey() in ServerListing.o "_AES_ctr128_encrypt", referenced from: HybridEncryption::AES_encrypt(unsigned char*, int, unsigned char*, unsigned char*, int)in HybridEncryption.o CellEncrypter::aesOperate(Cell&, aes_key_st*, unsigned char*, unsigned char*, unsigned int*)in CellEncrypter.o "_BIO_read", referenced from: Connection::writeFromBuffer(boost::function)in Connection.o "_SHA1_Update", referenced from: CellEncrypter::calculateDigest(SHAstate_st*, RelayCell&, unsigned char*)in CellEncrypter.o CellEncrypter::initKeyMaterial(unsigned char*)in CellEncrypter.o CellEncrypter::initKeyMaterial(unsigned char*)in CellEncrypter.o "_SHA1_Final", referenced from: CellEncrypter::calculateDigest(SHAstate_st*, RelayCell&, unsigned char*)in CellEncrypter.o "_DH_size", referenced from: CreatedCell::getKeyMaterial(unsigned char**, unsigned char**)in CreatedCell.o "_DH_new", referenced from: Circuit::initializeDhParameters() in Circuit.o "_BIO_write", referenced from: Connection::readIntoBufferComplete(boost::function, boost::system::error_code const&, unsigned long)in Connection.o "_RSA_free", referenced from: Circuit::~Circuit()in Circuit.o "_BN_dup", referenced from: Circuit::initializeDhParameters() in Circuit.o Circuit::initializeDhParameters() in Circuit.o "_BN_new", referenced from: Circuit::initializeDhParameters() in Circuit.o Circuit::initializeDhParameters() in Circuit.o "_SHA1_Init", referenced from: CellEncrypter::CellEncrypter()in CellEncrypter.o CellEncrypter::CellEncrypter()in CellEncrypter.o "_RAND_bytes", referenced from: HybridEncryption::encryptInHybridChunk(unsigned char*, int, unsigned char**, int*, rsa_st*)in HybridEncryption.o Util::getRandomId() in Util.o "_AES_set_encrypt_key", referenced from: HybridEncryption::AES_encrypt(unsigned char*, int, unsigned char*, unsigned char*, int)in HybridEncryption.o CellEncrypter::initKeyMaterial(unsigned char*)in CellEncrypter.o CellEncrypter::initKeyMaterial(unsigned char*)in CellEncrypter.o "_BN_set_word", referenced from: Circuit::initializeDhParameters() in Circuit.o "_RSA_new", referenced from: ServerListing::getOnionKey() in ServerListing.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [torproxy] Error 1 Any idea how I could fix it?

    Read the article

1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >