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!
Related
I am trying to compile some software that contains a compile.sh shell script. When I run the script, the software fails to compile due to what it reports as a broken C compiler.
I have tried reinstalling C compilers, both within and outside of conda, to no avail.
Below, please find the output of running the compile shell script
(base) userA#server:~/SPAdes-3.13.0-dev$ ./spades_compile.sh
-- The C compiler identification is GNU 7.3.0
-- The CXX compiler identification is GNU 7.3.0
-- Check for working C compiler: /home/userA/anaconda3/bin/x86_64-conda_cos6-linux-gnu-cc
-- Check for working C compiler: /home/userA/anaconda3/bin/x86_64-conda_cos6-linux-gnu-cc -- broken
CMake Error at /home/userA/anaconda3/share/cmake-3.14/Modules/CMakeTestCCompiler.cmake:60 (message):
The C compiler
"/home/userA/anaconda3/bin/x86_64-conda_cos6-linux-gnu-cc"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /home/userA/SPAdes-3.13.0-dev/build_spades/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/make cmTC_708f4/fast
/usr/bin/make -f CMakeFiles/cmTC_708f4.dir/build.make CMakeFiles/cmTC_708f4.dir/build
make[1]: Entering directory '/home/userA/SPAdes-3.13.0-dev/build_spades/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_708f4.dir/testCCompiler.c.o
/home/userA/anaconda3/bin/x86_64-conda_cos6-linux-gnu-cc -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -o CMakeFiles/cmTC_708f4.dir/testCCompiler.c.o -c /home/userA/SPAdes-3.13.0-dev/build_spades/CMakeFiles/CMakeTmp/testCCompiler.c
Linking C executable cmTC_708f4
/home/userA/anaconda3/bin/cmake -E cmake_link_script CMakeFiles/cmTC_708f4.dir/link.txt --verbose=1
/home/userA/anaconda3/bin/x86_64-conda_cos6-linux-gnu-cc -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,--disable-new-dtags -Wl,--gc-sections -rdynamic CMakeFiles/cmTC_708f4.dir/testCCompiler.c.o -o cmTC_708f4
/home/userA/anaconda3/bin/x86_64-conda_cos6-linux-gnu-ld: cannot find crtbeginS.o: No such file or directory
/home/userA/anaconda3/bin/x86_64-conda_cos6-linux-gnu-ld: cannot find -lgcc
/home/userA/anaconda3/bin/x86_64-conda_cos6-linux-gnu-ld: cannot find -lgcc
collect2: error: ld returned 1 exit status
CMakeFiles/cmTC_708f4.dir/build.make:86: recipe for target 'cmTC_708f4' failed
make[1]: *** [cmTC_708f4] Error 1
make[1]: Leaving directory '/home/userA/SPAdes-3.13.0-dev/build_spades/CMakeFiles/CMakeTmp'
Makefile:121: recipe for target 'cmTC_708f4/fast' failed
make: *** [cmTC_708f4/fast] Error 2
CMake will not be able to correctly generate this project.
Expected result: properly compiled software
Actual result: report of a broken C compiler
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.
I am getting this error when building wxWidgets in Cygwin:
../src/generic/dirctrlg.cpp:67:24: fatal error: direct.h: No such file or directory
compilation terminated.
make: *** [corelib_dirctrlg.o] Error 1
T_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -I/cygdrive/c/wxWidgets-2.8.12/build-debug/lib/wx/include/msw-ansi-debug-static-2.8 -I../include -Wall -Wundef -Wno-ctor-dtor-privacy -ggdb -O0 ../src/generic/dirctrlg.cpp
Makefile:28340: recipe for target `corelib_dirctrlg.o' failed
I followed the instructions included in wxWidgets for Windows using configure in install.txt(Compiling wxWidgets).
Which compiler do you use? See http://wxwidgets.blogspot.com/2011/06/choosing-gcc-for-building-wxwidgets.html for some of the choices you have. FWIW direct.h should be present in MinGW compiler headers.
We have a large Carbon based (PowerPlant) application that we are looking finally to port over to Cocoa. We will be doing this incrementally and a first step is to try to get a Cocoa view into a Carbon window.
The problem seems to be that when I use any of the functions from HICocoaView.h the application will not compile unless I switch the compiler from GCC 4.2 to GCC 4.0.
Using any compiler other than GCC 4.0 I get an error in XCode that the functions are unavailable e.g. "HICocoaViewCreate is unavailable".
I can't figure out why this won't work, will we have to switch to the older compiler or is there some setting we can change to get it to compile?
Any help or pointers to useful documentation on porting Carbon to Cocoa greatly appreciated. I've read through the old Carbon Cocoa Integration guide but it doesn't mention this.
Edit: As requested here's the output from the build for the gcc command line:-
/Developer/usr/bin/gcc-4.2 -x objective-c++ -arch i386
-fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -Wmissing-prototypes -Wreturn-type -Wunused-variable -Wunused-value -D__IMPRO_DEBUG_BUILD__ -isysroot /Developer/SDKs/MacOSX10.5.sdk -mfix-and-continue
-mmacosx-version-min=10.5 -gdwarf-2 "-I/Users/matt/Code/MattsFeatureBranch/Modules/User
Notes/Mac/../../../(Intermediates)/Debug/User Notes.build/Debug/Module
Bundle.build/User Notes.hmap" -Wparentheses -Wno-conversion
-Wno-sign-compare -Wno-multichar -Wno-deprecated-declarations "-F/Users/matt/Code/MattsFeatureBranch/Modules/User
Notes/Mac/../../../Build Products/Mac/Debug/Plugins" "-F../../../Build
Products/Mac/Debug" "-F../../../Third Party/Mac/NVidia"
"-I/Users/matt/Code/MattsFeatureBranch/Modules/User
Notes/Mac/../../../Build Products/Mac/Debug/Plugins/include"
-I../X-Platform -I../../../Common/Mac -I../../../Common/X-Platform -I../../../DLLs/ArcadiaCore/Mac -I../../../DLLs/ArcadiaCore/X-Platform "-I../../../Third Party/Mac/Powerplant"
-I/Developer/SDKs/MacOSX10.5.sdk/Developer/Headers/FlatCarbon "-I../../../Third Party/X-Platform/boost_1_38_0"
-I../../../DLLs/ArcadiaImaging/Mac -I../../../DLLs/ArcadiaImaging/X-Platform -I../../../DLLs/ArcadiaDatabase/Mac -I../../../DLLs/ArcadiaDatabase/X-Platform -I../../../DLLs/ArcadiaUI/Mac -I../../../DLLs/ArcadiaUI/X-Platform "-I../../../Third Party/Mac/Powerplant Extras"
-I../../../DLLs/ArcadiaDevices/Mac -I../../../DLLs/ArcadiaDevices/X-Platform -I../../../DLLs/Arcadia3D/Mac -I../../../DLLs/Arcadia3D/X-Platform "-I/Users/matt/Code/MattsFeatureBranch/Modules/User
Notes/Mac/../../../(Intermediates)/Debug/User Notes.build/Debug/Module
Bundle.build/DerivedSources/i386"
"-I/Users/matt/Code/MattsFeatureBranch/Modules/User
Notes/Mac/../../../(Intermediates)/Debug/User Notes.build/Debug/Module
Bundle.build/DerivedSources" -fpermissive -fasm-blocks -include
"/Users/matt/Code/MattsFeatureBranch/Modules/User
Notes/Mac/../../../(Intermediates)/Debug/SharedPrecompiledHeaders/XPrefix-acshmfbgvfwrdqbyayvgnckkypgr/XPrefix.h"
-c "/Users/matt/Code/MattsFeatureBranch/Modules/User Notes/Mac/MUserNotesView.cpp" -o
"/Users/matt/Code/MattsFeatureBranch/Modules/User
Notes/Mac/../../../(Intermediates)/Debug/User Notes.build/Debug/Module
Bundle.build/Objects-normal/i386/MUserNotesView.o"
From HICocoaView.h in both the 10.5 and the 10.6 SDK:
#if !__LP64__
extern OSStatus
HICocoaViewCreate(
NSView * inNSView, /* can be NULL */
OptionBits inOptions,
HIViewRef * outHIView) AVAILABLE_MAC_OS_X_VERSION_10_5_AND_LATER;
…
#endif /* !__LP64__ */
This means that HICocoaViewCreate() is not available on 64-bit (LP64) targets, i.e., if you need to use this function you have to target i386 (or PowerPC).
GCC 4.0 targets i386 by default even when run on 64-bit capable machines. On the other hand, GCC 4.2 targets x86_64 by default on 64-bit machines:
$ gcc-4.0 a.c; lipo -info a.out
Non-fat file: a.out is architecture: i386
$ gcc-4.2 a.c; lipo -info a.out
Non-fat file: a.out is architecture: x86_64
If you want to use both HICocoaViewCreate() and GCC 4.2, tell it to create (and use) 32-bit objects/binaries by passing -arch i386. For instance,
$ gcc-4.2 a.c -arch i386; lipo -info a.out
Non-fat file: a.out is architecture: i386
Even though part of Carbon is available for 64-bit targets, you’ll notice in the 64-bit Guide for Carbon Developers that much of HIToolbox simply isn’t available.
As for migrating from Carbon to Cocoa, it’s a whole new Objective-C API for the most part. I’m not aware of any simple migration guide, and Peter Hosey’s answer to a similar question on Stack Overflow is worth reading.
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