there.
I'm trying to install the Microchip XC8 compiler on a Ubuntu container to make a pipeline for building the project with Gitlab CI. But there's no response after I run the "xc8-v1.45-full-install-linux-installer.run" file.
Here is the environment I have:
Official Ubuntu 18.04 LTS image on a Docker container
Docker version 19.03.13
Windows 10 as Docker host
Microchip XC8 v1.45 compiler
And the commands I used for downloading and installing are as following:
# Download XC8 from the Microchip official site
wget http://ww1.microchip.com/downloads/en/DeviceDoc/xc8-v1.45-full-install-linux-installer.run
# Change the access permission
chmod +x xc8-v1.45-full-install-linux-installer.run
# Execute the ".run" file
./xc8-v1.45-full-install-linux-installer.run
After I did them all, there's no response. Obviously, something went wrong.
I have tried the installation process above on a native Ubuntu computer, and it just works fine.
Is there any prerequisite I missed? Or there have some ways for me to achieve the same purpose?
Thanks!
I was having this problem on 64 bit Ubuntu 20.04 as well.
I had several problems, could not change execution bit because it was on an NTFS partition and the executable required 32 bit libraries to run.
First I had to move the file from an NTFS partition so that I could set the file to executable. In my case I moved it to my downloads directory and then in that folder executed:
sudo chmod +x ./xc8-v1.42-full-install-linux-installer.run
It still would not run, so I checked its type by executing:
file ./xc8-v1.42-full-install-linux-installer.run
which resulted in the response:
./xc8-v1.42-full-install-linux-installer.run: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, no section header
Eventually the main solutions was to install 32 bit libraries:
sudo apt-get install lib32z1
Finally I could install install that 32 bit library. Then running this worked:
sudo ./xc8-v1.42-full-install-linux-installer.run
Using existing MPLAB Docker repo
This GitLab.com project exists:
MPLAB X IDE/IPE podman/docker container
This may not help with your .run file problem, but maybe switching to an existing docker container might make it easier for you.
They also work with .run files, so you may find your solution over there as well.
Features:
Has a general-purpose installation of MPLAB X and the toolchain.
X11 forwarding for working in the IDE is supported.
Can use USB from inside the container.
Requires some setup. See readme for installation instructions.
MIT License
Need to test this still myself, but just wanted to share here, might just as well.
Posted in the microchip forums by the creator:
Dockerfile for MPLAB X IDE/IPE and toolchains
Related
I am following this tutorial. I already have .fastq files. I want to install ea-utils.
My setup is Ubuntu 18.04 bionic, via Oracle VM Virtual Box.
In terminal, I entered the command:
>>>sudo apt install ea-utils
E: Unable to locate package ea-utils
First, I installed latest Ubuntu updates via. Software Updater.
Then,
>>>sudo apt-get update
E: Some index files failed to download. They have been ignored, or old ones used instead.
Still throwing an error:
>>>sudo apt-get install ea-utils
Second command said: E: Unable to locate package ea-utils.
You cannot install it using Git-Bash. Git-Bash is not a Linux environment (apt-get is a Linux utility that can be used in a Linux environment). Git-Bash is a subset of the MSYS (or MSYS2, not sure) collection of open source tools compiled for Windows
What you can try is
build your own version of ea-utils for Windows. build guide - I will elaborate if required
check if there are any precompiled binaries for it
Expanding on building/compiling your own binaries of programs
Normally a program is written in a programming language (e.g C/C++, Java) that humans can read. These are plain text files.
That is compiled into something computers can read
This compiled file is executable on the platform which it is compiled for - ends in .exe for Windows
This executable file is distributed as a 'precompiled binary' that is copied into (usually) C:\Program Files by the installation procedure
But things change in the world of open source software
You are given the original files of code written in a programming language
You use a compiler combined with other libraries to compile it into an executable file
MinGW is a collection of tools, including the C/C++ compiler for Windows
GSL is a library that provides some other code that ea-utils depends on for the compilation of the binaries
General instructions for building
(Sorry I cannot test these. I do not use Windows any more)
Install MinGW - accepting the defaults should work fine
Install GSL - try the link that says Setup (again, accept defaults)
Unzip the file you downloaded earlier from ea-utils' GitHub
Open command prompt
cd into the unzipped folder
(based on instructions on their wiki) make
make test
Since your updated question is based on using Ubuntu 18.04 in a VM and you there is still an error, I suggest trying
sudo apt-get update
sudo apt-get install ea-utils
Commonly, software in the Linux word is distributed as "packages" - e.g ea-utils. The first command contacts Ubuntu's repositories (they serve the packages) and generates a list of all the available packages.
That should fix the error of ea-utils not being found.
Following the constant errors being thrown,
Download the .deb file 64-bit version or 32-bit version according to the virtual machine you are running. Open it inside the virtual machine, and follow the onscreen instructions.
When I run "sudo sh VBoxLinuxAdditions.run" just like on Ubuntu or CentOS, TinyCore throws errors and failed, and the /var/log/vboxadd-install.log shows that:
/tmp/vbox.0/Makefile.include.header:97: *** Error:
unable to find the sources of your current Linux kernel.
Specify KERN_DIR=<directory> and run Make again. Stop.
I have used tce tools installed some packets such as gcc, make, linux-kernel-sources-env.tcz, linux-3.16.2_api_headers.tcz, and then the VBoxLinuxAdditions.run can get the KERN_DIR, but no KERN_INC at this time.
If anybody has done this before could you please give me some points? I really don't know which packages should be installed in TinyCore to make VBoxAdditions work. My VBox and TinyCore is up to date. Thanks.
Found a repo for this issue, but have yet to verify:
https://github.com/MSumulong/vmware-tools-on-tiny-core-linux
Prior to that, I attempted to follow this tutorial, but it is incomplete:
https://www.gilesorr.com/blog/tcl641-guest-additions.html
Prior to that, attempted to build the kernel headers (/lib/modules/5.15.10-tinycore) with no luck.
Copying the Guest Additions to home folder and running sudo VBoxLinuxAdditions.run returns "Kernel headers not found for target kernel 5.15.10-tinycore. Please install them and execute /sbin/rcvboxadd setup"
Basically you have to install the package linux-headers-${kernel_version}
# apt-get install linux-headers-3.16.0-4-amd64
This solved my problem on Debian linux.
To check the version of your kernel, you should run the command:
# uname -a
# Linux debian 3.16.0-4-amd64 # SMP Debian
we use a setup, created with install4j (we still use 5.0.11). On a new local unix machine (Linux version 3.8.13-44.1.4.el6uek.x86_64) this setup failed, the log shows:
Unpacking JRE ...
micsetup.sh: 210: micsetup.sh: bin/unpack200: not found
Preparing JRE ...
Error unpacking jar files. The architecture or bitness (32/64) of the bundled JVM might not match your machine.
Searching for this error I found this:
the program tries to run the file /bin/unpack200 which does not exist. However, the file /usr/bin/unpack200 does exist. This is due to the fact that this file is in different places depending on the architecture of the machine used - if it is 32bits, it is in one place, if it is 64bits, it is in the other. I am having this problem because the file was made to run on a 32bit architecture but I am using a 64bits machine. Therefore to fix this problem one must install 32bits libraries.
After running
sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386
our setup works.
My question: is there a way to configure the "Unix installer" in install4j to build the setup, that it works on 64 bit Linux systems like the mentioned without installing additional libraries on this system? I think not all of our customers would allow this.
Thanks in advance!
Frank
No, there is no such functionality in install4j. Bundling JREs on Linux is generally problematic.
One strategy would be to offer installers with 32-bit JRE and installers with 64-bit JREs.
I need to build locally a driver for "precise" Ubuntu edition (uname -r for that system returns 3.2.0-33-generic-pae).
My local host is Ubuntu 13.10 'sausy'.
But I fail to install the linux headers( what should I do to set up the environment I need?)
I downloaded the image from here: from packages.ubuntu but what my next steps should be?
Actually I don't need exact steps but pointing the right direction would be great!
Thanks in advance :)
If you want to just build the driver (with out installing/testing)
then you will just have to download the kernel source of the preferred version (in this case it is 3.2.0-33) from kernel.org, build it with config from your host PC, and then compile your driver/module against that.
If you plan to install/test then after building the kernel source of the preferred version,
install the same to your host PC, then you will be able to insmod the driver you built
How do I run Linux binaries under Mac OS X?
Googling around I found a couple of emulators but none for running Linux binaries on a Mac. There are quite a few posts about running Mac OS X on Linux and that kind of stuff - but that's the opposite of what I want to do.
Update:
Thanks for all the answers! I am fully aware of MacPorts and Fink or any of the other things; and no, I do not want any of these utilities, and I do not want any of the package managers, I prefer to compile things myself. I also have Parallels and could set up virtual machines and all that jazz...
The only thing I want to do is to find a way to run a binary that I do not have the source code for and has been compiled for Linux, but I do not want to run it under Linux but under Mac OS X. Therefore my question about emulators.
Well there is a project introducing something like Linux's binfmt_misc to OS X so now what you need is an ELF loader, a dynamic linker that can load both Mach-O and ELF, and some mechanism to translate Linux calls to OS X ones.
Just for inspiration, you can implement the dynamic linker in the fashion that it ignores filename extension - both libfoo.so.1 (as an Linux ELF) and libfoo.1.dylib (as an Mach-O) can be loaded so that OS X versions of system libraries can be reused so that you do not need to write a "hosted on OS X" libc.so and syscalls can be handled by an kext that translates Linux calls to OS X ones in kernel.
Or, in an more elegant way, implement a stripped down Linux kernel as a kext that makes the OS X kernel a dual-purpose. However that will require you to use two sets of libraries. (Binaries do not clash so it is largely okay)
Set up a virtual machine (I personally use VMWare Fusion) and then install whatever distro of Linux you desire on the virtual machine.
Or, if you have the source to the Linux program, chances are you can recompile it on a Mac and run it natively. If you install Fink or MacPorts, you can install a lot of open source programs without much trouble.
I recently found Noah, which you can use to run Linux binaries on macOS. You can install Noah via homebrew (brew install linux-noah/noah/noah). Then you should be able to do this:
noah linux_binary
In my experience the behavior of the binary matches what I see on my Ubuntu machine.
You might have some luck with running Linux executables under Mac OS X using Qemu's User Space Emulator
If you decide to go the virtualization route, consider also VirtualBox.
Also, if you only need UNIX like command line tools, there is the MacPorts project. This is basically how I set up git on my mac: after having installed MacPorts you just have to run the sudo port install git command to install git on your system.
noah does not allow the binaries to execute properly for me. Use Docker Desktop for Mac.
Just do:
docker pull centos:latest # 73MB CentOS docker image
Make a folder for what is needed to run your binary, and in your Dockerfile:
FROM centos
COPY your_binary /bin/
ENTRYPOINT ["your_binary"]
and you can build it with
docker build -t image_name
then execute with
docker run image_name as if it were the binary itself. Worked for me. Hope it helps someone else. And if you need specific outputs or to store files somewhere you can mount volumes onto the docker with -v, for example:
docker run -v path_to_my_stuff:/docker_stuff image_name,
though adding a WORKDIR /docker_stuff line to the Dockerfile before ENTRYPOINT is probably best.
If you change ENTRYPOINT to
ENTRYPOINT ["bash", "-c"]
and add
CMD ["your_binary"]
underneath it, you can actually pass the command into the image like
docker run -v path_on_local:/in_container_path image_name "your_binary some_parameters -optionrequiringzerowhitespacebeforeinputvalue"