mac trying to compile with -nostdinc - c++

I am trying to do a "clean" build of a c++ program on my mac. By clean, I mean, do not include anything that I do not explicitly specify.
My gcc installation is located at:
/Applications/gcc471/
So far, I can compile using
-nostdinc++
by including
GPP-INCLUDES += -I/Applications/gcc471/include/c++/4.7.1/
GPP-INCLUDES += -I/Applications/gcc471/include/c++/4.7.1/x86_64-apple-darwin12.0.0
and doing
g++ -c *.cpp $(GPP-INCLUDES) -nostdinc++
I am pretty happy with that. However, I am trying to make the leap into compiling with
-nostdinc
And it seems that, no matter how many paths I include like
/usr/local/include
/usr/include
....
I get a crapton of errors like this:
/Applications/gcc471/include/c++/4.7.1/tr1/cmath: At global scope:
/Applications/gcc471/include/c++/4.7.1/tr1/cmath:156:11: error: ‘::double_t’ has not been declared
/Applications/gcc471/include/c++/4.7.1/tr1/cmath:157:11: error: ‘::float_t’ has not been declared
/Applications/gcc471/include/c++/4.7.1/tr1/cmath:160:11: error: ‘::acosh’ has not been declared
...
Does anyone know how to completely build a cpp program from scratch on the mac using -nostdinc?

I was able to compile using -nostdinc, but not without -I/usr/include/ as I had hoped. I do not trust Xcodes llvm/clang/gcc4.2 (Really old)/not real GCC nonsense. So I downloaded GCC from scratch and built it from source using the guide here: http://staticimport.blogspot.ca/2012/02/building-gcc-462-on-os-x-lion.html
The problem is that libstdc does not appear to ship with gcc anymore, only libstdc++. So all .hpp files are in my GCC directory, but really old headers, such as locale.h (From 1993), only appears to come with the libstdc XCode installs to /usr/include. I will keep looking for a vanilla libstdc to install, but for now, these are the most minimal and most "GNU" directories I can include to compile:
...
#FOR -nostdinc++
GPP-INCLUDES += -I/Applications/gcc471/include/c++/4.7.1/
GPP-INCLUDES += -I/Applications/gcc471/include/c++/4.7.1/x86_64-apple-darwin12.0.0
#for -nostdinc
GPP-INCLUDES += -I/Applications/gcc471/lib/gcc/x86_64-apple-darwin12.0.0/4.7.1/include/
GPP-INCLUDES += -I/usr/local/include
GPP-INCLUDES += -I/usr/include/ #bahhhhh cant get away
g++ -c *.cpp $(GPP-INCLUDES) -nostdinc++ -nostdinc -std=c++11

Related

Lapack with Cygwin 64bit and C++ code

