I am posting here since I don't think GROMACS is going to know my issue. I have MacOS Big Sur and download Intel C/C++ compiler because it is supposed to make this program faster. I can compile with clang and GNU gcc but not Intel. The cmake commands finds both feenableexcept/fedisableexcept but when using the functions in one of the C++ files math/utilities.cpp during making the progam it fails. See failure below. It is related maybe to this post
-- Looking for feenableexcept in m
-- Looking for feenableexcept in m - found
-- Looking for fedisableexcept in m
-- Looking for fedisableexcept in m - found
Failure:
/Users/brian/tools/gromacs-2021.4/src/gromacs/math/utilities.cpp(96): error: identifier "feenableexcept" is undefined
return feenableexcept(c_FPexceptions);
^
/Users/brian/tools/gromacs-2021.4/src/gromacs/math/utilities.cpp(125): error: identifier "fedisableexcept" is undefined
return fedisableexcept(c_FPexceptions);
^
This is my cmake commmand
cmake .. -DGMX_FFT_LIBRARY=mkl \
-DMKL_LIBRARIES="/opt/intel/oneapi/mkl/2021.4.0/lib" \
-DMKL_INCLUDE_DIR="/opt/intel/oneapi/mkl/2021.4.0/include" \
-DCMAKE_C_COMPILER=icc \
-DCMAKE_CXX_COMPILER=icpc \
-DCMAKE_OSX_SYSROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk \
-DCMAKE_OSX_DEPLOYMENT_TARGET=/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk \
-DGMX_USE_TNG=OFF \
-DZLIB_LIBRARY=/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/lib
And these are my flags I set before running cmake
CFLAGS="-syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/lib -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk -L/opt/intel/oneapi/ipp/latest/lib -I/opt/intel/oneapi/compiler/2021.4.0/mac/compiler/include -I/opt/intel/oneapi/ipp/latest/include -MMD -MF -MP -lz -std=99 -lboost"
CXXFLAGS="-syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/lib -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk -L/opt/intel/oneapi/ipp/latest/lib -I/opt/intel/oneapi/compiler/2021.4.0/mac/compiler/include -I/opt/intel/oneapi/ipp/latest/include -MMD -MF -MP -lz -std=99 -lboost"
export CPLUS_INCLUDE_PATH=/opt/intel/oneapi/compiler/2021.4.0/mac/compiler/include:/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/include:/opt/intel/oneapi/ipp/latest/include
export C_INCLUDE_PATH=/opt/intel/oneapi/compiler/2021.4.0/mac/compiler/include:/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/include:/opt/intel/oneapi/ipp/latest/include
export CPATH=/opt/intel/oneapi/compiler/2021.4.0/mac/compiler/include:/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include:$(xcrun --show-sdk-path)/usr/include:/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/include:/opt/intel/oneapi/ipp/latest/include
export LIBRARY_PATH=/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/lib
Related
I'm trying to build mongodb (open source version 4.2) which uses python and scons for building. The problem relates to scons rather than mongodb.
My build fails very early with Couldn't find OpenSSL crypto.h header and library. Verbose details are:
file /.../SConstruct,line 3042:
Configure(confdir = build/scons/opt/sconf_temp)
scons: Configure: Checking for SSLeay_version(0) in C library crypto...
build/scons/opt/sconf_temp/conftest_d6743137aeb7fb2674cc9632f9989034_0.c <-
|
|
|#include "openssl/crypto.h"
|
|int
|main() {
| SSLeay_version(0);
|return 0;
|}
|
gcc -o build/scons/opt/sconf_temp/conftest_d6743137aeb7fb2674cc9632f9989034_0.o -c -std=c11 -ffp-contract=off -fno-omit-frame-pointer -fno-strict-aliasing -ggdb -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -Werror -O2 -Wno-unused-local-typedefs -Wno-unused-function -Wno-deprecated-declarations -Wno-unused-const-variable -Wno-unused-but-set-variable -Wno-missing-braces -Wno-exceptions -fstack-protector-strong -fno-builtin-memcmp -fPIE -DNDEBUG -D_XOPEN_SOURCE=700 -D_GNU_SOURCE build/scons/opt/sconf_temp/conftest_d6743137aeb7fb2674cc9632f9989034_0.c
cc1: error: command-line option '-Wno-exceptions' is valid for C++/ObjC++ but not for C [-Werror]
cc1: all warnings being treated as errors
scons: Configure: no
I'm using Arch Linux which has multiple OpenSSL packages, and the default 3.0 is not compatible with mongodb source. I also have OpenSSL 1.1 and 1.0 installed, and can switch with e.g. gcc -I/usr/include/openssl-1.1.
Unfortunately I have not found a way to instruct SConstruct to use this flag in the command lines it generates to check the environment. I have tried CFLAGS, CCFLAGS, CPPPATH both as environment variables and scons command line parameters.
I also tried reverse enginering it, and tracked this to Conftest and TryBuild but it's not obvious how I can influance theses from the command line, so I'm trying my luck with you guys before going deeper in scons code.
If you look at the SConstruct and search for openssl, you'll find this blurb under the logic to detect on macOS
NOTE: Recent versions of macOS no longer ship headers for the system OpenSSL libraries.
NOTE: Either build without the --ssl flag, or describe how to find OpenSSL.
NOTE: Set the include path for the OpenSSL headers with the CPPPATH SCons variable.
NOTE: Set the library path for OpenSSL libraries with the LIBPATH SCons variable.
NOTE: If you are using HomeBrew, and have installed OpenSSL, this might look like:
\tscons CPPPATH=/usr/local/opt/openssl/include LIBPATH=/usr/local/opt/openssl/lib ...
NOTE: Consult the output of 'brew info openssl' for details on the correct paths."""
I'd bet if you did the same but pointed at the proper locations on your system for the openssl libs and header files, you'd be able to build.
(see: https://github.com/mongodb/mongo/blob/r4.2.0/SConstruct#L3015 )
I have to cross-compile wxGtk (an old version: 2.8.11) and managed to setup the environment so that configure runs successfully.
$ export CC=/opt/my_toolchain/toolchain_base/bin/i686-pc-linux-gnu-gcc
$ export CXX=/opt/my_toolchain/toolchain_base/bin/i686-pc-linux-gnu-g++
$ export CPPFLAGS=-I/opt/my_toolchain/additional_libs/usr/include/
$ export PKG_CONFIG_SYSROOT_DIR=/opt/my_toolchain/additional_libs/
$ export PKG_CONFIG_PATH=/opt/my_toolchain/additional_libs/usr/lib/pkgconfig
$ export PKG_CONFIG_DIR=/opt/my_toolchain/additional_libs/usr/lib/pkgconfig
$ export PKG_CONFIG_LIBDIR=/opt/my_toolchain/additional_libs/sysroot/usr/lib/
// LDFLAGS evtl falsch?? nicht ueberschreiben!?
$ export LDFLAGS="-L/opt/my_toolchain/additional_libs/lib/ -L/opt/my_toolchain/additional_libs/usr/lib/"
$ export CFLAGS="-Wl,-rpath-link=/opt/my_toolchain/additional_libs/lib/ -Wl,-rpath-link=/opt/my_toolchain/additional_libs/usr/lib/"
$ export CXXFLAGS="-Wl,-rpath-link=/opt/my_toolchain/additional_libs/lib/ -Wl,-rpath-link=/opt/my_toolchain/additional_libs/usr/lib/"
$ export LD_LIBRARY_PATH=/opt/my_toolchain/additional_libs/lib/:/opt/my_toolchain/additional_libs/usr/lib/:/opt/my_toolchain/additional_libs/usr/lib/:/opt/my_toolchain/additional_libs/lib/
$ pkg-config --define-variable=pc_path=/opt/my_toolchain/additional_libs/usr/lib/pkgconfig pkg-config
wxGTK-2.8.11 $ ./configure --enable-unicode --disable-shared --prefix=/usr/local/<targetname>
[...]
Configured wxWidgets 2.8.11 for `x86_64-unknown-linux-gnu'
Which GUI toolkit should wxWidgets use? GTK+ 2
Should wxWidgets be compiled into single library? no
Should wxWidgets be compiled in debug mode? no
Should wxWidgets be linked as a shared library? no
Should wxWidgets be compiled in Unicode mode? yes
What level of wxWidgets compatibility should be enabled?
wxWidgets 2.4 no
wxWidgets 2.6 yes
Which libraries should wxWidgets use?
jpeg sys
png sys
regex builtin
tiff sys
zlib sys
odbc no
expat sys
libmspack no
sdl no
However the subsequent make reports an error:
wxGTK-2.8.11 $ make
[...]
bk-make-pch ./.pch/wxprec_netlib/wx/wxprec.h.gch wx/wxprec.h /opt/my_toolchain/toolchain_base/bin/i686-pc-linux-gnu-g++ -I./.pch/wxprec_netlib -D__WXGTK__ -DWXBUILDING -I./src/regex -DwxUSE_GUI=0 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -I/mnt/cifs/osb_m/10_Competence_Centers/21_CC_IE/22_Kunden_Technik_Aktiv/Holmer/Software/Holmer_VT-Server/wxGTK-2.8.11/lib/wx/include/gtk2-unicode-release-static-2.8 -I./include -pthread -I/opt/my_toolchain/additional_libs//usr/include/gtk-2.0 -I/opt/my_toolchain/additional_libs//usr/lib/gtk-2.0/include -I/opt/my_toolchain/additional_libs//usr/include/pango-1.0 -I/opt/my_toolchain/additional_libs//usr/include/atk-1.0 -I/opt/my_toolchain/additional_libs//usr/include/cairo -I/opt/my_toolchain/additional_libs//usr/include/pixman-1 -I/opt/my_toolchain/additional_libs//usr/include/libpng16 -I/opt/my_toolchain/additional_libs//usr/include/gdk-pixbuf-2.0 -I/opt/my_toolchain/additional_libs//usr/include/libpng16 -I/opt/my_toolchain/additional_libs//usr/include/pango-1.0 -I/opt/my_toolchain/additional_libs//usr/include/harfbuzz -I/opt/my_toolchain/additional_libs//usr/include/pango-1.0 -I/opt/my_toolchain/additional_libs//usr/include/freetype2 -I/opt/my_toolchain/additional_libs//usr/include/glib-2.0 -I/opt/my_toolchain/additional_libs//usr/lib/glib-2.0/include -I/opt/my_toolchain/additional_libs/usr/include/ -DWX_PRECOMP -pthread -Wall -Wundef -Wno-ctor-dtor-privacy -O2 -fno-strict-aliasing -Wl,-rpath-link=/opt/my_toolchain/additional_libs/lib/ -Wl,-rpath-link=/opt/my_toolchain/additional_libs/usr/lib/
In file included from /opt/my_toolchain/additional_libs/usr/include/math.h:46:0,
from ./include/wx/math.h:19,
from ./include/wx/wx.h:30,
from ./include/wx/wxprec.h:68:
/opt/my_toolchain/additional_libs/usr/include/bits/mathdef.h:47:6: warning: "__FP_FAST_FMA" is not defined [-Wundef]
/opt/my_toolchain/additional_libs/usr/include/bits/mathdef.h:51:6: warning: "__FP_FAST_FMAF" is not defined [-Wundef]
/opt/my_toolchain/additional_libs/usr/include/bits/mathdef.h:55:6: warning: "__FP_FAST_FMAL" is not defined [-Wundef]
/opt/my_toolchain/toolchain_base/bin/../i686-pc-linux-gnu/libc/usr/lib/crt1.o: In function `_start':
(.text+0x18): undefined reference to `main'
collect2: error: ld returned 1 exit status
Makefile:12022: recipe for target '.pch/wxprec_netlib/wx/wxprec.h.gch' failed
make: *** [.pch/wxprec_netlib/wx/wxprec.h.gch] Error 1
I've printed the compiler command which reports the issue:
/opt/my_toolchain/toolchain_base/bin/i686-pc-linux-gnu-g++ \
-I./.pch/wxprec_baselib -D__WXGTK__ -DWXBUILDING \
-I./src/regex \
-DwxUSE_GUI=0 -DwxUSE_BASE=1 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES \
-I/path/to/wxGTK-2.8.11/lib/wx/include/gtk2-unicode-release-static-2.8 \
-I./include \
-pthread \
-I/opt/my_toolchain/additional_libs//usr/include/gtk-2.0 \
-I/opt/my_toolchain/additional_libs//usr/lib/gtk-2.0/include \
-I/opt/my_toolchain/additional_libs//usr/include/pango-1.0 \
-I/opt/my_toolchain/additional_libs//usr/include/atk-1.0 \
-I/opt/my_toolchain/additional_libs//usr/include/cairo \
-I/opt/my_toolchain/additional_libs//usr/include/pixman-1 \
-I/opt/my_toolchain/additional_libs//usr/include/libpng16 \
-I/opt/my_toolchain/additional_libs//usr/include/gdk-pixbuf-2.0 \
-I/opt/my_toolchain/additional_libs//usr/include/libpng16 \
-I/opt/my_toolchain/additional_libs//usr/include/pango-1.0 \
-I/opt/my_toolchain/additional_libs//usr/include/harfbuzz \
-I/opt/my_toolchain/additional_libs//usr/include/pango-1.0 \
-I/opt/my_toolchain/additional_libs//usr/include/freetype2 \
-I/opt/my_toolchain/additional_libs//usr/include/glib-2.0 \
-I/opt/my_toolchain/additional_libs//usr/lib/glib-2.0/include \
-I/opt/my_toolchain/additional_libs/usr/include/ \
-DWX_PRECOMP -pthread -Wall -Wundef -Wno-ctor-dtor-privacy -O2 -fno-strict-aliasing \
-Wl,-rpath-link=/opt/my_toolchain/additional_libs/lib/ \
-Wl,-rpath-link=/opt/my_toolchain/additional_libs/usr/lib/ \
-o ./.pch/wxprec_baselib/wx/wxprec.h.gch \
-MMD -MF \
./.deps/___pch_wxprec_baselib_wx_wxprec_h_gch.d \
./include/wx/wxprec.h
If I remove the two the -Wl,-rpath-link= statements from this compiler command and invoke it manually, the command succeeds.
It seems the additional -Wl statements make the compiler miss the source file with the main()-function (which seems to be provided via ./include/wx/wxprec.h), but I don't really see how that could happen.
I'd be grateful about any advice how I can address this problem.
Update
The configure-Script has the usual options (no --source)
--build=BUILD configure for building on BUILD [guessed]
--host=HOST cross-compile to build programs to run on HOST [BUILD]
--target=TARGET configure for building compilers for TARGET [HOST]
where --target is of no interest. The other options I'll have to check. As I mentioned in the comments, I've so far only seen them being used with prefixes e.g. aarch64-linux-gnu for toolchains from package repositories which are in the $PATH, and with according libraries etc.
So I've added the folder for toolchain binaries to path and configured with
./configure --enable-unicode --disable-shared --prefix=/usr/local/<target> --host=i686-pc-linux-gnu
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
checking build system type... x86_64-unknown-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
That looks correct. I want to build on my local machine for another target.
But:
checking for GTK+ - version >= 2.0.0... no
*** Could not run GTK+ test program, checking why...
*** The test program failed to compile or link. See the file config.log for the
*** exact error that occured. This usually means GTK+ is incorrectly installed.
configure: error:
The development files for GTK+ were not found. For GTK+ 2, please
ensure that pkg-config is in the path and that gtk+-2.0.pc is
installed. For GTK+ 1.2 please check that gtk-config is in the path,
and that the version is 1.2.3 or above. Also check that the
libraries returned by 'pkg-config gtk+-2.0 --libs' or 'gtk-config
--libs' are in the LD_LIBRARY_PATH or equivalent.
Unfortunately that makes sense. The toolchain itself only has some libraries, but does not have the GTK-libraries.
/opt/my_toolchain/toolchain_base/
The GTK libraries and other libraries are in a separate folder:
/opt/my_toolchain/additional_libs/
And the toolchain's binaries don't know about this folder.
I think the whole issue arises because wxGtk builds libraries for the host = i686-pc-linux-gnu, but also builds executables (e.g. wx-config) for the build-system = x86_64-unknown-linux-gnu.
The wxGtk 2.8.11 cross-build is finally working with the following setup:
export PATH=/opt/my_toolchain/toolchain_base/bin/:${PATH}
export PKG_CONFIG_SYSROOT_DIR=/opt/my_toolchain/additional_libs
export PKG_CONFIG_PATH=/opt/my_toolchain/additional_libs/usr/lib/pkgconfig
export PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1
# make sure those env vars are not left from previous setup
unset CC
unset CXX
unset CPPFLAGS
unset CFLAGS
unset CXXFLAGS
unset LD_LIBRARY_PATH
unset LDFLAGS
unset PKG_CONFIG_DIR
unset PKG_CONFIG_LIBDIR
./configure --enable-unicode --disable-shared --prefix=/usr/local/<target> --host=i686-pc-linux-gnu --build=x86_64-linux-gnu
make
sudo make install
I want to develop apps across multiple platform. I am new with wxwidgets. I want to compile debug but it produce an error. this is my command result. please help me. so far i've done apps using wpf mvvm c# but it can only be run in windows env. so i'm changing to c++ knowing that it can be compiled in any environment. please help me.
C:\wxWidgets-3.0.2\build\msw>mingw32-make SHELL=CMD.exe -f makefile.gcc USE_XRC=1 BUILD=debug UNICODE=1 SHARED=1 MONOLITHIC=1 USE_OPENGL=1 VENDOR=cb CXXFLAGS="-fno-keep-inline-dllexport"
if not exist ..\..\lib\gcc_dll\mswud mkdir ..\..\lib\gcc_dll\mswud
g++ -c -o gcc_mswuddll\monodll_any.o -g -O0 -mthreads -DHAVE_W32API_H -D__WXMSW__ -D_UNICODE -I..\..\lib\gcc_dll\mswud -I..\..\include -W -Wall -DWXBUILDING -I..\..\src\tiff\libtiff -I..\..\src\jpeg -I..\..\src\png -I..\..\src\zlib -I..\..\src\regex -I..\..\src\expat\lib -I..\..\src\stc\scintilla\include -I..\..\src\stc\scintilla\lexlib -I..\..\src\stc\scintilla\src -D__WX__ -DSCI_LEXER -DLINK_LEXERS -DwxUSE_BASE=1 -DWXMAKINGDLL -Wno-ctor-dtor-privacy -fno-keep-inline-dllexport -MTgcc_mswuddll\monodll_any.o -MFgcc_mswuddll\monodll_any.o.d -MD -MP ../../src/common/any.cpp
In file included from C:/TDM-GCC-32/lib/gcc/mingw32/5.1.0/include/c++/type_traits:35:0,
from ..\..\include/wx/strvararg.h:25,
from ..\..\include/wx/string.h:46,
from ..\..\include/wx/any.h:19,
from ../../src/common/any.cpp:18:
C:/TDM-GCC-32/lib/gcc/mingw32/5.1.0/include/c++/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
^
In file included from ..\..\include/wx/string.h:46:0,
from ..\..\include/wx/any.h:19,
from ../../src/common/any.cpp:18:
..\..\include/wx/strvararg.h:350:18: error: 'is_enum' in namespace 'std' does not name a template type
typedef std::is_enum<T> is_enum;
^
..\..\include/wx/strvararg.h:354:54: error: 'is_enum' was not declared in this scope
enum { value = wxFormatStringSpecifierNonPodType<is_enum::value>::value };
^
..\..\include/wx/strvararg.h:354:68: error: template argument 1 is invalid
enum { value = wxFormatStringSpecifierNonPodType<is_enum::value>::value };
^
makefile.gcc:6428: recipe for target 'gcc_mswuddll\monodll_any.o' failed
mingw32-make: *** [gcc_mswuddll\monodll_any.o] Error 1
C:\wxWidgets-3.0.2\build\msw>
Have you been following the usual build instructions without any changes? Something exceedingly strange is happening, as HAVE_TYPE_TRAITS is somehow defined for you (look at the condition in the file wx/strvararg.h just above the line that the error points you to), yet this shouldn't be the case with the unmodified wxWidgets sources because it's only defined when using C++11, i.e. when __cplusplus >= 201103L, yet the compiler you use (g++ 5.1) defines __cplusplus as 199711L by default.
If you had tried to build it differently, e.g. using configure, you must clean everything before building it again, i.e. just destroy the entire source directory and re-expand the archive if you had downloaded it or do git clean -fdx if you had cloned the Git repository.
You'll need to set the C++ standard to 11. Add -std=c++11 to your compile command line (I didn't paste the whole line as it's very long.):
mingw32-make SHELL=CMD.exe -f makefile.gcc -std=c++11 USE_XRC=1 BUILD=debug U...
I have a C++ project. I am testing a cross-compile with Autotools on OS X for iOS. I configure with:
$ echo $IOS_SYSROOT
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.2.sdk
$ CXXFLAGS="-DNDEBUG -g2 -O3 -arch arm64" ./configure --with-sysroot="$IOS_SYSROOT" --build=`config.guess` --host=aarch64-ios
When make'ing it results in (line breaks added for clarity):
libtool: compile: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
-DHAVE_CONFIG_H -I. ... -DNDEBUG -g2 -O3 -arch arm64 -MT adhoc.lo -MD -MP -MF .deps/adhoc.Tpo -c adhoc.cpp -o adhoc.o
In file included from adhoc.cpp:2:
In file included from /usr/include/c++/4.2.1/iosfwd:44:
In file included from /usr/include/c++/4.2.1/bits/c++config.h:41:
In file included from /usr/include/c++/4.2.1/bits/os_defines.h:61:
In file included from /usr/include/unistd.h:71:
In file included from /usr/include/_types.h:27:
In file included from /usr/include/sys/_types.h:32:
/usr/include/sys/cdefs.h:658:2: error: Unsupported architecture
#error Unsupported architecture
...
Notice the wrong header files are being used. The build system's headers are used rather than the iPhone headers. I'm fairly certain --with-sysroot is not being honored. Searching for the keywords seems to indicate its a widespread problem with Autoconf (based on all the bug reports trying to use the feature).
Manually adding CXXFLAGS="-sysroot=$IOS_SYSROOT -arch arm64 ... seems to fix the issue. This seems to be the same problem (or nearly the same problem) detailed at Bug 79885: --with-build-sysroot= does not get honored throughout the build.
There does not seem to be a AC_SYSROOT (or similar) to copy --with-sysroot into AM_CXXFLAGS. Searching the Autoconf site for the keywords is not returning useful hits: "--with-sysroot" site:https://www.gnu.org/software/autoconf/manual.
How are we supposed to handle Autoconf's --with-sysroot option? What is the practice packagers are supposed to follow?
Here are the Autoconf prject files: cryptopp-autotools. There are two files of interest, and they are configure.ac and Makefile.am. I'm not sure what applies to this problem at the moment.
Here's the message where Autoconf tells users to use it:
$ ./configure --help | grep sysroot
--with-sysroot[=DIR] Search for dependent libraries within DIR (or the
compiler's sysroot if not specified).
I'd prefer to supress the message if Autoconf cannot wire-in --with-sysroot properly. Otherwise, users are going to be filling bug reports against us.
Am trying to compile a large C++ project in a simulated 32bits environment (cel5.03-i386-2.3) on a 64bits machine. (The compiling worked well on 32bits machine before)
During this compiling some files fail as below. The weird thing is that the argument passed to g++ command is "--sysroot=" while in error message it becomes "-fsysroot=".
Why could this happen?
/usr/bin/g++ -MMD -MF /proj/src/.debug/lib/osiris/core/utils/WWNConverter.d -I/proj/src/lib/osiris -DDEBUG_LOG -DDEBUG -D_REENTRANT -DAPE_MODE -DSWAT_MODE -g -Werror -Wall -Wno-write-strings -fPIC -m32 --sysroot=/auto/andpkg/rep_cache//wr-x86/3.0FCS/sysroot -rdynamic -I/proj/src -I/proj/src/.debug/include/private -I/proj/src/.debug/include/public -I/proj/src/lib/framework -I/proj/src/lib/osiris -I/proj/src/lib/prt -I/proj/src/lib/callhome -I/proj/src/lib/snmp -I/proj/src/.debug/external/pcre/include -I/proj/src/external/sqlite/include -I/proj/src/external/openssl/openssl-fips-1.2.3/include -I/proj/src/support/storage-driver/include -I/proj/src/external/json/include -DTARGET_OBJECT=libosiris.so -I/proj/src/.debug/external/pcre/include -I/proj/src/.debug/external/libcurl/include -o /proj/src/.debug/lib/osiris/core/utils/WWNConverter.o -c /proj/src/lib/osiris/core/utils/WWNConverter.cc
make[1]: *** [/proj/src/.debug/lib/osiris/core/utils/WWNConverter.o] Error 1
cc1plus: error: unrecognized command line option "-fsysroot=/auto/andpkg/rep_cache//wr-x86/3.0FCS/sysroot"
The 32-bit compiler (GCC 3.4.6) is too old to support the --sysroot option, which was added to trunk with commit 102367, and did not make it into a release branch until GCC 4.1.0.
2005-07-25 Mark Mitchell <mark#codesourcery.com>
* gcc.c (option_map): Add --sysroot.
(process_command): Handle --sysroot.
(display_help): Document it.
* doc/cppopts.tex (-isysroot): Document.
* doc/invoke.texi (--sysroot): Document.
* doc/install.texi (--with-build-sysroot): Document.
* Makefile.in (inhibit_libc): New variable.
(INHIBIT_LIBC_CFLAGS): Likewise.
(LIBGCC2_CFLAGS): Include
$(INHIBIT_LIBC_CFLAGS).
(CRTSTUFF_CFLAGS): Include $(INHIBIT_LIBC_CFLAGS).
($(T)crtbegin.o): Do not use #inhibit_libc#.
($(T)crtend.o): Likewise.
($(T)crtbeginS.o): Do not use #inhibit_libc#.
($(T)crtendS.o): Likewise.
($(T)crtbeginT.o): Do not use #inhibit_libc#.
($(T)crtendT.o): Likewise.
(stmp-fixinc): Do not complain about missing headers if
inhibit_libc.
* configure.ac (inhibit_libc): Set it to true/false.
(--with-build-sysroot): New option. Use it to set
SYSTEM_HEADER_DIR.
* configure: Regenerated.