I am working on a machine with
Linux version 2.6.16.46-0.12-smp (geeko#buildhost) (gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)) #1 SMP Thu May 17 14:00:09 UTC 2007
and I don't have root privileges. I was trying to compile a self-written program that needs OpenMP. However limgomp is not installed and thus compilation fails.
Is there a way to install my program, e.g. by somehow using a newer compiler in my home directory or something?
Thanks.
If you have a compiler and sufficient space in writable directories, sure, you can just fetch the sources for missing packages and compile them there.
Installing programs from source usually consists of three steps: configuring, building / compiling and installing (copying to target locations). Read the README to find out what you have to change for configure, then usually just run make and install into your home directory or skip the install step altogether.
Add the path to the resulting executables to your PATH and you should be able to run your newly compiled programs.
Expect to spend several hours (or days) for reading documentation and waiting for compilation to finish (depends on how much you have to compile). Or, maybe, look for another way to get things done.
You should be able to compile the dependencies yourself and put the libraries in your home folder somewhere, and then add their location to your PATH variable.
If you're doing this on a university computer system, you might consider sending an email to your friendly local network administrator and ask him to install them for you, I had to do the same thing at RIT to get them to install the openssl development libraries.
Related
I have an application that I built using Qt Creator on Linux and want to deploy it now. However, I don't want to statically build it as I don't want it to be open-sourced. I tried the ldd ./YourExecutable command, however that only lists (and not add) the additional dependencies the application needs in order for it to run. My question is, how do I gather the necessary dependencies without having to individually look for these files? Is there a tool, such as windeployqt.exe on Windows, that I can use on Linux for the same purpose? Or is there a better approach than the one I'm thinking of?
Get Cygwin setup.exe: http://www.cygwin.com/
1.1. Run setup.exe and continue to package selection list.
1.2. Under Devel catagory select tools you need for compiling your source. For
example 'GNU make'.
1.3. Finish installing.
Get linux crosscompilers for cygwin:
"cygwin-gcc-linux.tar.bz2" (68.2 Mb).
md5sum: 340e91a346f5bb17e660db10e43005b8
These compilers are made with crosstool 0.28-rc37. This package contains:
gcc-3.3.4 and gcc-2.95.3 for i386 (glibc 2.1.3) and gcc-3.3.3 for amd64
(glibc 2.3.2).
Note! There is now newer version of GCC avaible with glibc 2.3.2:
"cygwin-gcc-3.3.6-glibc-2.3.2-linux.tar.bz2 (i386, x86_64)".
2.1. Copy 'cygwin-gcc-linux.tar.bz2' to 'c:\cygwin' or install directory which
you selected in setup.exe.
2.2. Open Cygwin shell and change directory to root with 'cd /'.
2.3. Uncompress to Cygwin root with command:
'tar -jxvf cygwin-gcc-linux.tar.bz2'.
Cross-compilers are installed under '/opt/crosstool'. You can use theim
directly or with commands: gcc-linux, g++-linux, gcc-linux-2.95,
g++-linux-2.95, gcc-linux-x86_64 and g++-linux-x86_64.
From: Cross-compiling on Windows for Linux
More info here.
It sounds like you want to use the shared library deployment option:
http://doc.qt.io/qt-5/linux-deployment.html#creating-the-application-package
Then if you wanted to go further than that, you could look into making a .rpm or a .deb .
There are lots of examples of qt projects that are now available on GitHub and have packages made. Usually for prebuilt binaries you need to make one for x86 and a separate one for x64.
Hope that helps.
I'm pretty new to linux, and I want to have installed multiple toolchains versions on my machine for testing purposes, I've read many documents on the internet refering to how to install test/experimental/unstable packages to get very new compilers packages (i.e. g++-6), but after setting Debian to find packages from test/experimental/unstable channels and install g++-6 my machine crashed, so as a new Linux user I would like to get your help to understand what is the recommended way of doing this, in my case I would like to have an easy way of testing my code against g++ (4.9, 5 and 6).
On Windows I used to download a zip package from a daily build version of mingw including g++ 5 or 6 and just setted the IDE to look for the toolchain in each folder, is that possible on Linux?
Mixing up stable/testing/unstable branch of debian is not easy and i wouldn't recommend to do it. What you could do is to download diractly the tarball, or clone the cvs and compile the compiler on your own, having each version in their own directory.
The different releases can be found here, for example.
I was wondering if there is a way in MSYS2 to specify the base MinGW/MinGW64 directory?
In MSYS (i.e., MSYS-1), after installing MSYS, it knows that the directory structure is, e.g., /c/mingw/msys/..., and if you install a mingw package using mingw-get, the installed binary goes to /c/mingw/bin. I think this might be because there is /mingw mount in the default /etc/fsab.
Now, when I do a similar operation under MSYS2/MinGW64 with MSYS2 at /c/mingw/msys64, the binary isn't installed the /c/mingw/bin anymore. For example, if I install clang as follows:
pacman -S mingw-w64-x86_64-clang
the binary is installed to:
/c/mingw/msys64/mingw64/bin/clang.exe
as if MSYS2 were creating another mingw64 installation within itself (with bin/lib/etc/share ...). This confuses MinGW64, as it reports that clang cannot be found. I know I can add another path, but it's rather weird to have one MinGW installation at the root, and another inside a subfolder of MSYS2. And I suspect this could cause inconsistency in the tool-chain in the future.
My question is, is there a way to let MSYS2 install MinGW packages to the MinGW directory tree as with MSYS?
Thanks
To say that you have "another mingw64 installation within itself" is the wrong way to think about it. MSYS2 is the system that is running the show, that you chose to put it in a folder called "C:/mingw" doesn't make that folder a mingw-w64 system in any way, you've just got an MSYS2 system rooted at "C:/mingw/msys64"
I'm afraid that MSYS2 doesn't allow selection of root folders for any of its 3 repositories outside of selecting the global system root (i.e. the folder to which you install or unpack MSYS2). The main reason for this is because we use pacman as our package manager and this facility doesn't exist there since it is a tool to manage the entire system and as such, all pacman packages are compressed with absolute folders (which are unpacked relative to the global system root).
Since MSYS2 (via Cygwin; credit for the core of MSYS2 lies with Cygwin) provides "/etc/fstab", you might think to use that to enable you to put "/mingw{32,64}" elsewhere, and to an extent you can get away with that, but I strongly urge you not to do this as it will just result in problems. For example, Native Windows programs that expect to be able to use a relative path of "../" to get from "C:/msys64/mingw64" to "C:/msys64" will be sorely disappointed, and by that I mean will they will likely crash. For this reason I am not going to tell you how to achieve such a broken system.
You should try to think of your MSYS2 install as being a complete sub-system in its own right, where we've made some decisions (like the location of the "/", "/mingw32" and "/mingw64" folders) for you to improve compatibility and remove some variables that would make problems more frequent and difficult to diagnose and fix.
I would also recommend installing MSYS2 to the root of a drive (any drive) due to Windows 260 MAXPATH limit. I know that with UNC paths the limit is much further out, but most MSYS2 and Windows software do not use UNC paths and have hardcoded C string arrays of size MAXPATH+1 all over the place. Doing this may also help you to think of the MinGW-w64 repositories as being sub-repositories of the overall MSYS2 system, rather than the other way around.
For pacman reference, you should use these pages:
pacman.conf(5) Manual Page and pacman tips
What is the equivalent of ./configure in Windows?
Sometimes I download a C/C++ library and when I use the make it, it says "use ./configure" but obviously ./configure can only be used on a Linux machine and the libraries don't usually have instructions for compiling on Windows (although they do support Windows, they don't provide instructions).
For example, the library wxSVG says it works on Windows, but when I download it I don't see any instructions for compiling on Windows, and I only Linux files for configuring it.
I just faced with the same issue and here is what I did,
I first installed MinGw using the installation manager (with msys base included). Then I go to C:\MinGW\msys\1.0\ folder in my pc, where msys.bat (to evoke the MinGW shell) and run it. Then on that bash screen, I navigated to the folder that I wanted to install initially. After that, using "./configure" and "make" worked just fine.
Actually, ./configure is not Linux-specific at all. Its original purpose was to smooth over the differences between the many variants of Unix now thankfully relegated to the dust heap of history, but nowadays it may well know how to set up things to work on Windows.
I would install the MinGW/MSYS development tools and see if the configure script is happy in that environment. (If that doesn't work, I can't help you any further.)
./configure is a script that comes with the source you have downloaded. You will use it the same on windows as you do on any other operating system. Unfortunately, you will need a posix-like shell to run it. A good option for that is to use mingw or cygwin
I'd say that this is program dependant. You see "configure" is a program/script in the local directory, it's not a global command/program (like "dir" would be)...
You either have luck to find something like "configure.bat" or "configure.cmd", or you'd have to adapt the configure-file into a BATCH-file.
You only run the ./configure command when building certain applications from source.
So Unzip it where you want to install it and then go to the folder where you unziped it and run "./configure"
I've gone to http://sourceforge.net/project/showfiles.php?group_id=2435, downloaded the Automated MinGW Installer for MinGW 5.1.4 and at the same time the GNU Source-Level Debugger Release Candidate: GDB 6.8-3. I've then installed MinGW base tools into C:\MinGW. No problem so far.
However when I come to install the gdb debugger it has a lot of files and folders with the same names as some already installed but the files are different to those already installed. e.g C:\MinGW\include\bfd.h is 171 KB but gdb-6.8-mingw-3\include\bfd.h is 184 KB.
How do I add gdb to MinGW without breaking what's already installed?
In a command prompt I browsed to C:\MinGW\bin and ran:
mingw-get.exe install gdb
That fixed it for me. Not sure if it matters but I have C:\MinGW\bin in my path (guess I probably didn't need to browse to C:\MinGW\bin).
The Current Release (5.2.1) version of gdb at the project files page has always worked for me. The download is a stand-alone .exe, you don't need anything else.
But I'll bet the .exe in the 6.8 package will work, too. I'd try using just the .exe, and then if there are problems, try extracting the other files from the 6.8 package. (Though that may cause problems with the rest of the MinGW installation.)
Update: There seems to be a 7.something version. I haven't tested it thoroughly, but it seems to work, even with gcc 3.
Get Wascana Desktop Developer. It combines MinGW, gcc, Eclipse and gdb in one package.
You can safely overwrite the files prepackaged with MinGW with the (newer) ones from the gdb tarball. You can also choose not to overwrite them - just make sure to pick either one set, i.e. avoid mixing files from the older and the newer package.
Most of the offending files are probably not really relevant to you anyway. For example, the files belonging to the libbfd library aren't required for gdb's day to day operation, they're used if you want to extend the debugger or write debugging tools yourself.
At any rate, make a backup of the mingw directory before untarring the new release. It's very easy since MinGW is self-contained in that directory. That way, if anything should malfunction, you can just delete the directory and restore from the backup.
Usually for installing gdb in windows, You have to 2 ways to install:
1) use ready-made binaries that were build and compiled from GNU gdb by some provider (easy to install)
use TDM-GCC binaries provided from the following URL and that is including inturn the gcc complier and also gdb debugger.
http://tdm-gcc.tdragon.net/
use Equation package inside which GNU GDB was already compiled and built.
http://www.equation.com/servlet/equation.cmd?fa=gdb
2) use minimal mingw or cygwin package then after install gdb inside it.
Install either mingw or cygwin inside which GDB is already shipped
Open cygwin or mingw terminal and just type the following to make sure it is already installed
$ gdb --version
Hint: if you did not find gdb installed, simply open the cygwin or mingw package installer and make sure you already check gdb
Hint: getting and installing a debug build of the OHRRPGCE is providing useful information about crashes.
From cygwin or mingw terminal, Start gdb using the following
c:\mingw\bin\gdb.exe program_to_debug.exe
REF: http://rpg.hamsterrepublic.com/ohrrpgce/GDB_on_Windows
The TDM GCC/MinGW32 builds installer includes gdb. It's gcc 4.4.x with all the core binary packages required for basic Windows development, and is widely used without any unusual problems.