I recently switched from Windows to mac and bravely took the new MacBook with macOS BigSur and M1 chip. I'm trying to install BPP (https://github.com/bpp/bpp) following the program's installation guide, but run into problems when trying to compile an executable file.
git clone https://github.com/bpp/bpp.git
cd bpp/src
make
This gave multiple errors like this:
cc -D_GNU_SOURCE -DHAVE_SSE3 -DHAVE_AVX -DHAVE_AVX2 -g -msse3 -O3 -Wall -Wsign-compare -c -o bpp.o bpp.c
clang: warning: argument unused during compilation: '-msse3' [-Wunused-command-line-argument]
In file included from bpp.c:22:
In file included from ./bpp.h:43:
In file included from /Library/Developer/CommandLineTools/usr/lib/clang/12.0.0/include/x86intrin.h:15:
In file included from /Library/Developer/CommandLineTools/usr/lib/clang/12.0.0/include/immintrin.h:14:
Library/Developer/CommandLineTools/usr/lib/clang/12.0.0/include/mmintrin.h:373:12: error:
invalid conversion between vector type '__m64' (vector of 1 'long long'
value) and integer type 'int' of different size
return (__m64)__builtin_ia32_paddw((__v4hi)__m1, (__v4hi)__m2);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So I thought maybe the problem is that the default compiler is Clang 12 and after installing gcc-11 (which should be appropriate for M1) run:
make CC=/opt/homebrew/bin/gcc-11
But it gave an error too:
gcc-11: error: unrecognized command-line option '-msse3'
make: *** [bpp.o] Error 1
Since I'm not an experienced coder and with M1 being so new that finding solutions from forums is not simple, I'm kind of in a dead end. Any suggestions how to work through this problem?
I guess it is due to the fact that SSE3 is an x86 feature?
Related
On recent Big Sur 11.3, when compiling a simple source like this :
g++-10 -c -Wall -c -I/usr/local/include -I/usr/local/include/c++/10.2.0 main_gnu.cpp
I get the following error :
clang: error: invalid version number in '-mmacosx-version-min=11.0'
This looks like to the same issue than in '-mmacosx-version-min=11.2'
I removed CLT (CommandLineTools) and reinstall it, same error.
I don't want to install Xcode since up to now, I always worked only with CLT to compile.
I have also tried : export SYSTEM_VERSION_COMPAT=1
I have the following installation :
I have also tried to make the link : MacOSX.sdk -> MacOSX10.15.sdk, without success.
I don't understand why clang is called and where this flag comes from, I just compile with brew g++-10.
What might have happened here?
I'm triing to compile the superoptimizer on windows. (https://github.com/bonzini/superopt)
Unfortunatly my knowledge of make is very limited. I tried:
make CPU=-D386 superopt
Which gives me the error:
cc superopt.c -o superopt
process_begin: CreateProcess(NULL, cc superopt.c -o superopt, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [superopt] Fehler 2
After setting the compiler to gcc manually with:
make CPU=-D386 superopt CC=gcc
I get the following error:
gcc superopt.c -o superopt
In file included from superopt.c:27:0:
superopt.h:104:2: error: #error You have to choose target CPU type (--with-arch).
#error You have to choose target CPU type (--with-arch).
^
In file included from superopt.h:130:0,
from superopt.c:27:
longlong.h:1465:14: error: unknown type name 'UQItype'
extern const UQItype __clz_tab[];
^
superopt.c:32:21: fatal error: version.h: No such file or directory
compilation terminated.
make: *** [superopt] Fehler 1
It seems it does't properly selects i386.
Any hints would be greatly appreciated.
That is not the source code of
GNU superopt. It is the source code of someone's project
to patch GNU superopt, last updated 2008, and seemingly
abandoned a hard-hat area.
This is the source code of
GNU superopt. Extract the tarball and build as you have attempted
with:
make CC=gcc CPU=-DI386 superopt
Note: I386, not 386.
You will see warnings like:
warning: incompatible implicit declaration of built-in function 'foo'
because the 20 yearold C code does not diligently include the standard
headers that prototype the standard functions that it calls, but superopt will build successfully.
I’m trying to develop some plotting apps for Windows platform. I’m using Debian and built wxWidgets for cross-compiling as described here.
With MinGW compiler it works perfect and I have no problem with creating Win32 apps under Linux. But I faced some troubles with wxFreeChart.
I run ./configure --host=i386-mingw32 --with-wx-config=/usr/local/i586-mingw32/bin/wx-config
Then I run 'make' and getting error about
unrecognized command line option ‘-mthreads
Full output here:
~/dev/freechart/bk-deps g++ -c -o wxfreechart_lib_legend.o -I./include -I/usr/local/i586-mingw32/lib/wx/include/i586-mingw32msvc-msw-unicode-static-3.0 -I/usr/local/i586-mingw32/include/wx-3.0 -D_LARGEFILE_SOURCE=unknown -D__WXMSW__ -mthreads -O2 ./src/legend.cpp
g++: error: unrecognized command line option ‘-mthreads’
make: *** [wxfreechart_lib_legend.o] Error 1
The only advice I've seen was to remove '-mthreads' from code, but I have no idea where is it(
Problem described above is solved, but still no luck with building wxFreeChart.
Next errors I get were about some additional libs, which I finally solved by
CPPFLAGS="-I/usr/i586-mingw32msvc/include -I~/dev/wxWidgets-3.0.2/include" ./configure --host=i386-mingw32 --with-wx-config=/usr/local/i586-mingw32/bin/wx-config
I'm not sure that including .h from source folder ~/dev/wxWidgets is a good idea, but at least it solved some problems.
Now make crashing with messages like:
In file included from /usr/local/i586-mingw32/include/wx-3.0/wx/wx.h:17:0,
from ./include/wx/wxfreechartdefs.h:20,
from ./include/wx/legend.h:13,
from ./src/legend.cpp:10:
/usr/local/i586-mingw32/include/wx-3.0/wx/list.h: In constructor ‘wxListKey::wxListKey(const wxString&)’:
/usr/local/i586-mingw32/include/wx-3.0/wx/list.h:381:40: error: invalid use of incomplete type ‘class wxString’
or
/usr/local/i586-mingw32/include/wx-3.0/wx/containr.h:247:13: error: incomplete type ‘wxNavigationEnabled<wxControl>::BaseWindowClass {aka wxControl}’ used in nested name specifier
make: *** [wxfreechart_lib_legend.o] Error 1
I have followed the instruction on the "GMP Install Instruction for Windows Platform". I could build a 32bit version of GMP which can be used for Visual Studio.
./configure --prefix=${gmp-install} --disable-static --enable-shared
make
make install
Then I installed mingw_w64 and msys on another machine (which is running 64bit Windows) and rerun the commands.
./configure was run without any problem. However, when I run "make", I got the following.
m4 -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_add_n -DDLL_EXPORT -DPIC add_n.asm >tmp-add_n.s
gcc -std=gnu99 -c -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_add_n -O2 -pedantic -fomit-frame-pointer -mno-cygwin tmp-add_n.s -DDLL_EXPORT -DPIC -o .libs/add_n.o
tmp-add_n.s: Assembler messages:
tmp-add_n.s:84: Error: operand type mismatch for `push'
tmp-add_n.s:85: Error: operand type mismatch for `push'
tmp-add_n.s:86: Error: operand type mismatch for `push'
tmp-add_n.s:107: Error: operand type mismatch for `jmp'
tmp-add_n.s:114: Error: operand type mismatch for `pop'
tmp-add_n.s:115: Error: operand type mismatch for `pop'
tmp-add_n.s:116: Error: operand type mismatch for `pop'
make[2]: *** [add_n.lo] Error 1
make[2]: Leaving directory `/d/Temp/gmp-5.0.1/mpn'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/d/Temp/gmp-5.0.1'
make: *** [all] Error 2
If I used "gmake" instead, the following error was shown.
m4 gcc -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_add_n -DDLL_EXPORT -DPIC add_n.asm >tmp-add_n.s
m4: gcc: No such file or directory
gmake[2]: *** [add_n.lo] Error 1
gmake[2]: Leaving directory `d:/Temp/gmp-5.0.1/mpn'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `d:/Temp/gmp-5.0.1'
gmake: *** [all] Error 2
I am not familiar with C++ make. Do I need to specify any flag in order to notify mingw_w64 that I am building for 64bit? Thanks.
For me, gmp was successfully built for x86, and I have had problems building x64. The problem was in the following:
In mpn\fib_table.c:
#if GMP_NUMB_BITS != 32
Error, error, this data is for 32 bits
#endif
while in gmp.h:
#define GMP_LIMB_BITS 64
#define GMP_NAIL_BITS 0
#define GMP_NUMB_BITS (GMP_LIMB_BITS - GMP_NAIL_BITS)
fib_table.c is generated by gen-fix.exe tool, and this tool is generated by make.
So, if one tries to build x64 build after building x86 (like me), it is not enough to run "make clean" first. Delete all "gen-*.exe" files in gmp root folder after running "make clean", this files will be rebuilt properly by make. gmp x64 was successfully build for me after that.
Tested on gmp 6.0.0.
How I built dynamic dll gmp-6.1.2 for windows so that the dll can be linked for a visual studio project.
Setup Environment
Install 7-Zip
Install Cygwin, add the following packages to the default installation
gcc-core
gcc-g++
libgcc
m4
make
cmake
bash
Add the following Environment Variable to the User PATH: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\Hostx64\x64
This is so you can use the lib command. Your lib.exe may be located elsewhere.
Build GMP
Download the tar.bz2 version from https://gmplib.org/#DOWNLOAD and extract the gmp-6.1.2 folder with 7-zip.
Launch bash.exe from C:\cygwin64\bin.
Change directory to the unzipped gmp-6.1.2 folder. Ex: cd "A:\Code\gmp-6.1.2"
Execute ./configure --disable-static --enable-shared
Execute make
This will create cyggmp-10.dll under A:\Code\gmp-6.1.2\.libs\
Execute make check
Execute cd ./libs
Execute lib /machine:i386 /def:cyggmp-10.dll
This will generate cyggmp-10.exp and cyggmp-10.lib under A:\Code\gmp-6.1.2\.libs\ for use with visual studio
You now have everything needed to call gmp from C# code.
See http://gladman.plushost.co.uk/oldsite/computing/gmp4win.php , and note this paragraph;
GMP cannot, however, provide high
performance 64-bit libraries on
Windows because its 64-bit assembler
code is incompatible with Windows x64
calling conventions. This means that
64-bit GMP libraries on WIndows are
very slow when compared with MPIR,
which has excellent 64-bit assembler
support.
So you either disable assembly with ./configure --disable-assembly or use MPIR.
You might want to take a look at MPIR. It is a fork of GMP that natively supports Visual Studio.
I have tried the following. The library can be built successfully.
./configure --prefix=/d/Temp/gmp-5.0.1-install --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --disable-static --enable-shared
I'm trying to create a project as a shared library in OS X using CMake 2.8 and gcc 4.6 (from macports). When CMake gets to the point of linking my library into a .dylib, I get the following error from gcc:
g++ -dynamiclib -headerpad_max_install_names -o libmycoollibrary.dylib etc...
g++: error: unrecognized option '-h'
make[2]: *** [libnrtCore.dylib] Error 1
make[1]: *** [CMakeFiles/nrtCore.dir/all] Error 2
make: *** [all] Error 2
This -headerpad_max_install_names seems to be the problem, but I've never seen it before. Does anyone know how to either get CMake to not include this option, or to get GCC to accept this option?
You can re-build cmake to fix this -- it's apparently generating code for the XCode / Darwin version of g++ (a special version of 4.2), which accepts a number of non-standard linker flags.
Just change the Modules/Platform/Darwin*.cmake files and re-build. The culprit lines look like this:
SET(CMAKE_CXX_LINK_FLAGS "-Wl,-search_paths_first -headerpad_max_install_names")