Trying to compile x264 on Synology DiskStation with PowerPC - powerpc

I'm trying to compile x264 on a Synology NAS (DS413) with powerpc cpu (e500v).
However, when I try to run the configure - script, the following error occurs (in the config.log):
checking whether gcc works... no
Failed commandline was:
--------------------------------------------------
gcc conftest.c -Wall -I. -I$(SRCPATH) -maltivec -mabi=altivec -lm -o conftest
conftest.c:1: error: AltiVec and E500 instructions cannot coexist
--------------------------------------------------
Failed program was:
--------------------------------------------------
int main (void) { return 0; }
--------------------------------------------------
DIED: No working C compiler found.
I'm 100% certain that gcc is installed and that it works. I've googled the error and it seems that this was a bug in the configure script which should have been fixed already:
link. It has something to do with altivec not present in the ppc hardware or something. The script should recognise this, but unfortunately it doesn't recognize it in my case. The x264 I tried to compile is the most recent one (cloned directly from github).
The error shows up regardless of which configuration-flags I set (I tried different ones, e.g. --prefix=/opt --enable-shared --disable-asm). I also tried to modify the configuration script with sed, i.e. changing this line:
CFLAGS="$CFLAGS -maltivec -mabi=altivec"
to simply:
CFLAGS="$CFLAGS"
but then I get this error:
checking whether gcc works... no
Failed commandline was:
--------------------------------------------------
gcc conftest.c -Wall -I. -I$(SRCPATH) -lm -o conftest
/opt/lib/gcc/powerpc-linux-gnuspe/3.4.6/../../../../powerpc-linux-gnuspe/lib/li$
/opt/lib/gcc/powerpc-linux-gnuspe/3.4.6/../../../../powerpc-linux-gnuspe/lib/li$
/opt/lib/gcc/powerpc-linux-gnuspe/3.4.6/../../../../powerpc-linux-gnuspe/lib/li$
/opt/lib/gcc/powerpc-linux-gnuspe/3.4.6/../../../../powerpc-linux-gnuspe/lib/li$
/opt/lib/gcc/powerpc-linux-gnuspe/3.4.6/../../../../powerpc-linux-gnuspe/lib/li$
/opt/lib/gcc/powerpc-linux-gnuspe/3.4.6/../../../../powerpc-linux-gnuspe/lib/li$
collect2: ld returned 1 exit status
--------------------------------------------------
Failed program was:
--------------------------------------------------
int main (void) { return 0; }
--------------------------------------------------
DIED: No working C compiler found.
Any help on how to compile it would be greatly appreciated!

Related

undefined reference to `WinMain` while compiling my own kernel

I've started writing my very own kernel and am developing on Windows 10.
I am using the following tools:
gcc 8.1.0 elf x86_64 for compiling my C code, and for linking.
I am using this Windows package.
nasm 2.14.02 for compiling my assembly code.
I am using the following command to build my freestanding kernel code:
gcc -c -m64 common/src/kernel.c -o common/build/kernel.o -std=gnu99 -ffreestanding -O2 -Wall -Wextra`
I am using the following command for compiling the root assembly code:
nasm -f elf64 targets/x86_64/src/main.asm -o targets/x86_64/build/main.o
Finally I link the object files together:
gcc -o dist/x86_64/main.bin -ffreestanding -O2 targets/x86_64/build/main.o common/build/kernel.o -lgcc
I haven't a clue why, but the following error is stopping the linking process from working:
... undefined reference to `WinMain'
collect2.exe: error: ld returned 1 exit status
This doesn't make sense to me because my compilation and linking is in freestanding mode and I am not attempting to use any windows APIs.
How do I fix this?
If it matters, here is my very simple code:
main.asm:
EXTERN kernel_main
call kernel_main
jmp $
; padding and magic number
times 510-($-$$) db 0
dw 0xaa55
kernel.c:
void kernel_main()
{
// empty
}
Edit: It looks like I might need the x86_64-elf-gcc compiler
Edit 2: I tried the x86_64-w64-mingw32-gcc compiler, same error occurs
I was missing the -nostdlib flag on the linker. This seems to have solved the problem.

g++ compiling error: /bin/ld: Invalid BFD target 'maxdata:0x80000000'

