I'm following this video tutorial for using the Intel compiler, and the first thing to do is to source the compiler. In the video, this is the command:
source /opt/intel/composer_xe_2015.0.019/bin/iccvars.sh intel64
However, I'm using the 2017 version and the dir tree is different. I found the same file in:
source /opt/intel/compilers_and_libraries_2017.1.132/linux/bin/iccvars.sh intel64
Is this the analogous command, or do I need to do something else?
The linux/ subdirectory was added with ICC 17; 16 and below didn't have it.
Yes, they're basically the same.
Related
I'm trying to download glibc 2.23 sources and build them on my Ubuntu system.
I need to build that specific version from sources for getting modified version of glibc customized for my research, and it will be used only within my research apps using the loader environment variables (e.g., LD_PREDLOAD or LD_LIBRARY_PATH).
But, when building it as following, I got a huge file as an output (libc.so weights about 11MB):
download the sources to some local dir (let's say /tmp/glibc/)
create new directory for build results (/tmp/glibc/build)
run configure from build dir:
< build-dir >$ ../configure --prefix=< build-dir >
As a result, the build process will produce libc.so file under build-dir with a size of 11MB.
Is there anyway to reduce the size of the built libc.so?
p.s.
Here are my system details:
Linux version 4.4.0-93-generic (buildd#lgw01-03) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #116-Ubuntu SMP Fri Aug 11 21:17:51 UTC 2017
Thanks :)
Building glibc from source could be a bad idea. See this and some comments there. Its current version is GNU libc 2.26... Consider instead upgrading your entire Ubuntu distribution (Ubuntu 17.10 should be released in a few weeks, end of October 2017)
../configure --prefix= build-dir
is a misunderstanding of the role of --prefix in autoconf-ed software. It relates to where the software is installed, not to its build directory.
(and I don't know exactly what should be your --prefix since libc is so essential to your system, perhaps it should be --prefix=/ but you should check carefully)
Is there any way to reduce the size of the built libc.so?
You might use (very carefully) strip(1), but you risk breaking your system.
And you might not care about reducing the size of libc since it is used (and shared) by almost every software on your Linux system!
BTW, consider also musl-libc. It can cohabit nicely with GNU glibc, and in practice is used only by programs built with musl-gcc (provided by it).
If you are doing some research, it would be reasonable to work in a chroot(2)-ed environment. See also schroot. You could install with the help of make install DESTDIR=/tmp/instmylibc then copy that /tmp/instmylibc appropriately. Read more about autoconf
PS. Be sure to at least back up your important data before such dangerous experimentations. I don't think that the size of your libc.so should be a significant concern. But you need to use chroot, perhaps with the help of debootstrap during installation of the chrooted environment.
I am trying to integrate a Matlab program I wrote into some Fortran code. I tried to follow the example Mathworks provides. But I can't get it to compile because I can't find the header files it requests.
Does anyone know of an example of someone getting it to work on Linux using an Intel compiler. I think that might be part of the problem because Matlab only supports GNU Fortran on Linux.
And I realize this is a simple question, I just don't understand how to do anything in compiling more complicated than including multiple files with defined paths.
Disclaimer: I'm currently using OS X so I can only provide output from OS X but everything should transfer easily over to Linux due to the Unix base. I also don't have the Intel Fortran compiler on OS X (only the C/C++ compiler).
Note: You will need to substitute the paths I use for the correct paths on your system depending on your MATLAB installation directory.
This issue isn't specific to the Intel Compiler, I also receive errors with the GCC Fortran compiler.
$ gfortran fengdemo.F
fengdemo.F:1:0:
#include "fintrf.h"
^
Fatal Error: fintrf.h: No such file or directory
compilation terminated.
You can use the Unix locate command to find files.
$ locate fintrf.h
/Applications/Matlab R2014a.app/extern/include/fintrf.h
In the directory where fengdemo.F is we can then pass the correct directory in using the -I option
-I../../include/
However, this produces linking errors as we haven't specified where the libraries for fintrf.h can be found. We can do this with the -L option (you will need to replace maci64 with the correct option for Linux - I can't remember it off the top of my head but you should be able to see it in the bin directory)
-L../../../bin/maci64/
Now we need to tell it what libraries to use with -leng -lmx and so the completed command is
$ ifort fengdemo.F -I../../include/ -L../../../bin/maci64/ -leng -lmx
and it should compile correctly.
We aren't finished yet though as it won't execute. We need to set up our PATH and DYLD_LIBRARY_PATH environment variables correctly. Specifically we need to add the bin and bin/maci64 directories of our MATLAB installation to PATH
$ export PATH=$PATH:/Applications/Matlab\ R2014a.app/bin/maci64:/Applications/Matlab\ R2014a.app/bin
and the bin/maci64/ and sys/os/maci64/ to DYLD_LIBRARY_PATH
$ export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/Applications/Matlab\ R2014a.app/bin/maci64/:/Applications/Matlab\ R2014a.app/sys/os/maci64/
Note: On Linux DYLD_LIBRARY_PATH should be LD_LIBRARY_PATH. Thanks to Vladimir F for correcting me.
Now you can execute the program using
$ ./a.out
I have a problem with Linux embedded OpenWRT.
I must compile a software for arch MIPS.
The software is composed of 2 file.c and 4 /include/file.h ...
I have compiled a toolchain for Openwrt with the "new" gcc (for mips) I have compiled one by one the 2 file.c getting 2 file.o as output. How can I create a unique binary file to execute the software?
Second question: it is correct to compile the file one by one?
Thanks, I hope that my question is clear.
You can create an OpenWrt package. See this tutorial. You can point OpenWrt to the folder, where your files are and let compile the project there instead of pulling it from a VCS repo.
See this SO answer about compiling multiple files with GCC.
I am using a software for graph mining.
I have got the binary of that software in 2 folders for Linux mode and SunOs mode but don't have the source.
I am able to run the binary in Linux machine.
But when I want to run the binary in a Mac machine I am getting "command not found" for both the Linux and SunOs folders' binaries.
Could someone suggest if it can be able to run this in a MAC machine by any means like using a Linux shell or something
Gaurav
EDIT:I am getting "cannot execute binary" error when I set chmod to "u+x"
You'll need to recompile it for OS X or use a VM.
A command not found just means you're not executing it right, make sure it's chmod u+x and it's either on your PATH, or you specify the path explicitly.
If you use the file command you will see the difference, on the linux executable you'll have something like:
ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically
linked, for GNU/Linux 2.6.15, not stripped
and something like this for OS X executables:
command: Mach-O universal binary with 2 architectures command (for
architecture x86_64): Mach-O 64-bit executable x86_64 command (for
architecture i386): Mach-O executable i386
Operating systems generally don't support executing object code any extra formats... If Mac osx decended from solaris or Linux, then there could be some incentive for legacy support. But just assume everything to be binarily incomparable if it was compiled for a different arch and platform. There are a few places where you inherit backwards compatibility, running 32 but code on 64 bit oses... Or ppc code support on intel macs, but I suspect that both of those, especially the latter were non trivial engineering tasks.
Here are your options...
Get the source and compile on the Mac, if it compiles on Linux and solaris good chance it will compile and run ok on Mac.
Run through an emulator or boot camp
Are there any command line interpreters or any other set of programs around for x86 linux in order to run MIPS assembly programs?
I'd like to be able to write simple MIPS assembly programs and run them from the console on my local machine.
I know of SPIM but it requires X Windows and I'm curious if there are better options out there.
Edit: Turns out it doesn't require X Windows. I still have issues with SPIM. Not the best in my humble opinion. Qemu / Cross compiled toolchain is a little more work but I have less quirks.
Incidentally, Spim does not require X Windows. It has a console interface as well. Run either spim or xspim.
You will need either a cross compilation toolchain, or to build your own cross binutils.
For a prebuilt toolchain, you can visit code sourcery. If you just want to compile assembly, then all
you need is binutils. There are some guidelines on the Linux Mips wiki
For the emulation part, QEmu would be my choice.
MARS made my assembly programming for MIPS architecture so much easier. If you would like a GUI/IDE, I would recommend MARS for sure.
I was in the same situation yesterday. I also didn't like SPIM, so this is what I did:
installed gxemul and gxemul-doc (those are the package names on debian)
installed netbsd on an emulated MIPS machine following the detailed instructions in the documentation
since netbsd already includes the standard gcc toolchain and vi, you're good to go.
Setting up networking is pretty easy and well documented, too. This has the advantage of not needing to fiddle with cross compilation.
You could use gxemul, which emulates a MIPS machine (among others, including Dreamcast), and is able to run many Operating systems (included linux, netbsd and some more).
gxemul-wikipedia
gxemul-home page
QEmu has a good MIPS emulator. Combine that with a cross-compiled GCC/binutils (technically you only need binutils to get GAS, the GNU assembler) and you're good to go.
Assuming you wish to use GCC.
Steps for compiling for MIPS on an x86-64 system, and then running the executable using an emulator:
Use a cross-compilation toolchain to produce an executable.
If you are on Debian/Ubuntu, install a cross-compilation toolchain for MIPS. For example, either of these APT packages: gcc-mips-linux-gnu (MIPS big endian) or gcc-mipsel-linux-gnu (MIPS little endian).
Compile using mips-linux-gnu-gcc (mipsel-linux-gnu-gcc for little endian MIPS); assemble using mips-linux-gnu-as; link using mips-linux-gnu-ld.
Run the executable using an emulator.
Install an emulator that can launch Linux programs compiled for one architecture (e.g. MIPS) on another architecture (e.g. x86-64): sudo apt-get install qemu-user.
Run your executable compiled for MIPS using the emulator: qemu-mips ./a.out (or qemu-mipsel ./a.out for little endian MIPS). Simply running ./a.out might also work; the emulator might be used automagically if you (or your distro's qemu package) has set up binfmt-misc to transparently run qemu-user.
Maybe you can take a look at these emulators? I'm not an expert but the list seems good.