Trying to install swift on my Ubuntu 14.04.3 server. Followed the guide on Swift.org.
download the install package
fetched the gpg keys
verified the .sig file
extracted the file and added the usr/bin subdir to my PATH
However when I try running swift I get "No such file or directory"
Swift seems to be found:
icanzilb#underplot:~/public$ which swift
/home/icanzilb/swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a-ubuntu14.04/usr/bin/swift
Path is correct:
icanzilb#underplot:~/swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a-ubuntu14.04/usr/bin$ echo $PATH
/home/icanzilb/swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a-ubuntu14.04/usr/bin:...
But can't run it:
icanzilb#underplot:~/swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a-ubuntu14.04/usr/bin$ swift
-bash: /home/icanzilb/swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a-ubuntu14.04/usr/bin/swift: No such file or directory
=====
Update 1: I tried the development and stable builds of Swift from swift.org and the .sig checks out but still getting the same error.
Both the swift executable and my Ubuntu are 64 bit.
It really looks like this is a problem of an architecture mismatch, as indicated by one of the commenters, or a corrupted download. The swift executable is in the path and is picked up by which. Judging from the name of the directory where it is located, it is indeed for Ubuntu 14.04. I would try the following:
file `which swift`
This should tell you it is an ELF 64-bit executable, dynamically linked, etc. If that is not the case, you have a corrupted binary somehow.
Then do
uname -a
which should identify your system as Ubuntu 14, x86_64 among other things. If that is the case, you probably have a corrupted binary. Unpack the downloaded package again and retry. If your system is not x86_64, then you are on a wrong architecture.
Update 2/4/2016:
Based on the additional info you provided about the binary and the architecture, I tend to believe this is a platform mismatch. The output of uname doesn't show it is an Ubuntu box. Besides, the Linux kernel is 4.4.0, and the binary is for 2.6.24. I can successfully run the same binary on an Ubuntu 14.04 installation with a 3.19.0 kernel. The kernel version difference is not necessarily a problem in itself, but an indicator that the platform may not be a standard Ubuntu 14.04 install.
As another check, could you please do cat /etc/os-release and cat /etc/lsb-release? Those files should indicate if the platform is indeed Ubuntu. If it is, then I'm wondering how you ended up with this late kernel version. It is possible some other components of the OS are also too recent and incompatible with the Swift binary. This may be some strange custom Linode image... If you have a machine you can use, virtual or physical, try downloading and installing a standard Ubuntu 14.04.
Related
I've created a basic image with buildroot (buildroot-2021.02.1), containing some software and also selected the RPI firmware in order to use the camera and some Raspberry Pi tools: Target packages --> Hardware handling --> Firmware --> ([x] rpi-firmware) --> Firmware to boot as mentioned here.
But the tools raspistill, vcgencmd, ... are not included. The question is how to include them and why are they not included?
At some point in time it must have been working, see: RaspberryPi camera with buildroot
More details:
In the logs of buildroot the following lines show up:
>>> rpi-firmware d016a6eb01c8c7326a89cb42809fed2a21525de5 Installing to target
comm: /home/ich/br/buildroot/output/build/rpi-firmware-d016a6eb01c8c7326a89cb42809fed2a21525de5/.files-list.before: No such file or directory
comm: /home/ich/br/buildroot/output/build/rpi-firmware-d016a6eb01c8c7326a89cb42809fed2a21525de5/.files-list-staging.before: No such file or directory
comm: /home/ich/br/buildroot/output/build/rpi-firmware-d016a6eb01c8c7326a89cb42809fed2a21525de5/.files-list-host.before: No such file or directory
and inside this package the binaries are existing. They are downloaded from http://sources.buildroot.net/rpi-firmware/ where the tars contain the actual tools. But they are not copied into the final image by buildroot but only downloaded. Maybe because some files-list.txt file(s) are missing, as pointed out by the error message. Maybe those files are whitelisting the files to copy. But I could not find documentation about this.
For 64-bit builds the binaries in the (then manually downloaded) tar file could not be executed, because they are 32-bit executables: firmware-d016a6eb01c8c7326a89cb42809fed2a21525de5/opt/vc/bin/vcgencmd: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 3.1.9, not stripped; on a 32-bit build with buildroot it also does not work, because the shared libraries are missing, even though the full structure from the archive has been placed under /opt/vc/{bin|lib|...} like on a standard RPI image.
I'm unsure how to proceed with the problem, diagnose it and fix it.
EDIT: maybe this are two different problems; I read the linked SO question once again and compared the files fixup.dat and start.elf (which contain the RPI hardware stuff to make the tools work) in the boot.vfat of the built image with the images in buildroot/output/build/rpi-firmware-d016a6eb01c8c7326a89cb42809fed2a21525de5/boot and the files fixup_x.dat and start_x.elf are taken from there. So is in accordance to the mentioned SO question. And at no place it is indicated that the tools for the Raspberry Pi are compiled. They are only inside this tar archive. Maybe one needs to compile them extra and this package is not designed to integrate those tools.
I figured out the solution and this might be useful for future reference, so I put the solution here.
One have to differentiate between:
the "firmware" (that is the mentioned tar from the question), which is turned on with BR2_PACKAGE_RPI_FIRMWARE=y in buildroot. This causes then that the start.elf and fixup.dat contain the correct data from this tar. The fact that the tars also contain the desired binaries is only "coincidence"
the desired applications are packaged as "userland" (see here) and if one finds the # BR2_PACKAGE_RPI_USERLAND is not set line in .config in the buildroot project's root directory and replaces this line by BR2_PACKAGE_RPI_USERLAND=y the applications (vcgencmd, raspistill, ...) are being built and included into the final image (I could not find the location in make menuconfig however, but this is no problem, if you directly modify the vars)
Therefore, the question is answered. But: you might run into some issues ;-) :
Question 1: I get a "Segmentation fault" when running raspistill
For raspistill -o i.jpg you might get out:
mmal: mmal_vc_shm_init: could not initialize vc shared memory service
mmal: mmal_vc_component_create: failed to initialise shm for 'vc.camera_info' (7:EIO)
mmal: mmal_component_create_core: could not create component 'vc.camera_info' (7)
mmal: Failed to create camera_info component
Segmentation fault
(with an empty image file), see here for details.
Answer: this is related to /dev/vcsm (or /dev/vcsm-csa) missing which is used for camera control / video decoding "stuff". Symlinking to /dev/vc-mem as stated somewhere around the net does not help.
Solution: I was using the latest BR with Kernel 5.10.x (buildroot-2021.02.1 and simply "dowgraded" to buildroot-2020.02.1, rebuilt it and /dev/vcsm appears and everything works fine.
Question 2: I want to do it in docker containers
Answer: No problem. I used balenalib/rpi-raspbian:latest (as suggested here) and it worked flawlessly by running docker run --privileged --device=/dev/vchiq --rm -it balenalib/rpi-raspbian:latest. For this only the proper devices and the support is needed. So the package BR2_PACKAGE_RPI_USERLAND=y could be completely omitted.
Question 3: Does it work with 64-bit?
Answer: No. I tried out the recent version (raspberrypi3_64_defconfig) of buildroot and the version from Feb 2020 as mentioned and for both /dev/vcsm (or /dev/vcsm-csa) is missing. Linux cpi64 4.19.97-v8 #1 SMP PREEMPT Sat Apr 17 14:13:11 CEST 2021 aarch64 GNU/Linux
I'm trying to use VSCode Remote extension to connect to a remote host that runs on RHEL/CentOS 6, but it fails to connect since CentOS 6 ships with GLIBC 2.12 and GLIBCXX 3.4.1. As mentioned in this post, in order to get the extension to work, the workaround is to install GLIBC>=2.17 and GLIBCXX>=3.4.18.
Unfortunately, I don't have sudo access for the server, so I won't be able to update these libraries using the bash script provided in the link. Also, in this SO post, the author says not to update the system GLIBC since it can break down system applications. That being said, I've tried something different -- I extracted those rpm packages, as described in this blog, inside my home folder. I've then updated the env variables PATH and LD_LIBRARY_PATH in ~/.bash_profile to point to these new locations. But the node binary (in VS Code Remote) still can't find these libraries.
Is there a way to let the node binary know where to look for these libraries? More precisely, can someone explain how I can make this extension work without sudo access?
I've got it to work by installing gcc and glibc using Linuxbrew. See this post for more details: https://github.com/microsoft/vscode-remote-release/issues/103#issuecomment-546551293.
Couple of things to take note of:
Node binary versions in VS Code Server may vary between commits. In the GitHub comment above, the author uses node#10 -- you may replace it with node#12; everything would still work.
Make sure glibc and gcc are properly installed using linuxbrew. This step is key.
I have download that code from github.
Whenever that code tries to check mexopencv (a file inside lib folder). It shows an error on Matlab 2017a that is:
[error 3] please make sure gcc >= 4.4 g++ >= 4.4 is installed ...
I am having a gcc version of 8.8.0
Following is the description of system
Window 10
Visual Studio 2012
Matlab 2017a
opencv 2.4.10
mexopencv (install from your folder LIB)
You might lack of standard libraries (.dll in Windows but .lib in Linux). The code was developed under Linux (help is also only provided for Linux systems) and once tested under Windows 7.
The method was tested under OS linux lubuntu 14.04, CPU intel i5 and
16GB of RAM. This guide was written under a linux-based distribution
scope, more precisely debian. Unfortunately we lack experience to
address bugs or any problem that could emerge in non-linux OS, we will
provide only linux OS help regarding execution problems, we apologise.
we tested this code on Windows7. We successfully installed opencv
2.4.10 following this tutorial: [http://www.learnopencv.com/install-opencv3-on-windows/]
This suggests that the mex-function is also linux-based. The error should vanish if you compile the source code yourself on your system, e.g. with MinGW (also GCC), see here.
EDITED:
the README.markdown file (under LIB/mexopencv-master.zip) provides a little guide through the installation process of both, openCV and the mexopencv function for unix (including ubuntu 14.04) and Windows systems. The latter states:
Browse to mexopencv root folder, and type the following in the MATLAB
command window:
>> mexopencv.make
By default, mexopencv assumes the OpenCV library is installed in
C:\opencv. If this is not the case, specify the path as an argument:
>> mexopencv.make('opencv_path', 'c:\your\path\to\opencv')
Note that if you build OpenCV from source, this path specification
might not work out of the box. You need to replace dll files in the
OpenCV package with newly built binaries. Or, you need to modify
+mexopencv/make.m to correctly link your MEX-files with the library.
To remove existing mexopencv binaries, use the following command.
>> mexopencv.make('clean', true)
It requires a standard C++ compiler supported by Matlab (see here), any Visual Studio installation should be OK, as an open-source option MinGW is recommended. Just remember to pick the right system (usually 64-bit).
I have met a problem with hdf5 libraries on eclipse CDT. When running a test C++ program, I got prompt information as below:
/home/lsl/Documents/CODE/eclipse-workspace/ReadWriteHDF5/Debug/ReadWriteHDF5:
error while loading shared libraries: libhdf5.so.103: cannot open
shared object file: No such file or directory.
libhdf5.so is confirmed to exist in /usr/local/lib/hdf5-1.10.4/lib and /usr/local/lib/hdf5-1.10.4/lib is within LD_LIBRARY_PATH. Do you have any indications?
Thanks very much!
It looks like Linux is your main operating system. See what happens when you type
sudo apt install libhdf5-dev
since it might supplant the package you're looking for. It worked for me.
I come across similar issue while compiling C++ code that uses Armadillo. Since I have anaconda installed, I find the libhdf5.so.103 file located at ~/anaconda3/lib. After I add the path to LD_LIBRARY_PATH, the error disappears.
I came across exactly the same problem today (perhaps the only difference is that it complaint libhdf5.so.200 was missing). What I eventually found out is that the system (Ubuntu 20.04) already shipped with libhdf5-dev at version 1.10.4, and this conflicted somehow with my installed version 1.12.2. My build command line is as below:
clang++ <...> -L/my/custom/path/to/hdf5-1.12.2/hdf5/lib <...>
Since the system hdf5 is in standard location, the linker finds simultaneously two versions, causing problem.
My solution is:
sudo apt purge libhdf5-dev
Hope it helps.
I have installed moses successfully, I have also install xmlrpc-c via
sudo apt-get install libxmlrpc-core-c3 then I have built the moses via
./bjam --with-xmlrpc-c=[/path/to/xmlrpc-c-config]. While doing these I have followed the instructions in http://www.statmt.org/moses/?n=Development.GetStarted. Up to that point, I guess everything was correct. From now, I need to connect to the machine where moses is installed, however I could not start the mosesserver. What should I do with the file in mosesdecoder/contrib/server/mosesserver.cpp. I think after the build an executable should be created in there , or am I going to compile it manually? Btw, this is the remote version: x86_64 x86_64 x86_64 GNU/Linux.
Thanks in advance...
"mosesserver" binary executable is located in mosesdecoder/bin directory after successful compilation.
It can be started in a similar fashion to moses, i.e.
/path/to/mosesserver -f /path/to/moses.ini
It will run a web server on port 8080 by default, expecting XML-RPC v2 protocol to communicate.
For building, make sure you have Boost libraries (+ devel package) installed at a location where they can be found (i.e. /lib or /usr/lib or lib64, depending on the system) or add the path to LD_LIBRARY_PATH if you compile them manually.