I've been struggling for the last couple of days trying to install GMP on Windows and it is not working at all. This is what I get when I run:
$ ./configure --prefix=${gmp_build} --build= --enable-cxx --with-gnu-ld
checking build system type... sandybridge-unknown-cygwin checking host
system type... sandybridge-unknown-cygwin checking for a
BSD-compatible install... /usr/bin/install -c checking whether build
environment is sane... yes checking for a thread-safe mkdir -p...
/usr/bin/mkdir -p checking for gawk... gawk checking whether make sets
$(MAKE)... yes checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of
Makefiles... no checking ABI=64 checking compiler gcc -O2 -pedantic
-fomit-frame-pointer -m64 ... no, function pointer return checking whether cc is gcc... yes checking compiler cc -O2 -pedantic
-fomit-frame-pointer -m64 ... no checking ABI=x32 checking compiler gcc -O2 -pedantic -fomit-frame-pointer -mx32 ... no checking whether
cc is gcc... yes checking compiler cc -O2 -pedantic
-fomit-frame-pointer -mx32 ... no checking ABI=32 checking compiler gcc -m32 -O2 -pedantic -fomit-frame-pointer ... no checking compiler
gcc -O2 -pedantic -fomit-frame-pointer ... no checking compiler icc
-no-gcc ... no checking whether cc is gcc... yes checking compiler cc -m32 -O2 -pedantic -fomit-frame-pointer ... no checking compiler cc -O2 -pedantic -fomit-frame-pointer ... no configure: error: could not find a working compiler, see config.log for details
Could anyone give me hand with this.
Related
I'm working on a shared library with CMake. Today I try to build it with NDK 25. when build type is "DEBUG", cmake add -O0 in CXX_FLAGS, and it add "-O2" in "RELWITHDEBINFO" build type. but when I changed it to "RELEASE", no optimize level was set.
I looked into the files that CMake generated. I found this in "CMakeCache.txt":
//Flags used by the compiler during all build types.
CMAKE_CXX_FLAGS:STRING=
//Flags used by the compiler during debug builds.
CMAKE_CXX_FLAGS_DEBUG:STRING=
//Flags used by the CXX compiler during MINSIZEREL builds.
CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG
//Flags used by the compiler during release builds.
CMAKE_CXX_FLAGS_RELEASE:STRING=
//Flags used by the CXX compiler during RELWITHDEBINFO builds.
CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG
//Libraries linked by default with all C++ applications.
CMAKE_CXX_STANDARD_LIBRARIES:STRING=-latomic -lm
I found "CMAKE_CXX_FLAGS_RELEASE:STRING" is empty, that's why optimize level is not set when buildding "RELEASE".
This is my shell script to run the cmake:
NDK_PATH="~/Library/Android/sdk/ndk/25.0.8775105"
rm -rf buildV7
mkdir buildV7
cd buildV7
../../../../CMake/Mac/CMake.app/Contents/bin/cmake ..
-DANDROID_ABI=armeabi-v7a
-DANDROID_PLATFORM=android-23
-DANDROID_NDK=$NDK_PATH
-DCMAKE_BUILD_TYPE=RELEASE
-DCMAKE_TOOLCHAIN_FILE=$NDK_PATH/build/cmake/android.toolchain.cmake
make VERBOSE=1
cd ..
the final clang command is:
Android/sdk/ndk/25.0.8775105/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++ --target=armv7-none-linux-androideabi23 --sysroot=Android/sdk/ndk/25.0.8775105/toolchains/llvm/prebuilt/darwin-x86_64/sysroot -DBianqueLogger_EXPORTS -I/Users/TestProj/build/android/dynamicLib/../../../src -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -march=armv7-a -mthumb -Wformat -Werror=format-security -DNDEBUG -fPIC -std=gnu++11 -MD -MT CMakeFiles/BianqueLogger.dir/Users/TestProj/src/utils/head.cpp.o -MF CMakeFiles/BianqueLogger.dir/Users/TestProj/src/utils/head.cpp.o.d -o CMakeFiles/BianqueLogger.dir/Users/TestProj/src/utils/head.cpp.o -c /Users/TestProj/src/utils/head.cpp
Is This NDK's BUG? Or -O3 is no longer needed in NDK25 and it's clang toolchain?
https://github.com/android/ndk/issues/1740. Will be fixed in r25b.
But typically you don't want to use Release for Android, you want to use RelWithDebInfo or MinSizeRel (it's really unfortunate that cmake doesn't have a MinSizeRelWithDebInfo). Your packaging tools should be stripping any libraries before packing them into an APK, so there is no reason to avoid compiling debug info. All that does is make it so you can't debug.
"Release" - there is no such config by default in NDK since r23. The default configs are: "Debug", "MinSizeRel" and "RelWithDebInfo". Use one of these three.
I use R version 4.0.2 (2020-06-22) -- "Taking Off Again". My system is W10 enterprise 1909.
I assume I have correctly installed Rtools40, since:
install.packages("jsonlite", type = "source") terminates correctly
I used some code from devtools: has_rtools() and it returns TRUE.
install.packages("jsonlite", type = "source")
essai de l'URL 'https://cran.rstudio.com/src/contrib/jsonlite_1.6.1.tar.gz'
Content type 'application/x-gzip' length 1057910 bytes (1.0 MB)
downloaded 1.0 MB
* installing *source* package 'jsonlite' ...
** package 'jsonlite' correctement décompressé et sommes MD5 vérifiées
** using staged installation
** libs
*** arch - i386
C:/Users/toto26/DOCUME~1/R/R-40~1.2/etc/i386/Makeconf:244: warning: overriding recipe for target '.m.o'
C:/Users/toto26/DOCUME~1/R/R-40~1.2/etc/i386/Makeconf:237: warning: ignoring old recipe for target '.m.o'
"C:/rtools40//mingw32/bin/"gcc -I"C:/Users/toto26/DOCUME~1/R/R-40~1.2/include" -DNDEBUG -Iyajl/api -D__USE_MINGW_ANSI_STDIO -O2 -Wall -std=gnu99 -mfpmath=sse -msse2 -mstackrealign -c base64.c -o base64.o
[...]
"C:/rtools40//mingw32/bin/"ar rcs yajl/libstatyajl.a yajl/yajl.o yajl/yajl_alloc.o yajl/yajl_buf.o yajl/yajl_encode.o yajl/yajl_gen.o yajl/yajl_lex.o yajl/yajl_parser.o yajl/yajl_tree.o
C:/rtools40//mingw32/bin/gcc -shared -s -static-libgcc -o jsonlite.dll tmp.def base64.o collapse_array.o collapse_object.o collapse_pretty.o escape_chars.o integer64_to_na.o is_datelist.o is_recordlist.o is_scalarlist.o modp_numtoa.o null_to_na.o num_to_char.o parse.o prettify.o push_parser.o r-base64.o register.o row_collapse.o transpose_list.o validate.o -Lyajl -lstatyajl -LC:/Users/toto26/DOCUME~1/R/R-40~1.2/bin/i386 -lR
installing to C:/Users/toto26/Documents/R/R-4.0.2/library/00LOCK-jsonlite/00new/jsonlite/libs/i386
*** arch - x64
C:/Users/toto26/DOCUME~1/R/R-40~1.2/etc/x64/Makeconf:244: warning: overriding recipe for target '.m.o'
C:/Users/toto26/DOCUME~1/R/R-40~1.2/etc/x64/Makeconf:237: warning: ignoring old recipe for target '.m.o'
"C:/rtools40//mingw64/bin/"gcc -I"C:/Users/toto26/DOCUME~1/R/R-40~1.2/include" -DNDEBUG -Iyajl/api -D__USE_MINGW_ANSI_STDIO -O2 -Wall -std=gnu99 -mfpmath=sse -msse2 -mstackrealign -c base64.c -o base64.o
[...]
"C:/rtools40//mingw64/bin/"ar rcs yajl/libstatyajl.a yajl/yajl.o yajl/yajl_alloc.o yajl/yajl_buf.o yajl/yajl_encode.o yajl/yajl_gen.o yajl/yajl_lex.o yajl/yajl_parser.o yajl/yajl_tree.o
C:/rtools40//mingw64/bin/gcc -shared -s -static-libgcc -o jsonlite.dll tmp.def base64.o collapse_array.o collapse_object.o collapse_pretty.o escape_chars.o integer64_to_na.o is_datelist.o is_recordlist.o is_scalarlist.o modp_numtoa.o null_to_na.o num_to_char.o parse.o prettify.o push_parser.o r-base64.o register.o row_collapse.o transpose_list.o validate.o -Lyajl -lstatyajl -LC:/Users/toto26/DOCUME~1/R/R-40~1.2/bin/x64 -lR
installing to C:/Users/toto26/Documents/R/R-4.0.2/library/00LOCK-jsonlite/00new/jsonlite/libs/x64
** R
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
converting help for package 'jsonlite'
finding HTML links ... fini
base64 html
flatten html
fromJSON html
prettify html
rbind_pages html
read_json html
serializeJSON html
stream_in html
unbox html
validate html
** building package indices
** installing vignettes
** testing if installed package can be loaded from temporary location
*** arch - i386
*** arch - x64
** testing if installed package can be loaded from final location
*** arch - i386
*** arch - x64
** testing if installed package keeps a record of temporary installation path
* DONE (jsonlite)
The downloaded source packages are in
‘C:\Users\toto26\AppData\Local\Temp\RtmpQrssTP\downloaded_packages’
One of my issue may come from the location of make:
Sys.which("make")
make
"C:\\WINDOWS\\SYSTEM32\\make.exe"
instead of the expected
Sys.which("make")
## "C:\\rtools40\\usr\\bin\\make.exe"
I have asked my IT department to remove the system32 version from my laptop.
Nevertheless, I am not sure it is the root cause of my issues:
install.packages("Rcpp", type = 'source')
essai de l'URL 'https://cran.rstudio.com/src/contrib/Rcpp_1.0.4.6.tar.gz'
Content type 'application/x-gzip' length 2751467 bytes (2.6 MB)
downloaded 2.6 MB
* installing *source* package 'Rcpp' ...
** package 'Rcpp' correctement décompressé et sommes MD5 vérifiées
** using staged installation
** libs
*** arch - i386
C:/Users/toto26/DOCUME~1/R/R-40~1.2/etc/i386/Makeconf:244: warning: overriding recipe for target '.m.o'
C:/Users/toto26/DOCUME~1/R/R-40~1.2/etc/i386/Makeconf:237: warning: ignoring old recipe for target '.m.o'
"C:/rtools40//mingw32/bin/"g++ -std=gnu++11 -I"C:/Users/toto26/DOCUME~1/R/R-40~1.2/include" -DNDEBUG -I../inst/include/ -O2 -Wall -mfpmath=sse -msse2 -mstackrealign -c api.cpp -o api.o
"C:/rtools40//mingw32/bin/"g++ -std=gnu++11 -I"C:/Users/toto26/DOCUME~1/R/R-40~1.2/include" -DNDEBUG -I../inst/include/ -O2 -Wall -mfpmath=sse -msse2 -mstackrealign -c attributes.cpp -o attributes.o
"C:/rtools40//mingw32/bin/"g++ -std=gnu++11 -I"C:/Users/toto26/DOCUME~1/R/R-40~1.2/include" -DNDEBUG -I../inst/include/ -O2 -Wall -mfpmath=sse -msse2 -mstackrealign -c barrier.cpp -o barrier.o
"C:/rtools40//mingw32/bin/"g++ -std=gnu++11 -I"C:/Users/toto26/DOCUME~1/R/R-40~1.2/include" -DNDEBUG -I../inst/include/ -O2 -Wall -mfpmath=sse -msse2 -mstackrealign -c date.cpp -o date.o
"C:/rtools40//mingw32/bin/"g++ -std=gnu++11 -I"C:/Users/toto26/DOCUME~1/R/R-40~1.2/include" -DNDEBUG -I../inst/include/ -O2 -Wall -mfpmath=sse -msse2 -mstackrealign -c module.cpp -o module.o
"C:/rtools40//mingw32/bin/"g++ -std=gnu++11 -I"C:/Users/toto26/DOCUME~1/R/R-40~1.2/include" -DNDEBUG -I../inst/include/ -O2 -Wall -mfpmath=sse -msse2 -mstackrealign -c rcpp_init.cpp -o rcpp_init.o
"C:/rtools40//mingw32/bin/"g++ -std=gnu++11 -shared -s -static-libgcc -o Rcpp.dll tmp.def api.o attributes.o barrier.o date.o module.o rcpp_init.o -LC:/Users/toto26/DOCUME~1/R/R-40~1.2/bin/i386 -lR
/usr/bin/sh: line 8: "C:/rtools40//mingw32/bin/"g++ -std=gnu++11 : No such file or directory
aucune DLL n'a pas été créé
ERROR: compilation failed for package 'Rcpp'
* removing 'C:/Users/toto26/Documents/R/R-4.0.2/library/Rcpp'
Warning in install.packages :
installation of package ‘Rcpp’ had non-zero exit status
If I install the compiled version it works, but then I can't use Rcpp:
install.packages("Rcpp")
essai de l'URL 'https://cran.rstudio.com/bin/windows/contrib/4.0/Rcpp_1.0.4.6.zip'
Content type 'application/zip' length 3167452 bytes (3.0 MB)
downloaded 3.0 MB
package ‘Rcpp’ successfully unpacked and MD5 sums checked
The downloaded binary packages are in
C:\Users\toto26\AppData\Local\Temp\RtmpQrssTP\downloaded_packages
> Rcpp::evalCpp("2+2")
C:/Users/toto26/DOCUME~1/R/R-40~1.2/etc/x64/Makeconf:244: warning: overriding recipe for target '.m.o'
C:/Users/toto26/DOCUME~1/R/R-40~1.2/etc/x64/Makeconf:237: warning: ignoring old recipe for target '.m.o'
"C:/rtools40//mingw64/bin/"g++ -std=gnu++11 -I"C:/Users/toto26/DOCUME~1/R/R-40~1.2/include" -DNDEBUG -I"C:/Users/toto26/Documents/R/R-4.0.2/library/Rcpp/include" -I"C:/Users/toto26/AppData/Local/Temp/RtmpQrssTP/sourceCpp-x86_64-w64-mingw32-1.0.4.6" -O2 -Wall -mfpmath=sse -msse2 -mstackrealign -c file477046ea4828.cpp -o file477046ea4828.o
"C:/rtools40//mingw64/bin/"g++ -std=gnu++11 -shared -s -static-libgcc -o sourceCpp_2.dll tmp.def file477046ea4828.o -LC:/Users/toto26/DOCUME~1/R/R-40~1.2/bin/x64 -lR
/usr/bin/sh: line 8: "C:/rtools40//mingw64/bin/"g++ -std=gnu++11 : No such file or directory
Error in sourceCpp(code = code, env = env, rebuild = rebuild, cacheDir = cacheDir, :
Error occurred building shared library.
Any hints would be more than welcome.
Thanks a lot in advance.
Emmanuel
edit: here is my path:
> Sys.getenv('PATH')
[1] "C:\\rtools40\\usr\\bin;C:\\Users\\toto26\\Documents\\R\\R-4.0.2\\bin\\x64;C:\\rtools40\\usr\\bin;C:\\rtools40\\mingw64\\bin;C:\\ProgramData\\DockerDesktop\\version-bin;C:\\Program Files\\Docker\\Docker\\Resources\\bin;C:\\RBuildTools\\bin;C:\\RBuildTools\\mingw_64\\bin;C:\\RBuildTools\\mingw_32\\bin;C:\\Program Files (x86)\\Common Files\\Oracle\\Java\\javapath;C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\;C:\\Program Files\\MATLAB\\R2018a\\runtime\\win64;C:\\Program Files\\MATLAB\\R2018a\\bin;C:\\Program Files (x86)\\PDFtk\\bin\\;C:\\WINDOWS\\System32\\OpenSSH\\;C:\\rtools40\\usr\\bin;C:\\RBuildTools\\3.5\\mingw_64\\bin;C:\\RBuildTools\\3.5\\bin;C:\\Python\\Scripts\\;C:\\Python\\;C:\\Users\\toto26\\AppData\\Local\\Microsoft\\WindowsApps;C:\\Users\\toto26\\AppData\\Local\\atom\\bin;C:\\Users\\toto26\\AppData\\Local\\Programs\\MiKTeX 2.9\\miktex\\bin\\x64\\;C:\\RBuildTools\\3.3\\mingw_64\\bin;C:\\MinGW\\bin;C:\\Users\\toto26\\AppData\\Local\\Microsoft\\WindowsApps;C:\\Users\\toto26\\AppData\\Local\\Pandoc\\;"
If I compile in two stages, using a particular language standard:
g++ -std=c++2a -c file1.cpp #compile source files
g++ -std=c++2a -c file2.cpp
g++ -std=c++2a file1.o file2.o -o program #link 'em
...can I leave the -std=c++2a out of the link command, or is it sometimes needed?
Version is gcc 10.
I guess you are compiling on Linux with a recent GCC. Be sure to read more about C++ and about your particular compiler (i.e. GCC 9 is not the same as GCC 10). Check with g++ --version what it is.
In practice you want to compile with warnings and debug information (in DWARF for GDB inside your ELF object files and executables), so use
g++ -std=c++2a -Wall -Wextra -g -c file1.cpp
and likewise for file2.cpp
Later (once your program is correct enough, e.g. has few bugs) you could want to ask the compiler to optimize it. So you could use
g++ -std=c++2a -Wall -Wextra -O3 -g -c file1.cpp
Practically speaking, you'll configure your build automation tool (e.g. GNU make or ninja) to run your compilation commands.
In rare cases, you could want to use link time optimizations. Then you need to both compile and link with g++ -std=c++2a -Wall -Wextra -O3 -g -flto and perhaps other options.
Be aware that link time optimization could almost double your build time.
You could also be interested by static analysis options of GCC 10 (or even by writing your own static analysis using GCC plugins).
From the research I have done, the problem seems to be with clang. If that is the case, how would I fix this on a Mac? Would switching to Ubuntu/Linux be a better option?
I'm not sure if it is relevant, but my professor is having us code using C syntax using g++ and saving our files as '.cpp' before we dive into C++.
Warning:
clang: warning: argument unused during compilation: '-ansi'
[-Wunused-command-line-argument]
Makefile:
CC = g++
calendar: main.o calendar.o appt.o day.o time.o
$(CC) main.o calendar.o appt.o day.o time.o -g -ansi -Wall -o calendar.out
%.o: %.cpp
$(CC) -Wall -c $<
You are correct in believing that this warning is issued by clang++ in these
circumstances and not by g++, and that you see it on your Mac because g++ is
really clang++.
The GCC option -ansi is meaningful for compilation and not meaningful
for linkage. Clang is warning you because you are passing it in your linkage recipe:
$(CC) main.o calendar.o appt.o day.o time.o -g -ansi -Wall -o calendar.out
where it is ineffective, and not passing it to your compilation recipe:
$(CC) -Wall -c $<
The wording of the diagnostic is misleading since it is provoked here
precisely by the absence of compilation. Nevertheless, it does
draw attention to a mistake on your part. Remove -ansi from your linkage recipe and add it to your compilation recipe.
This is in regards to compiling libjpeg v6b if that is relevant.
I run ./configure --prefix=/c/tmp/jpeg-6b-build --enable-shared --enable-static like the install doc says but libtool isn't having it.
checking dynamic linker characteristics... no
checking if libtool supports shared libraries... no
checking whether to build shared libraries... no
checking whether to build static libraries... yes
I think I need this shared library to be able to compile some functions. libjpeg itself compiles fine and the .exe's it generates work but I need to use the source for something else. v6b doesn't generate a .DLL for some reason while v9 does.
Full output for ./configure command:
ild
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking how to run the C preprocessor... gcc -E
checking for function prototypes... yes
checking for stddef.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for size_t... yes
checking for type unsigned char... yes
checking for type unsigned short... yes
checking for type void... yes
checking for working const... yes
checking for inline... __inline__
checking for broken incomplete types... ok
checking for short external names... ok
checking to see if char is signed... yes
checking to see if right shift is signed... yes
checking to see if fopen accepts b spec... yes
checking for a BSD compatible install... /bin/install -c
checking for ranlib... ranlib
checking host system type... i386-pc-mingw32
checking for ranlib... ranlib
checking for gcc... gcc
checking whether we are using GNU C... yes
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... no
checking if gcc static flag -static works... -static
checking whether ln -s works... no
checking for ld used by GCC... ./c:/mingw/bin/../lib/gcc/mingw32/4.7.2/../../../
../mingw32/bin/ld.exe
checking if the linker (./c:/mingw/bin/../lib/gcc/mingw32/4.7.2/../../../../ming
w32/bin/ld.exe) is GNU ld... yes
checking whether the linker (./c:/mingw/bin/../lib/gcc/mingw32/4.7.2/../../../..
/mingw32/bin/ld.exe) supports shared libraries... yes
checking for BSD-compatible nm... /mingw/bin/nm
checking command to parse /mingw/bin/nm output... no
checking how to hardcode library paths into programs... immediate
checking for ./c:/mingw/bin/../lib/gcc/mingw32/4.7.2/../../../../mingw32/bin/ld.
exe option to reload object files... -r
checking dynamic linker characteristics... no
checking if libtool supports shared libraries... no
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking for objdir... .libs
creating libtool
checking libjpeg version number... 62
creating ./config.status
creating Makefile
creating jconfig.h
jconfig.h is unchanged
Related question: Need help compiling jpegtran.c code from libjpeg
I encountered the same problem, and I believe it is because jpeg-6b is built with a very old version of autotools (the jpeg-6b version dates back 1998 if the sourceforge page is correct).
In particular, the problem is the way it checks if gcc supports the -fPIC flag:
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... no
And this is how they perform the check from config.log:
ltconfig:547: checking if gcc PIC flag -fPIC works
ltconfig:548: gcc -c -fPIC -DPIC -I/local/include conftest.c 1>&5
conftest.c:1:0: warning: -fPIC ignored for target (all code is position independent)
^
Notice how gcc returns a warning, it probably returns exit code 1 which makes the check fail. And position-independent code is necessary for shared libraries, so this makes it think it can't make them, and it later outputs:
checking whether to build shared libraries... no
Compare that with libjpeg9, which I assume uses a more up-to-date version of autotools:
checking for gcc -std=gnu99 option to produce PIC... -DDLL_EXPORT -DPIC
checking if gcc -std=gnu99 PIC flag -DDLL_EXPORT -DPIC works... yes
And from config.log:
configure:10108: checking for gcc -std=gnu99 option to produce PIC
configure:10115: result: -DDLL_EXPORT -DPIC
configure:10123: checking if gcc -std=gnu99 PIC flag -DDLL_EXPORT -DPIC works
configure:10141: gcc -std=gnu99 -c -g -O2 -I/local/include -DDLL_EXPORT -DPIC -DPIC conftest.c >&5
configure:10145: $? = 0
configure:10158: result: yes
I eventually compiled libjpeg9 instead, but I think libjpeg6 might also be compilable if you can recreate the ./configure script using a newer version of autotools.
You should probably try to run
./configure --help
and see all available configure flags, maybe you misspelled some or you need --enable-dynamic or something different.
For configure output you could also refer to config.log, that is in the project's (in your case -- libjpeg's) directory, just next to the configure file.