Hot answers tagged

159

This is binfmt_misc in action: it allows the kernel to be told how to run binaries it doesn't know about. Look at the contents of /proc/sys/fs/binfmt_misc; among the files you see there, one should explain how to run Mono binaries: enabled interpreter /usr/lib/binfmt-support/run-detectors flags: offset 0 magic 4d5a (on a Debian system). This tells the ...


7

Sure, of course, since you can develop portable software that runs on both MacOS and Linux. Be sure to test it on Linux at regular intervals to make sure you haven't unintentionally added something unportable. If you want to use Linux-specific features then you will have more of a hard time. Depending on what it is you do, the program may compile on MacOS ...


6

You use a cross compiler to produce executables (or objects) for a platform other than the local host. The native compiler only produces native binaries.


5

On Debian, there are apt-cross and dpkg-cross from Emdebian, which let you set up cross-compilation for many architectures (you get cross-compilers and libraries). On Ubuntu, there's a crosschain for ARM, and a project to improve on this. You can also create toolchain using crosstool-ng which is not link to a distribution.


5

Understanding the Basics From the wiki entry of MIPS architecture, it is described as, MIPS (originally an acronym for Microprocessor without Interlocked Pipeline Stages) is a reduced instruction set computer (RISC) instruction set (ISA) developed by MIPS Technologies (formerly MIPS Computer Systems, Inc.). From the wiki entry of the x86-64, ...


5

Host: The environment you are running the compiler on. Target: The environment you are compiling something for.


4

Now that I'm at work, I'll write up a step by step answer. First off you seem to be doing the steps in the wrong order. As such, I'll number these steps in the order they should be executed. mkdir -pv ~/chromium cd ~/chromium git config --global user.name “Joel Maranhao” git config --global user.email “youremail@example.com” git config --global ...


4

You need two things to cross-compile: a compiler that can generate code for the target architecture, and the static libraries (*.a) for the target architecture. Install at least the libc6-dev-i386 packages, and possibly other lib32.*-dev packages. The libc6-dev-i386 also pulls in the components of gcc needed for cross-compilation in the gcc-multilib package ...


4

Emdebian repositories are recommended to be used in stable most of the time since there could be utilities not built in the repositories, packages that were pulled back, etc. If you want to ensure that all your libraries have the correct dependencies, I would suggest stable or testing since they are less likely to have some dependency problem or have ...


3

It seems you are confused between the native compiler and the cross compiler, isn't it ? The commands you tried to use the native compiler : gcc -v gcc -print-prog-name=cc1 You should try ${CCPREFIX}gcc -v ${CCPREFIX}gcc -print-prog-name=cc1 Reading your comments I think you installed the gcc cross-compiler as ...


3

If you look into drivers/usb/serial/Makefile, you'll see that CONFIG_USB_SERIAL_QUALCOMM is responsible for this driver. Execute make menuconfig and goto "Device Drivers"->"USB support"->"USB Serial Converter support"->"USB Qualcomm Serial modem"


3

You need the gcc toolchain for both. The toolchain is part of the android source tree. Before you build the entire android source, you use the "lunch" tool, which sets the environment variables such that a prebuilt toolchain can be used. http://source.android.com/source/building-running.html#choose-a-target The page about compiling the android kernel has ...


3

The errors are likely from a wrong combination of build variables. The CLFS Build Variable page has detailed explanation on the best combinations of variable settings for different architectures. Similar configure script problems has been solved by changing the CLFS_ARCH variable to thumb For another similar BeagleBoard configure script error, the ...


3

No, there's absolutely no reason why you should build X (or most programs) on the same operating system that you'll run it on. It's often more difficult, occasionally even impossible, to build software for a different processor architecture (amd64/arm/ppc/x86/…). Building for a different operating system is easier, and the precise kernel version is ...


3

The kernel version has no bearing on compiling code for another system. Unfortunately without being able to install any software on the host system you're going to be out of luck. You need a compiler suite that will generate code for your target platform (ARM in this case) and by default such a compiler suite isn't installed on most systems - if they have a ...


