Xcode compile error with PostgreSQL headers - xcode

I am trying to include the following PostgreSQL headers files into my Xcode 7.2 project:
#import "postgres.h"
#import "pg_type.h"
#import "libpq-fe.h"
The app is written in Swift. I have an Objective-C bridging header. If I just import "libpq-fe.h" there are no compile errors.
When I try to import "postgres.h" and "pg_types.h" to get access to certain constants, I get an error with a PostgreSQL file: "c.h"
"Typedef redefinition with different types ('size_t' (aka 'unsigned long') vs 'long')
The previous definition is in OS X 10.11 > user/include > MacTypes.h
So there are two headers with the same definition:
PostgreSQL c.h
typedef size_t Size
OSX MacTypes.h
typedef long Size
If I comment out the definition in the PostgreSQL file then the project compiles. But I would rather not have to do that.
Does anyone know a way around this?
I read somewhere about using a 'backend header' but so far I have not been able to figure this out.
Thanks in advance.

Related

Recursive include of files in OpenCL source under Xcode

I'm looking to build a host program calling OpenCL code running on my GPU device. The cl source has the following form:
#include "skip_mwc.cl"
typedef struct{ uint x; uint c; } mwc64x_state_t;
//blah...
If I get rid of the #include directive and copy/paste the content of "skip_mwc.cl" directly into this source, I can partially "build" and at least get some errors, showing that my compiler (clang9 cl compiler) can at least recognize the kernels code. With the #include approach I get the following error:
Build log::
<program source>:9:10: fatal error: 'skip_mwc.cl' file not found
#include "skip_mwc.cl"
I have checked and the file is there in the search paths, so I'm inclined to believe that my Xcode IDE doesn't index .cl files properly to perform automatic file inclusion (as in .c or .cpp).
I really want to avoid having to copy/paste source from one file into the other. Any suggestions from someone familiar with Xcode, who has encountered this problem and managed to solve it, are very welcome and needed.
Thanks,
A
Two possible solutions:
Set the -I include_dir compiler option in clBuildProgram(), see also this answer.
Read both files from C++ with fstream and string-concatenate their content.
Also see the option of embedding the OpenCL code into the executable via stringification macro.

Omnet++ make issues

I get the following error when compiling omnetpp-5.4.1, do I need to uninstall the libgles2-mesa-dev package ?
In file included from /usr/include/GL/gl.h:2055:
/usr/include/GL/glext.h:469:19: error: typedef redefinition with different types
('ptrdiff_t' (aka 'int') vs 'khronos_intptr_t' (aka 'long'))
typedef ptrdiff_t GLintptr;
^
/usr/include/GLES3/gl31.h:74:26: note: previous definition is here
typedef khronos_intptr_t GLintptr;
^
In file included from osgviewer.cc:27:
In file included from /usr/include/arm-linux-gnueabihf/qt5/QtGui/QOpenGLFunctions:1:
/usr/include/arm-linux-gnueabihf/qt5/QtGui/qopenglfunctions.h:60:16: error:
cannot combine with previous 'double' declaration specifier
typedef double GLdouble;
^
/usr/include/osg/GL:129:38: note: expanded from macro 'GLdouble'
#define GLdouble double
^
3 errors generated.
This seems to be an issue with the system headers. If you do not need OpenSceneGraph/osgEarth support, you can turn it off in the configure.user file and the re-configure/rebuild omnet. That will exclude the OSG specific files from the build process. (if you do not need the graphical environment (Qtenv) you can even turn off that in the configure.user which will prevent also linking with Qt libs).

'value' is not a member of boost::mpl::aux::wrapped_type...when creating a mex function

