I tried to install the nix package manager on an Android device with termux.
When I try to execute the nix applicatives (for instance nix-store or nix-env) I get the following error
/nix/store/y9mfv3sx75mbfibf1zna1kq9v98fk2nb-nix-1.11.16/bin/nix-env:
error while loading shared libraries:
/nix/store/kfk65xrfzndyyz6if5fxk4wrwz76h2lh-glibc-2.25-49/lib/libc.so:
invalid ELF header
The file seems to be a script for the GNU linker, so I'm wondering what is the problem, could it be that termux's version of ld is unable to correctly interpret GNU Linker's scripts?
Thanks in advance for any help.
Edit: It seems that if unset the LD_PRELOADED and the LD_LIBRARY_PATH variables the nix-applications work fine. Problem is that in doing so termux cannot lunch any other non nix application, such as bash for instance.
Related
I'm trying to build a simple web app using Yew, Diesel, and Postgres. When I run
wasm-pack build --target web --out-name wasm --out-dir ./static
I get the following error:
*rust-lld: error: unable to find library -lpq*
I'm on macOS Catalina. I installed Postgres through Homebrew. My libpq.dylib file is at /usr/local/lib.
These are the troubleshooting I've tried already:
Added /usr/local/lib to $PATH. My pg_config shows LIBDIR = /usr/local/lib.
Re-installed Postgres
Updated rustc -nightly
Ideas here are not helpful as well: How can I link a Rust Wasm application with libpq via wasm-pack?
Still it is not resolved. I'd be grateful for any suggestions.
Libpq does not support the wasm-web platform as far as I'm aware therefore there is no way to make this work. As already mentioned in the comments you probably want to use diesel in your backend code, not in the frontend.
I am using Windows 10 and Strawberry Perl. I found this nice tutorial on building a 3D engine in Perl. Which requires SDL. For a couple of days I've been trying to install it, but it doesn't work. First I tried via CPAN, no success. No I am trying manually, but I am getting error messages when using "make". If I type "perl -V:make" it says I should use "dmake". If I do so, there's a dmake warning, telling me to use gmake instead. If I do that, there's the following message:
"to undefined at C:/Perl64/site/lib/ExtUtils/Install.pm line 1199. gmake: *** [Makefile:942: pm_to_blib] Error 2"
Any suggestions how to fix this? Or is there an easy (easier) way to install SDL?
It seems like the Perl SDL module uses SDL version 1.2.14, whereas the documentation says
The best course of action is to move to SDL 2.0 or later as quickly as
possible
So, I would recommend looking at the Python bindings PySDL2 instead. The following worked for me on Windows 10:
Downloaded Python 3.8 from here:
https://www.python.org/ftp/python/3.8.2/python-3.8.2-amd64.exe
Then added the following to the User enviroment variables for "Path" (NOTE: at the beginning, not at the end):
%USERPROFILE%\AppData\Local\Programs\Python\Python38
%USERPROFILE%\AppData\Local\Programs\Python\Python38\Scripts
Then, from the command prompt install pysdl2:
>pip install pysdl2
Collecting pysdl2
Downloading https://files.pythonhosted.org/packages/60/ba/ddb48261848874eeb3d54963edbf3c74fff86499746aeb23151f123953bb/PySDL2-0.9.7-py3-none-any.whl (541kB)
|████████████████████████████████| 542kB 2.2MB/s
Installing collected packages: pysdl2
Successfully installed pysdl2-0.9.7
>pip install pysdl2-dll
Collecting pysdl2-dll
Downloading https://files.pythonhosted.org/packages/01/37/f9aa5472fb85ce94507c69110916133ad29b650d2bf277de2cce37d7ad7d/pysdl2_dll-2.0.12-py2.py3-none-win_amd64.whl (2.5MB)
|████████████████████████████████| 2.5MB 3.2MB/s
Installing collected packages: pysdl2-dll
Successfully installed pysdl2-dll-2.0.12
Then, add a new User environment variable PYTHONPATH with value:
%USERPROFILE%\AppData\Local\Programs\Python\Python38\Lib\site-packages
Close the command prompt, and reopen a new one to update the environment variables. Then I created a test Python script:
import sys
import sdl2.ext
resource_dir=r'C:\Users\hakon\AppData\Local\Programs\Python\Python38\Lib\site-packages\sdl2\examples'
RESOURCES = sdl2.ext.Resources(resource_dir, "resources")
sdl2.ext.init()
window = sdl2.ext.Window("Hello World!", size=(640, 480))
window.show()
factory = sdl2.ext.SpriteFactory(sdl2.ext.SOFTWARE)
sprite = factory.from_image(RESOURCES.get_path("hello.bmp"))
spriterenderer = factory.create_sprite_render_system(window)
spriterenderer.render(sprite)
processor = sdl2.ext.TestEventProcessor()
processor.run(window)
sdl2.ext.quit()
and finally run it from the command prompt:
> python test.py
I am building Swift compiler from source on CentOS 6, and am running into a library issue. After fighting with the build script for a while I have got where running ./utils/build-script eventually gives:
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake --build /home/src/swift/build/Ninja-DebugAssert/cmark-linux-x86_64 -- all
ninja: no work to do.
llvm: using standard linker
+ cd /home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake -G Ninja -DCMAKE_C_COMPILER:PATH=clang -DCMAKE_CXX_COMPILER:PATH=clang++ '-DCMAKE_C_FLAGS= ' '-DCMAKE_CXX_FLAGS= ' -DCMAKE_BUILD_TYPE:STRING=Debug -DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE -DLLVM_TOOL_SWIFT_BUILD:BOOL=NO '-DLLVM_TARGETS_TO_BUILD=X86;ARM;AArch64' -DLLVM_INCLUDE_TESTS:BOOL=TRUE -LLVM_INCLUDE_DOCS:BOOL=TRUE -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINTERNAL_INSTALL_PREFIX=local /home/src/swift/llvm
CMake Error at cmake/modules/CheckAtomic.cmake:36 (message):
Host compiler appears to require libatomic, but cannot find it.
Call Stack (most recent call first):
cmake/config-ix.cmake:296 (include)
CMakeLists.txt:403 (include)
-- Configuring incomplete, errors occurred!
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeOutput.log".
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeError.log".
./utils/build-script: command terminated with a non-zero exit status 1, aborting
(gcc-4.8.2 was what I compiled llvm with)
libatomic is there:
$ locate libatomic
/opt/gcc-4.8.2/lib64/libatomic.a
/opt/gcc-4.8.2/lib64/libatomic.la
/opt/gcc-4.8.2/lib64/libatomic.so
/opt/gcc-4.8.2/lib64/libatomic.so.1
/opt/gcc-4.8.2/lib64/libatomic.so.1.0.0
I just don't know how to tell the build system where to look. I have tried the usual CMAKE_LIBRARY_PATH (exporting on the command line - I am not sure if cmake works like the way LD_LIBRARY_PATH, LIBRARY_PATH work) but it can't seem to find it.
I also don't have root on the machine.
I had not tried building from source on CentOS 6 until I saw this question, but I have been able to build Swift 2.2 on CentOS 7.1 and Ubuntu 14.04, with partial success. A few things to think about:
You will need numerous dependencies required to build Swift, and unless
they happen to be already on the system, you will need root access to
install them.
Use -R flag with the build-script to create a release build.
Building in DebugAssert (the default) will require a lot of memory. In my case even 14 GB was not sufficient. A release build
can be done with about 6 GB.
As for your specific problem, it is related to Clang's dependency on GCC-related packages for headers and libraries. See, for example, Fedora 21 with clang, without gcc.
Even if you installed GCC 4.8.2 and adjusted the path to use gcc and g++ from 4.8.2, Clang may still be looking in the old GCC directories for headers and libraries. CMake first tries to compile a C++ test file that includes the header atomic, which does not exist in the old GCC. So, it then tries to link a C test program that uses the library libatomic, which again doesn't exist in the old GCC. You can see this by looking at llvm/cmake/modules/CheckAtomic.cmake mentioned by usr1234567. CMakeError.log and CMakeOutput.log can also provide valuable insight. BTW, when I was building Swift on CentOS 7.1, I didn't run into this problem because GCC 4.8.2 was used by Clang for headers and libraries and the atomic header was found, so the C++ file got compiled. However, had the libatomic check been done, it would have failed, because libatomic.so in the repository-provided 4.8.2 has INPUT ( <name of some non-existent file> ), so trying to link with libatomic errors out.
I'm sure there are various ways of dealing with this issue, but what solved the problem for me was setting the following environment variables, please adjust to your specific setup:
export CPLUS_INCLUDE_PATH=/opt/gcc-4.8.2/include/c++/4.8.2:/opt/gcc-4.8.2/include/c++/4.8.2/x86_64-unknown-linux-gnu
export LIBRARY_PATH=/opt/gcc-4.8.2/lib64:/opt/gcc-4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
Also make sure that your 4.8.2 version of libstdc++.so is available to the dynamic linker at runtime. Since you don't have root, do
export LD_LIBRARY_PATH=/opt/gcc-4.8.2/lib64
If you had root, you could use ldconfig.
Before you start building Swift, you may want to try building, using Clang, a simple C program linking it with libatomic (the code doesn't actually have to use any symbols from the lib) and a simple C++ program that includes the <atomic> header. When compiling the C++ program, use the -std=c++11 compiler flag. If the C++ program compiles successfully, then it is not necessary for the libatomic linking test to be successful.
Interestingly, the CMakeOutput.log file still did not report finding GCC 4.8.2 as a candidate GCC installation, but the configuration/build worked well past the error.
Hopefully this helps. Please let us know if you run into something else.
CheckAtomic.cmake seems to be part of LLVM. I found a file at Github and it tries to find '__atomic_fetch_add_4' from libatomic
check_library_exists(atomic __atomic_fetch_add_4 "" HAVE_LIBATOMIC)
This fails for you. Check CMakeFiles/CMakeError.log to get more details why this test failed. Or try this line in a new project.
My problem is that when I try to start debuggin in DDT in Eclipse (Kepler) an error shows up:
Error in final launch sequence
Failed to execute MI command:
-gdb-set auto-solib-add on
Error message from debugger back end:
No symbol table is loaded.
Use the "file" command.
No symbol table is loaded.
Use the "file" command.
I've compiled the application with -gc and -g flag but it didn't help.
I'm using original DMD compiler.
Sounds like you are working on Windows, DMD has no GDB support there yet. You can either use windbg from the command line or use the Visual Studio plugin, which converts the debug info after compiling.
The issue that I had is that the compiler (DMD) is not working with GDB under Windows. If somebody wants to use DDT with debugging support, he needs to use GDC compiler.
This actually is mentioned in the "Debugging" page:
http://wiki.dlang.org/Debugging
I am using eclipse to execute a cuda program. I have downloaded a CUDA PLUGIN for
eclipse. When I execute sample cuda program given by plugin its fine but when I try
to execute any other program I am getting error undefined reference to main...
make
Building target: Add_cuda
Invoking: NVCC Linker
nvcc -L/export/trainee3/dinesh/cuda5.0/lib64 -o "Add_cuda" ./mycuda.o -lcudart
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status
I found in stackoverflow that some times we get this problem because of system startup file
I used flag -nostartfiles but it is not working in my case..
I have included lib64 and include path in c++ build.
So any suggestion to over come this problem....
We've been over this already.
Use nsight eclipse edition instead.
If you have cuda 5.0 or 5.5 installed, just type nsight in a terminal session.
If you really want to use that Eclipse CUDA plugin (which is no longer supported, I don't believe), then start with the C++ sample project, which you agree now and back then would work. Then modify the source code in that project. Don't create your own project.
Install CUDA 5. It comes with Nsight Eclipse version. Very Elegant to use. NV Visual profiler is integrated with Nsight. Syntax highlighting and debug mode are very easy to use.