I'm moving an existing VxWorks 6.9 build system from Windows to RedHat Linux. In theory this should be easy but it seems that if I install VxWorks 6.9, from the same CD, on Linux then the dcom-2.3 library (and a couple of others) are not installed - installing from the same CD on Windows does install them.
Anyone know what I am? This is a cross-compiler environment for an embedded system so I can't see any reason that the installed libraries should be different between the two host systems.
Related
Because Msys2 sucks,
as mentioned above, I need to change its default server mirrors to point to Arch Linux Mingw-w64 AUR ones, and make it as the default one.
So when I issue some pacman -S mingw-w64-* it will download the package from Arch Linux Repository and not Msys2.
I need to use Msys2 only as a shell.
Msys2 Minwg-32/64 builds use Dwarf instead of SJLJ as exception model, and this is a very bad choice, because they don't catch exceptions from other DLLs that are built with other tool-chains, and the application will crash (For example Firebird 2).
Arch Linux is smart, and has chosen to use SJLJ as exception model for its Minwg-32/64 builds.
This seems very unlikely to work. pacman for MSYS2 will download Windows PE binaries for your MSYS2 environment. pacman for Arch Linux is going to download Linux ELF binaries. You won't be able to run these on your Windows device.
You may be able to get what you want if you use Windows Subsystem for Linux (WSL).
We are currently provisioning a physical server as our automation server. We are making considerations as far as what our native operating system should be on this physical machine.
We are going to use a Linux OS as our operating system. From the Jenkins download page, I can see that Jenkins’ package distribution is available to Red Hat / Fedora / CentOS (which we will not be using), as well as Ubuntu / Debian. I also notice that a Generic Java package (WAR) distribution is available.
Am I correct in assuming that if we use a non-Ubuntu / non-Debian
operating system, we can still install Jenkins via the WAR
distribution without issue?
If we are not able to install via WAR without issue, are we relegated
to using Debian / Ubuntu if we’re going to install Jenkins on a Linux
machine (with the possibility of Red Hat / Fedora / CentOS ruled
out)?
It should probably be noted that we will likely install / upgrade on the Jenkins LTS release schedule.
Thanks for any guidance from anybody who may have experience installing / maintaining a Jenkins instance on a Linux machine!
I want to install Gitlab on the suse linux OS.
Could some one please suggest me which OS supported Gitlab installer from the available ones on Gitlab site : Ubuntu, Debian and Centos can be used to install Gitlab on Suse linux ?
OS details :
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 4
I'm afraid that Suse is a complete different system. They use a package manager called YaST that won't be compatible with any of the proposed OS on the GitLab website.
Alternatively, you can try installation via Docker (Hopefully your system is 64bits):
https://gitlab.com/gitlab-org/gitlab-ce/tree/master/docker
Or the hard way, manually:
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/installation.md
Or even pop an instance somewhere in the cloud but this would involve some costs.
For all other OSs it has packages to install all the required components, but for SUSE there is no package, so you will have to install all the required components like ruby, redis, mysql and other dependent libs on your own.
You may like to try this :
https://gist.github.com/rriemann/5163741
or
https://gist.github.com/jniltinho/5565606
Since I found this answer while looking for the installation on SUSE 12 (SP3), there is one of the currently working options (2021).
First, check the version supported on the system, (Gitlab 12.1 in case of SUSE 12 SP3, which corresponds to OpenSUSE 42.3)
After that, get the proper .rpm file using wget.
Install with
sudo EXTERNAL_URL="http://gitlab.my.domain" rpm -ivh path/to/file/filename
That's it. Some Versions of Omnibus for SUSE are supported directly, but it really depends on the host system version.
I have been working with Linux kernel, compiling and inserting modules, in my custom kernels. Previously I had Ubuntu where I had been working with my custom kernel and all the commands for compiling and installing kernel worked like a charm once I had installed all the required libraries.
Now I have switched over to Fedora 20, here I want to install my custom kernel and for that I downloaded all possible kernel tools, namely, Kernel Development Kernel Tools these are group installs and other libraries that I downloaded were ia32 libraries (as I am working on 64-bit OS), kernel-devel package. Still I am not able to work with make-kpkg command. It says bash: make-kpkg: command not found....
I googled out and did everything I could.
Can anyone get me out of this trouble?
make-kpkg is a Debian kernel packaging tool. It does not exist on RHEL family distributions, such as Fedora.
Please refer to the Fedora documentation page "Building a custom kernel" for the correct procedure. (I have not reproduced it here as it is rather long, and I'm not sure how far you may have gotten.)
The make-kpkg tool is part of the 'kernel-package' package on Debian systems. It is a Debian tool to produce debian package files. Ubuntu is based on Debian and has this tool. However, Fedora uses a different system to manage packages. So, make-kpkg would not be available on Fedora.
My .deb package, built on 32-bit Ubuntu and containing executables compiled with gcc, won't install on the 64-bit version of the OS (the error message says 'Wrong architecture i386'). This is confusing to me because I thought that in general 32-bit software worked on 64-bit hardware, but not vice-versa.
Will it be possible for me to produce a .deb file that I can install on a 64-bit OS, using my 32-bit machine? Is it just a matter of using the appropriate compiler flags to produce the executables (and if so what are they), or is the .deb file itself somehow specific to one processor architecture?
The deb installer is probably refusing to install your package because it was (correctly) labeled with a conflicting Architecture: field. i386 code can be executed on an amd64 machine, but it requires that all the appropriate dependencies (32-bit libraries, etc.) be present. It's better to build separate packages for each architecture.
Yes, you can build for 64-bit on your 32-bit machine. It's called cross-compiling, and it requires that you create a build environment for that purpose. To get started, you might want to look up the dpkg-cross and apt-cross tools.
Alternatively, you can just install a virtual machine running a 64-bit OS, and build for your secondary architecture there.
The architecture is just an option in the config file of debian package. By default it uses those from uname. You can override it but there is an easier way.
In general, most 32-bit programs will run fine on 64-bit. However, unless you have a very old PC, it is also very easy to install a mini 64-bit debian in a virtualbox virtual machine. You probably only need base + build essentials + dev libraries. This will not take a lot of diskspace. If you can spare 2G diskspace, just install a desktop debian.
There are more options to do crosscompilation, with various degrees of automation.
I use the virtualbox method regularly. It is easy and fast.
If you run 64-bit linux making a 32-bit environment is as easy as mkdebootstrap + linux32 + chroot.