We are migrating some very simple C++ programs from AIX Server to Linux. The code is compiling fine on AIX server.
I tried to compile the C++ code in the Linux server. But the command line below failed:
g++ map2key.cpp -o map2key -nodefaultlibs -lstdc++ -lm -lgcc_s -lc -Xlinker -bmaxdata:0x8000000
With the error message:
/bin/ld: invalid BFD target `maxdata:0x80000000'
collect2: error: ld returned 1 exit status
The C++ program should be compiled and executable file should be generated
If you can help, I would very much appreciate it.

Problem cross-compiling trivial example with gcc when using hard float

When I try to compile a trivial example test.c
int main () {
return 0;
}
for a cortex m7 target with hard float ABI by using the following invocation
arm-none-eabi-gcc -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard --specs=nosys.specs test.c
I get this error:
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: error: /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/crt0.o: Conflicting CPU architectures 13/1
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: failed to merge target specific data of file /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/crt0.o
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: error: a.out uses VFP register arguments, /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/libc.a(lib_a-atexit.o) does not
[snip]
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: failed to merge target specific data of file /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/libnosys.a(_exit.o)
collect2: error: ld returned 1 exit status
So the issue is that gcc is linking to the wrong libc.a. If I use the argument print-multi-directory, it would appear that my version of arm-none-eabi-gcc should support this architecture:
$ arm-none-eabi-gcc -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard --specs=nosys.specs --print-multi-directory
thumb/v7e-m/fpv5/hard
And I can list the different versions of libc.a that are provided by arm-none-eabi-gcc:
$ find /usr/lib/arm-none-eabi/ -name libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/fpu/fpv5-sp-d16/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/fpu/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/fpu/fpv5-d16/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/softfp/fpv5-sp-d16/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/softfp/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/softfp/fpv5-d16/libc.a
/usr/lib/arm-none-eabi/newlib/libc.a
/usr/lib/arm-none-eabi/newlib/armv6-m/libc.a
/usr/lib/arm-none-eabi/newlib/fpu/libc.a
/usr/lib/arm-none-eabi/newlib/thumb/libc.a
/usr/lib/arm-none-eabi/newlib/armv7-m/libc.a
So it looks like there is a version of libc.a compiled for my desired architecture, but gcc isn't linking against it. How can I get gcc to link against the correct version of libc.a?
I'm using arm-none-eabi-gcc version 6.3.1 provided by the gcc-arm-none-eabi package for Ubuntu 18.04.

Error while building Tor on arm system

I'm trying to build Tor from source on my NAS (Synology DS213j).
./configure fails with this error (snippet of config.log):
configure:4097: checking whether the C compiler works
configure:4119: gcc -mfloat-abi=hard -mfpu=vfpv3-d16 -I${top_srcdir}/src/common -mfloat-abi=hard -mfpu=vfpv3-d16 conftest.c >&5
conftest.c:1: sorry, unimplemented: -mfloat-abi=hard and VFP
If I try to build without -mfloat-abi=hard then I get
configure:4097: checking whether the C compiler works
configure:4119: gcc -I${top_srcdir}/src/common conftest.c >&5
/opt/lib/gcc/arm-none-linux-gnueabi/4.2.3/../../../../arm-none-linux-gnueabi/bin/ld: ERROR: /lib/libc.so.6 uses VFP register arguments, a.out does not
/opt/lib/gcc/arm-none-linux-gnueabi/4.2.3/../../../../arm-none-linux-gnueabi/bin/ld: failed to merge target specific data of file /lib/libc.so.6
My guess is that vfp is needed to compile, but my compiler chokes on it for some reason, although the processor (Marvell Armada 370) should support it.
So how do I get VFP into my compiler?
Thanks for your help!

Compiling C code for 64-bit Matlab on Intel MAC

I need compile a piece of C code to be called from matlab (mex compiling).
I am doing that on an intel mac and, since I am using Matlab's R2010a (7.10.0.499), I'd like to compile the C code into a version for 64-bits.
For whatever reason, just doing mex with the -arch=maci64 option did not seem to work...
As a way around, I am compiling the C code to a mexmaci64 file directly on the command line.
I used the gcc calls made by mex (with the -v option on) as a starting point.
I managed to compile the C code to an object file, but it looks like I am not compiling the C code to the correct architecture.
Does anyone know how to correct the gcc calls below so the C code gets compiled to 64-bits intel macs?
Details are listed below.
As always, any help greatly appreciated...
Keep thirsty, my friends. :p
G
DETAILS:
Here is how I did the compilation and linking:
gcc -c -I/Applications/MATLAB_R2010a.app/extern/include -DMATLAB_MEX_FILE -fno-common -no-cpp-precomp -fexceptions -D MACVERSION -DMX_COMPAT_32 -O3 -DNDEBUG "BoxQP.c"
gcc -O -bundle -Wl,-flat_namespace -undefined suppress -Wl,-exported_symbols_list,/Applications/MATLAB_R2010a.app/extern/lib/maci64/mexFunction.map -o "BoxQP.mexmaci64" BoxQP.o -L/Applications/MATLAB_R2010a.app/bin/maci64 -lmx -lmex -lmat -lstdc++
Here are the warnings I get:
ld warning: in /Applications/MATLAB_R2010a.app/bin/maci64/libmx.dylib, file is not of required architecture
ld warning: in /Applications/MATLAB_R2010a.app/bin/maci64/libmex.dylib, file is not of required architecture
ld warning: in /Applications/MATLAB_R2010a.app/bin/maci64/libmat.dylib, file is not of required architecture
Ignoring the warnings and calling the BoxQP function from matlab results in the following error message:
??? Invalid MEX-file '/Users/gvrocha/Documents/academic/projects/splice/code/matlab/covsel/BoxQP.mexmaci64':
dlopen(/Users/gvrocha/Documents/academic/projects/splice/code/matlab/covsel/BoxQP.mexmaci64, 1): no suitable image found.
Did find: /Users/gvrocha/Documents/academic/projects/splice/code/matlab/covsel/BoxQP.mexmaci64: mach-o, but wrong architecture.
PS: I tried changing the -DMX_COMPAT_32 flag to -DMX_COMPAT_64 but I do get the same warnings and same error...
PPS: I guess it may be relevant to mention that I am using Mac OS X 10.5.8 (the "tropical"/plain-vanilla Leopard, i.e., not the snow Leopard).
PPPS: The same happens with the yprime.c example provided by MATLAB

Resources