Tag Info

Hot answers tagged

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.


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

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

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 ...


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

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

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

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, ...


2

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


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

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 '/'.


2

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 ...


2

You can copy libraries to your embedded device provided that it's running the same operating system on the same processor architecture family. Your device has an x86 processor, which is the same family as 32-bit PCs. So if you have a 32-bit Linux system on your desktop machine, you can copy libraries and executables from your desktop machine to your device. ...


2

In order to cross compile, you must have (or build) a cross-compiler; gcc cannot, by default, just build for any target that it could be configured for. There is a list of possibilities in the gcc source package, I believe. Building a cross compiler toolchain is not a simple undertaking, so if you want to do that, you have to decide what it's for and ask ...


2

It's perfectly normal for certain processes to create other copies of themselves after execution, usually to improve performance through parallel execution. As for how it works, the process fork(2)'s (it may or may not also exec(2) another copy of itself, depending on the way it is implemented). See man 2 fork and man 2 exec. Essentially, new processes in ...


2

You haven't passed the right options to Configure. Make sure to pass the argument linux-armv4. If you're cross-compiling, in addition to armv4, you need to pass the path to the cross-compiler, as well as include and library paths if necessary. ./Configure --cross-compiler-prefix=/opt/gcc-arm/bin/arm-linux-gnueabi- -I/opt/gcc-arm/include -L/opt/gcc-arm/lib


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

The error message shows that you want to compile code for your platform (x86/64) with the ARM compiler which does not work. The configure script has not guessed the correct target ("TCC_TARGET_X86_64" instead of the ARM target). Probably, you need the --cpu=armv7a (or what you exactly have) option and/or the --cross-prefix=arm-none-linux-gnueabi- option. ...


2

You should not deduce, you must know and choose the one you need, if you needed compatibility with an old 486 or the best performance with your 686. The missing headers are just a different issue.


2

This appears to me to be a bug in align.c 2.6.39 and previous with respect to GCC >= 4.6. I am guessing that you are building on a recent Fedora that has GCC 4.6 as the default installed GCC. The bug should not appear using GCC < 4.6 IMHO. The variable "instruction" is declared on line 704 and initialized to zero. It is then re-assigned on line 746. This ...


2

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 ...


2

From what I can gather, you have x86 compiled libncursesw5 on the x86 machine and ARM compiled libncursesw5 on the Rpi. What you need is ARM compiled libncursesw5 on the x86 machine. When you perform the ./configure command the step you encounter the error on is compiling a small program to link with libncursesw5 to test for its existence. You ARM cross ...


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

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

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

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 ...



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