I'd like to learn how to use lapack together with C/C++ code in Windows. I am a C/C++ programming newbie, so I know how to code in C, how to organize the code in h/c files, and how to compile them with gcc under cygwin / MinWG / VS. What I'm totally new to is the use of external libraries, such as lapack.
To learn how to use it with Cygwin (64bit), I followed the procedure indicated here
(http://matrixprogramming.rudnyi.ru/2011/04/using-lapack-from-c/)
which seemed to be successful and created the built version of lapack in the folder $HOME\lapack-3.3.0
Now I want to re-run this example: main.cc
What I did was to try to compile it by calling
$ g++ -O3 main.cc -L$HOME/lapack-3.3.0 -llapack -lblas -lgfortran -I ./include -o main
and what I get is
main.cc: In function ‘int main(int, char**)’:
main.cc:39:23: error: ‘dgetf2’ was not declared in this scope
info = dgetf2(A, ipvt);
^
main.cc:45:23: error: ‘dgetrf’ was not declared in this scope
info = dgetrf(A, ipvt);
^
main.cc:55:26: error: ‘dgetrs’ was not declared in this scope
info = dgetrs(A, B, ipvt);
^
where the "include" folder only contains the
Matrix.h
matrix class required in main.cc
To me it seems that some header files are missing. What I do not understand is how this is possible if the building process of the libraries was successful. Do I have to give further "-I options"? I looked for "dgetf2", "dgetrf" and "dgetrs" in the lapack-3.3.0 folder, so I found the object files in $HOME\lapack-3.3.0\SRC but if I include them as well as
$ g++ -O3 main.cc -L$HOME/lapack-3.3.0 -llapack -lblas -lgfortran -I ./include -I $HOME/lapack-3.3.0/SRC -o main
I get exactly the same error which makes somehow sense as they are object files and not header files. What am I doing wrong? How does one manage declarations of functions implemented in external libraries?
Thanks!

--with-sysroot is not honored during a compile on OS X?

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.

C++ PackageKit newb linking issue

I'm trying to import PackageKit into a C++ project I'm working with (as a C++ newbie coming from a mostly Java background). My goal is do some things with the packages I have installed on my system.
I've installed libpackagekit-glib2-16, libpackagekit-glib2-dev, libpackagekit-qt2-6, libpackagekit-qt2-dev, and packagekit (I know I won't need all of these down the line, but I'm just covering my bases for now). I can see that they've been installed here: /usr/include/PackageKit which has the subfolders packagekit-glib2, packagekit-qt2, plugin.
To help me along I'm using qt 5.2.1 to act as a crutch for my Makefiles while I'm still learning, but I'm not actually using any qt resources for now. I've been able to import apt's and dpkg's libraries previously via -lapt-lib and -ldpkg under qt's LIBS+= but I can't figure out how to import the packagekit's library (I've tried multiple variations, but I can't figure out how to properly import this library).
This:
#define I_KNOW_THE_PACKAGEKIT_GLIB2_API_IS_SUBJECT_TO_CHANGE
#include <PackageKit/packagekit-glib2/packagekit.h>
int main(int argc, char *argv[])
{
return 0;
}
Results with this:
g++ -c -std=c++11 -g -Wall -W -D_REENTRANT -fPIE -DQT_QML_DEBUG -DQT_DECLARATIVE_DEBUG -DQT_CORE_LIB -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -I../console-example -I/usr/include/qt5 -I/usr/include/qt5/QtCore -I. -I. -o main.o ../console-example/main.cpp
In file included from ../console-example/main.cpp:3:0:
/usr/include/PackageKit/packagekit-glib2/packagekit.h:31:41: fatal error: packagekit-glib2/pk-catalog.h: No such file or directory
#include <packagekit-glib2/pk-catalog.h>
If this is necessary, my system is Ubuntu 14.04 64bit and as I've mentioned I'm using qt 5.2.1 to help with the makefile. Thanks to all in advance!
This seems to be a compilation problem. The compiler cannot find packagekit's headers. I suppose that into g++ line you need to add -I/usr/include/PackageKit or something similar.
From within my qt project's .pro file I had to make the following additions to get it to compile and link.
CONFIG += link_pkgconfig # This enables the next line
PKGCONFIG = gtk+-2.0 # This will link against gtk+-2.0
INCLUDEPATH += /usr/include/PackageKit/ \ # This is the include for packagekit
+= /usr/lib/glib-2.0/include/ # This will include glib, which packagekit is dependent on

compile <json/json.h> in eclipse using c++

I'm trying to include and compile
#include <json/json.h>
However even though I've installed it and included it on the project settings it wouldn't find the path.
here's what I've so far done:
path to libjson:
/usr/include/jsoncpp-src-0.5.0
options in eclipse gcc c++ compiler:
-Ijson_linux-gcc-4.5.2_libmt -O0 -g3 -Wall -c -fmessage-length=0 -ljson_linux-gcc-4.5.2_libmt
libraries in gcc c++ linker:
-L/usr/include/jsoncpp-src-0.5.0/include/
Anything else I forgot to do to make it work?
try adding -I/usr/include/jsoncpp-src-0.5.0 to compiler options
-L indicates where to find shared libraries (e.g. .so)
-I is the search path for the header files.
If the problem occurs during compilation (json.h not found), then you have indicated the wrong -I
If it occurs during linking (symbol not found), then you have indicated a wrong -L, a wrong -l, or forgot to run ldconfig

gcc compilation without using system defined header locations

I am attempting to compile a c++ class using gcc. Due to the nature of the build, I need to invoke gcc from a non-standard location and include non-system defined headers, only to add a set from a different location. However, when I do this, I run into an issue where I cannot find some base symbols (suprise suprise). So i am basically running this command to compile my code:
-->(PARENT_DIR)/usr/bin/gcc # invoke compiler
-B$(PARENT_DIR)/usr/lib64/gcc/suselinux-x8664
-B$(PARENT_DIR)/usr/lib64
#C/C++ flags
-fPIC -fvisibility=default -g -c -Wall -m64 -nostdinc
# source files
-I$(SRC_DIR_ONE)/
-I$(SRC_DIR_TWO)
-I../include
# 'Mock' include the system header files
-I$(PARENT_DIR)/usr/include/c++/$(GCC_VERSION)
-I$(PARENT_DIR)/usr/include/c++/$(GCC_VERSION)/backward
-I$(PARENT_DIR)/usr/include/c++/$(GCC_VERSION)/x86_64-suse-linux
-I$(PARENT_DIR)/usr/lib64/x86_64-suse-linux/$(GCC_VERSION)/include
-I$(PARENT_DIR)/usr/lib64/gcc/x86_64-suse-linux/$(GCC_VERSION)/include
-I$(PARENT_DIR)/usr/lib64/gcc/x86_64-suse-linux/$(GCC_VERSION)/include-fixed
-I$(PARENT_DIR)/usr/src/linux/include
-I$(PARENT_DIR)/usr/x86_64-suse-linux/include
-I$(PARENT_DIR)/usr/include/suselinux-x8664
-I$(PARENT_DIR)/usr/suselinux-x8664/include
-I$(PARENT_DIR)/usr/include
-I$(PARENT_DIR)/usr/include/linux
file.cpp
I am getting several errors which indicate that the base headers are not being included: such as:
$(PARENT_DIR)/usr/include/c++/$(GCC_VERSION)/cstddef ::prtdiff_t has not been declared
$(PARENT_DIR)/usr/include/c++/$(GCC_VERSION)/cstddef ::size_t has not bee declared.
Is there something that I am doing wrong when I include the header file directories? Or am I looking in the wrong place?
Perhaps the --sysroot arg would help, see gcc docs.