I am using an extensive piece of code which compiles in Windows and Linux with gcc>=4.7. It is a utility to seamlessly generate mex functions in Matlab from m-scripts written by someone. I am having trouble compiling a short c script (not provided here) in Mac os x. I am using gcc-4.8 with C++11. It uses Boost library only for headers. The piece of utility code where it gets stuck is:
/* gets mxClassID, given C type>
eg. mx_class_id<float>()*/
template<typename T>
struct mx_class_id
{
operator mxClassID()
{
return static_cast<mxClassID>(boost::mpl::at<mxInverseTypeMap,T>::type::value);
}
};
required by
template<typename T>
mxArray* mxCreateScalar(const T & val)
{
//mxClassID cid=static_cast<mxClassID>(boost::mpl::at<mxInverseTypeMap,T>::type::value);
mxArray * arr=mxCreateNumericMatrix(1,1,mx_class_id<T>(),mxREAL);
mxSetValue(arr,val);
return arr;
}
What am I missing? Is it conflicting with built-in clang libraries? Or is it a header not specified (boost/mpl/at.hpp is included)? As I mention it does compile in Matlab for Windows and Linux.I have tried boost 1.51.0 (this is what we use) and also 1.56.0 (this is what Matlab uses) but I get the same error message.
The code I use to compile is
mex -v /usr/local/bin/gcc-4.8 -I path-to-boost-library -I path-to-private-library -I /usr/local/lib -std=C++11 script.cc
Here is the error message I am getting:
error: 'value' is not a member of 'boost::mpl::aux::wrapped_type <
boost::mpl::aux::type_wrapper < mpl_::void_> > ::type {aka
mpl_::void_}'
Any pointers or help appreciated. Thanks
This was resolved by the conflicting use of 'size_t' and 'unsigned long int'.
I think in Linux, Windows, size_t was employed in the code with the assumption it to be uint64_t. And it compiled in both.
However, for mac os x, it is either size_type or unsigned long int. This especially created problem because the code was matching c type to Matlab mex type with one-to-one mapping. In inverse mapping, with the use of size_t this one-to-one mapping was getting lost and instead became many-to-one. Once that was addressed it was easy to fix the rest.

Objective C interface declaration

i'm trying a simple academic program where an interface is declared as:
#import <objc/Object.h>
#interface Saludador:Object{
char* saludo;
}
- init;
- (void)setSaludo:(char*)unSaludo;
- (void)setSaludo:(char*)unSaludo y:(char*)unaColetilla;
- (void)saluda;
#end
When I try to compile the .m file i get the error:
error: cannot find interface declaration for 'Object', superclass of 'Saludador'
I really don't know why, i'm compiling on the terminal window in a mac OSX 10.9.
thanks for the help
Object is the OBJC_ROOT_CLASS for ObjC 1.0, for ObjC 2.0 use NSObject and #import <Foundation/Foundation.h>. You'll also have to add the -framework Foundation as a compiler flag if you are compiling using clang or gcc on the command line.
See the header file Object.h:
#if __OBJC__ && !__OBJC2__
__OSX_AVAILABLE_STARTING(__MAC_10_0, __IPHONE_NA)
OBJC_ROOT_CLASS
#interface Object
Note the #if __OBJC__ && !__OBJC2__.
EDIT:
I actually managed to find that: When writing code that is based upon the Foundation framework, that root class is typically NSObject in an old document... The OBJC_ROOT_CLASS got me confused, so even if you're using ObjC 1.0 it's still NSObject.

Unknown error when compiling Clang 3.3 with Mingw

I'm not able to compile clang(3.3) using MinGW 4.8.1. The following error always pops-up when 70% build is complete:
clang/lib/Basic/FileManager.cpp includes sys/stat.h, which defines #define stat _stat64i32 (actually there are a few other defines in between, but you get the idea ;)
clang/include/clang/Basic/FileManager.h does not include sys/stat.h; instead only has a forward-declaration.
Hence, while parsing the header, the forward declaration is used (struct stat)
But when it finally arrives at the implementation, the preprocessor will kick in and replace struct stat with struct stat64i32. Hence the mismatch.
The best solution would be to change the forward declaration in the header to instead include sys/stat.h. (I didn't actually test if it will compile then)
The current trunk does not contain the code anymore.
Update: regarding off64_t. This is defined in _mingw_off_t.h these days as:
#ifndef _OFF64_T_DEFINED
#define _OFF64_T_DEFINED
__MINGW_EXTENSION typedef long long _off64_t;
#if !defined(NO_OLDNAMES) || defined(_POSIX)
__MINGW_EXTENSION typedef long long off64_t;
#endif
#endif /*_OFF64_T_DEFINED */
So you probably want to define _POSIX before including io.h (or stdio.h)

Resources