I installed Cygwin 64-bit 2.831 on Windows 8 and I installed the built-in OpenMPI 1.7.4-1 packages.
Now whenever I invoke any OpemMPI program (e.g. mpirun, mpicc, mpic++, ompi_info), it immediately terminates without any output. It doesn't even report problems in the command line arguments. Any solution or explanation is much appreciated.
Thank you
UPDATE: Apparently, it is a 64-bit issue; mpic++ seems to work on 32-bit Cygwin.
Running gdb mpic++ on 64-bit Cygwin gives the following output:
Starting program: /usr/bin/opal_wrapper
[New Thread 3544.0x6f8]
warning: `/cygdrive/c/Windows/SYSTEM32/wow64.dll': Shared library architecture i386:x86- 64 is not compatible with target architecture i386.
warning: `/cygdrive/c/Windows/system32/wow64win.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
warning: `/cygdrive/c/Windows/system32/wow64cpu.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
dll path too long
dll path too long
dll path too long
dll path too long
warning: `/usr/bin/cygwin1.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
warning: `/usr/bin/cygwin1.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
[Inferior 1 (process 3544) exited with code 030000000173]
Running strace mpic++ gives:
strace.exe: error creating process mpic++, (error 2)
Related
I need to build a complete linux development framework for a Cortex-M MCU, specifically a STM32F7 Cortex-M7. First I've to explain some background info so please bear with me.
I've downloaded and built a gcc toolchain with croostool-ng 1.24 specifying an armv7e-m architecture with thumb-only instructions and linux 4.20 as the OS and that I want the output to be FLAT executables (I assumed it will mean bFLT).
Then I proceeded to compile the linux kernel (version 4.20) using configs/stm32_defconf, and then a statically compiled busybox rootfs, all using my new toolchain.
Kernel booted just fine but throw me an error and kernel painc with the following message:
Starting init: /sbin/init exists but couldn't execute it (error -8)
and
request_module: modprobe binfmt-464c cannot be processed, kmod busy with 50 threads
The interesting part is the last message. My busybox excutable turned out to be an .ELF! Cortex-M has no MMU, so it's imposible to build a linux kernel on a MMU-less architecture with .ELF support, that's why an (464c)"LF" binary loader can't be found, there is none.
So at last, my question is:
how could I build bFLT executables to run on MMU-less Linux architectures? My toolchain has elf2flt, but in crosstool-ng I've already specified a MMU-less architecture and FLAT binary and I was expecting direct bFLT output, not a "useless" executable. Is that even possible?
Or better: is there anywhere a documented standard procedure to build a complete, working Linux system based on Cortex-M?
Follow-up:
I gave up on building FLAT binaries and tried FDPIC executables. Another dead end. AFAIK:
Linux has long been supporting ELF FDPIC, but the ABI for ARM is pretty new.
It seems that still at this day and age, GCC has not a standard way to enable FDPIC. On some architectures you can use -mfdpic. Not on arm, don't know why. I even don't know if ARM FDPIC is supported at all by mainline GCC. Info is extremely scarce if inexistent.
It seems crosstool-ng 1.24 is BROKEN at building ARM ELF FDPIC support. Resulting gcc has not -mfdpic, and -fPIC generates ARM executables, not ARM FDPIC.
Any insight will be very appreciated.
you can generate FDPIC ELF files just with a prebuilt arm-linux-gnueabi-gcc compiler.
Specifications of an FDPIC ELF file:
Position independent executable/code (i.e. -fPIE and fPIC)
Should be compiled as a shared executable (ET_DYN ELF) to be position independent
use these flags to compile your programs:
arm-linux-gnueabi-gcc -shared -fPIE -fPIC <YOUR PROGRAM.C> -o <OUTPUT FILE>
I've compiled busybox successfully for STM32H7 with this method.
As I know, unfortunately FDPIC ELFs should be compiled with - shared flag so, they use shared libraries and cannot be compiled as -static ELF.
For more information take a look at this file:
https://github.com/torvalds/linux/blob/master/fs/binfmt_elf_fdpic.c
Track the crosstool-ng BFLAT issue from here:
https://github.com/crosstool-ng/crosstool-ng/issues/1399
Can someone explain the difference between the three architectures?
Actually when I built a 64-bit application in Linux, I got a link error saying:
skipping incompatible library.a when searching for library.a
Then I used objdump -f on that library and I got the below output:
a.o: file format elf32-x86-64
architecture: i386:x64-32, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000
Does it mean the library is 32-bit? Is that the reason I am getting the linker error?
There are 3 common ABIs usable on standard Intel-compatible machines (not Itanium).
The classic 32-bit architecture, often called "x86" for short, which has triples like i[3-6]86-linux-gnu. Registers and pointers are both 32 bits.
The 64-bit extension originally from AMD, often called "amd64" for short, which has GNU triple of x86_64-linux-gnu. Registers and pointers are both 64 bits.
The new "x32" ABI, with a triple of x86_64-linux-gnux32. Registers are 64 bits, but pointers are only 32 bits, saving a lot of memory in pointer-heavy workflows. It also ensures all the other 64-bit only processor features are available.
Each of the above has its on system call interface, own ld.so, own complete set of libraries, etc. But it is possible to run all 3 on the same kernel.
On Linux, their loaders are:
% objdump -f /lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2 /libx32/ld-linux-x32.so.2
/lib/ld-linux.so.2: file format elf32-i386
architecture: i386, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x00000a90
/lib64/ld-linux-x86-64.so.2: file format elf64-x86-64
architecture: i386:x86-64, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x0000000000000c90
/libx32/ld-linux-x32.so.2: file format elf32-x86-64
architecture: i386:x64-32, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x00000960
Now, if you're getting the message about "skipping incompatible library", that means something is messed up with your configuration. Make sure you don't have bad variables in the environment or passed on the command line, or files installed outside of your package manager's control.
Beyond usual full 64bit and good old 32bit ABI there is a special ABI (inspired by SGI n32 envirnment) where pointers are 32bit (thus they are 32bit apps), but it is designed to run on 64bit host and have full access to all x64 goodies:
native x64 registers and math
more registers
SSE2/3/4, AVX1/2/...
Full 4Gb address space on 64bit host
It is called x32 ABI, link: https://en.wikipedia.org/wiki/X32_ABI
UPDATE
On Ubuntu system I have to install two packages (with deps) to get x32 working:
> sudo apt install gcc-multilib
> sudo apt install libx32stdc++-5-dev
Then compiling simlple C++ code with g++ -mx32 hellow.cpp works, making x32 executable
> file a.out
./a.out: ELF 32-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /libx32/ld-linux-x32.so.2, for GNU/Linux 3.4.0
I am recently doing some experiment on building a cluster system for computing tasks. My server is Suse Linux Enterprise 11, and one of the client is Redhat Enterprise Linux 5. I compiled openmpi on Suse, and it runs fine alone. Then I shared /usr/local(where the openmpi was installed) to my Redhat client, and tried to do mpirun, the following error popped up: error while loading shared libraries: /usr/local/openmpi/lib/libopen-rte.so.0: ELF file OS ABI invalid. Does this mean that I have to compile openmpi on redhat separately? Thanks!
I'm trying to follow a tutorial for the Diagrams library for haskell.
I've installed Cairo and gtk2hs with macports.
But when I try to run the tutorial examples, I get the following error:
$ ghc --make diagramsTutorial.lhs
Linking diagramsTutorial ...
ld: warning: in /opt/local/lib/libgtk-x11-2.0.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /opt/local/lib/libgdk-x11-2.0.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /opt/local/lib/libatk-1.0.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /opt/local/lib/libpangocairo-1.0.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
.. etc...
I'm using OS X 10.6.8, core i5 macbook pro.
EDIT I have just found that I'm using the 32bit haskell platform, which may be part of the problem. However I can't install the 64 bit version (it has an unspecified error during install). I can't find the uninstaller. According to this page, I should find an uninstaller at /Library/Frameworks/GHC.framework/Tools/Uninstaller but there is nothing there.
It looks like the Macports libraries are 64-bit only. You can check with lipo -info /opt/local/lib/libgtk-x11-2.0.dylib If this is the case, you should reinstall them using the +universal variant, which will allow for linking both 32bit and 64bit code.
Let me explain.
I'm using webots in combination with aldebaran SDK. My operating system is Debian Squeeze amd64. Webots (64bit) will not work with aldebaran SDK because their libraries are compiled for 32bit. I do not have the source of the libs to recompile in 64bit.
While trying to compile the default nao controller under webots, i get the following error:
g++ -o naoqi_for_webots
naoqi_for_webots.o naoproxy.o
-L"/usr/local/webots/lib" -lController -L"/home/alex/naoqi-sdk-1.10.44-linux/lib"
-lnaoqiclient /usr/bin/ld: skipping incompatible
/home/vor73x/naoqi-sdk-1.10.44-linux/lib/libnaoqiclient.so
when searching for -lnaoqiclient
/usr/bin/ld: cannot find -lnaoqiclient
doing a
file libnaqoqiclient.so
tells me:
libnaoqiclient.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
The default project in webots has a Makefile which among other things has:
additional libraries:
LIBRARIES=-L"$(AL_DIR)/lib" -lnaoqiclient
I have downloaded and installed the 32bit version of webots, which links fine with the libnaoqiclient.so but will not link with other webots libraries (libController.so) where again, ld complains about incompatible type.
Can I link using webots 64bit with the 32bit aldebaran sdk ?
Can I link using webots 32bit with the 32bit aldebaran ? (I should, but I still get errors).
How can I specify to ld (or through Makefile even better) that the library is 32bits ?
Or in the case of using webots 32bit how can I specify that I want a 32bit binary ?
I do not care if my binary is 32 or 64bit, I do not care if I use the 32 or 64bit version of webots, all I want is to be able to compile the controllers.
Well, you can't mix and match 32-bit and 64-bit code. If you compile all your code using -m32 (to make it build as 32-bit), you may be able to get your application to link if you have 32-bit versions of all your libraries available.