3

There is a GNU standard naming scheme for compilers and other parts of the toolchain: <target triplet>-<tool name> The target triplet is of the form <machine>-<vendor>-<operatingsystem> And the tool name is gcc for the compiler, or another tool name like ld or strip or ar, etc... The default compiler, the one that ...


3

To run your program on the server, you will need to have the program installed there. You don't need administrator privileges to do this but you will need remote shell access to actually run the program. Your 4th requirement to not leave or install software on the server makes your proposition impossible. If you want to do processing on the server, you ...


3

I made it :-) I basically followed Gilles's advice and decided to do it properly: i.e. manage a complete cross-compilation of GLIBC. I started from crosstool-ng, and was initially disappointed - seeing that it didn't support my old kernel. I kept at it, though - manually editing the configuration file saved by crosstool-ng to do changes like these on the ...


2

We first have to set up the multi-arch environment (more info): sudo dpkg --add-architecture armhf sudo apt update Download the source package (using less as an example): apt-get source less Navigate to the directory and, finally, build the package: cd less-458 dpkg-buildpackage -us -uc -b --host-arch armhf The special flag in the command above is ...


2

If you care more about convenience than speed, you can use the following method, which uses qemu to emulate an ARM system. Install package that got the tool we need, pbuilder-dist: sudo apt install ubuntu-dev-tools The following command creates a chroot to build on, and creates a tarball of it (in this case a Debian 8 system for armhf architecture): ...


2

You can use binutils-x86-64-linux-gnu, available in Debian Jessie (but not Ubuntu). It contains x86_64-linux-gnu-as, so you need to configure using x86_64-linux-gnu as target.


2

I believe all you need to do is: Add the compiler binaries to your path. export $PATH=/home/tester/Misc/gnuarm/install/bin:$PATH Run configure in the Dropbear source directory with the correct options for cross-compiling. ./configure --host=arm-none-eabi Continue compilation as per the INSTALL guide. Note: If you do have any problems caused by the ...


2

The term platform includes all the details regarding the computer on which the program is compiled or/and run. This means stuff like: CPU: instruction set (x86, x86_64, ARM), endianess (big endian, littel endian) compiler: language (e.g. C90, C99, C11), vendor (GCC, LLVM) libraries, for example glibc and BSD libc, malloc and jemalloc operating system ...


2

Camera's libc does not match the libc used for the toolchain. In this case the program must be compiled statically adding -static switch. After this 'Hello world' is executable on the device. Another solution is to add all required shared libraries (I haven't tested this). People from #mipslinux irc channel helped me to solve this problem - thank you.


2

Debian now includes cross-toolchains officially, though they won't be part of the next Stable release (8.0). Virtual packages are provided.


2

I had the exact same problem and was puzzled. The clue was in the error line: configure: error: invalid feature name: libstdc++-v3 make[1]: *** [configure-gmp] Error 1 evidently the configure-gmp target (in make) was passed the feature name from the parent project. The trick is to spell it out as follows in the command line: --disable-libstdc__-v3 ...


2

Cygwin aims to maximise POSIX and Linux source compatibility, whereas MinGW provides a GNU toolchain for building native Windows application. Hopefully this means that your Linux application requires no or only minor changes to build on Cygwin, whereas porting code using POSIX/Linux-specific APIs to native Windows can be a major effort. However, if you can ...


2

As far as I know it is not possible. Please remember that toolchain does not exist in vaccum and is interlinked. What might work is to build cross-compiler of new infrastructure but I really doubt it - the "atomicity" on update of glibc will break everything. I would advice backup & reinstall of system.


2

Have you tried downloading the amd64 stage3 tarball and using the copy of gcc with that?


2

The problem is that 'valgrind' is looking for a different executable to run the real checking. It uses the install path you specified when you configured it, which is not the same path as on the target. You should be able to confirm this by creating a symlink /home/NFS_mounted on your target that points to '/'.



Only top voted, non community-wiki answers of a minimum length are eligible