Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Problems building ohNet on Mac OS X Mavericks
10-02-2014, 10:02 AM
Post: #1
Problems building ohNet on Mac OS X Mavericks
I recently updated my Mac from Lion to Mavericks. The update process required me to install an updated version of Xcode with a new C/C++ compiler (clang instead of gcc - see this page). This causes the following build failures:

1) Compiler messages about redefinition of parameter 'restrict'. Here's an example:

Code:
gcc -fPIC -o Build/Obj/Mac-x64/Release/Ascii.o -c -fexceptions -Wall  -pipe -D_GNU_SOURCE -D_REENTRANT -DDEFINE_LITTLE_ENDIAN -DDEFINE_TRACE -g -O2 -fvisibility=hidden -DPLATFORM_MACOSX_GNU -arch x86_64 -mmacosx-version-min=10.4 -std=c++0x -D__STDC_VERSION__=199901L -Werror -IBuild/Include/  OpenHome/Ascii.cpp
In file included from OpenHome/Ascii.cpp:1:
In file included from Build/Include/OpenHome/Private/Ascii.h:4:
In file included from Build/Include/OpenHome/Private/Standard.h:5:
In file included from Build/Include/OpenHome/Exception.h:5:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1/exception:42:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1/bits/c++config.h:41:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1/bits/os_defines.h:61:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/unistd.h:595:47: error:
      redefinition of parameter 'restrict'
void     swab(const void * __restrict, void * __restrict, ssize_t);
                                              ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/sys/cdefs.h:198:20: note:
      expanded from macro '__restrict'
#define __restrict      restrict
                        ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/unistd.h:595:28: note:
      previous declaration is here
void     swab(const void * __restrict, void * __restrict, ssize_t);
                           ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/sys/cdefs.h:198:20: note:
      expanded from macro '__restrict'
#define __restrict      restrict

This appears to be caused by the compiler flags '-std=c++0x -D__STDC_VERSION__=199901L'. In cdefs.h, the macro variable '__restrict' is expanded to either 'restrict' or nothing, depending on the result of the test '#if __STDC_VERSION__ < 199901'. As the value of __STDC_VERSION__ has been set to 199901L, '__restrict' is expanded to 'restrict', which is illegal. I worked around this by adding nocpp11=yes to the make command.

2) Unresolved linker references when linking libohNet.dylib. The solution is to add the flag -mmacosx-version-min=10.6 to the platform_linkflags variables on lines 160 and 165 of Makefile (see this page).

3) Missing include files. The paths in the includes_jni variable on line 315 of Makefile are no longer valid. They require a lengthy prefix which is currently

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk

I think the best solution for this is to add the prefix ${MACOSX_SDK} to lines 315 and 316 of Makefile and for the user to define the prefix value (if needed) as an environment variable. If this environment variable isn't set, the current absolute paths will be used. Note: I have added this prefix on line 316 as well as line 315 to ensure that the library and header files come from the same location. Without this, the library and header files might come from different versions of Java.

4) ohNetJni compilation failures. The -Wall -Werror flags produce an error when a variable is assigned to itself, which is done extensively by the .c files in the Java bindings. The solution is to change -Wall to -Wall -Wno-self-assign on line 335 of Makefile.

5) A warning is produced about the -pthread option on g++ when linking. As this is only a warning, I haven't attempted to eliminate it in this set of changes. Could this option be removed completely for Mac OS X, or is it needed for linking when building on an older level of Mac OS X?

As I no longer have a Lion system available, I can't be sure whether changes 2) and 4) will work OK when building ohNet on older levels of Mac OS X. Change 3) is definitely backward compatible.

I am hoping that the binaries I've built will run on older versions of Mac OS X (Snow Leopard, Lion and Mountain Lion), but I'm unable to verify this myself. I'm planning to release these binaries as part of a MinimServer update later today, so I'm sure I'll get some quick user feedback if there's a problem.

Here is the diff for my Makefile changes:

Code:
--- \ohnet\ohNet-ohNet_1.0.1028\Makefile    2014-02-06 17:39:51.000000000 +0000
+++ Makefile    2014-02-09 18:20:48.000000000 +0000
@@ -157,12 +157,12 @@
    linkopts_ohNet = -Wl,-install_name,@loader_path/libohNet.dylib
    ifeq ($(mac-64),1)
        platform_cflags = -DPLATFORM_MACOSX_GNU -arch x86_64 -mmacosx-version-min=10.4
-        platform_linkflags = -arch x86_64 -framework CoreFoundation -framework SystemConfiguration
+        platform_linkflags = -arch x86_64 -framework CoreFoundation -framework SystemConfiguration -mmacosx-version-min=10.6
        osbuilddir = Mac-x64
        openhome_architecture = x64
    else
        platform_cflags = -DPLATFORM_MACOSX_GNU -m32 -mmacosx-version-min=10.4
-        platform_linkflags = -m32 -framework CoreFoundation -framework SystemConfiguration        
+        platform_linkflags = -m32 -framework CoreFoundation -framework SystemConfiguration -mmacosx-version-min=10.6
        osbuilddir = Mac-x86
        openhome_architecture = x86
    endif
@@ -312,8 +312,8 @@
publicjavadir = OpenHome/Net/Bindings/Java/

ifeq ($(platform), IntelMac)
-    includes_jni = -I/System/Library/Frameworks/JavaVM.framework/Headers -I/usr/include/malloc
-    link_jvm = /System/Library/Frameworks/JavaVM.framework/JavaVM
+    includes_jni = -I${MACOSX_SDK}/System/Library/Frameworks/JavaVM.framework/Headers -I${MACOSX_SDK}/usr/include/malloc
+    link_jvm = ${MACOSX_SDK}/System/Library/Frameworks/JavaVM.framework/JavaVM
    javac = /usr/bin/javac
    jar = /usr/bin/jar
else
@@ -332,7 +332,7 @@
    jar = $(JAVA_HOME)/bin/jar
endif

-java_cflags = -fexceptions -Wall $(version_specific_java_cflags) -Werror -pipe -D_GNU_SOURCE -D_REENTRANT -DDEFINE_$(endian)_ENDIAN -DDEFINE_TRACE $(debug_specific_cflags) $(platform_cflags)
+java_cflags = -fexceptions -Wall -Wno-self-assign $(version_specific_java_cflags) -Werror -pipe -D_GNU_SOURCE -D_REENTRANT -DDEFINE_$(endian)_ENDIAN -DDEFINE_TRACE $(debug_specific_cflags) $(platform_cflags)
jarflags = cf
dirsep = /
prefix = /usr/local
Find all posts by this user
10-02-2014, 05:08 PM
Post: #2
RE: Problems building ohNet on Mac OS X Mavericks
Thanks for this. Our build slaves aren't yet on Mavericks so we'll have to think about whether to add yet more build flags to select MacOS versions or use your patch as-is and update our slaves.

I'll get back to you on this.
Find all posts by this user
14-03-2014, 03:24 AM (This post was last modified: 14-03-2014 03:50 AM by DLNAUser.)
Post: #3
RE: Problems building ohNet on Mac OS X Mavericks
Also I couldn't find libohNetJni.dylib(or libohNet.jnilib) in all the builds for Mac OS.
Yes, I do see libohNet.dylib, but if want JNI binding, then I couldn't find it.

Looks like I need to build from, which I think is too much if somebody just want to try ohNet out.

Would anyone wants to share libohNetJni.dylib (or libohNet.jnilib) to me??
Find all posts by this user
08-10-2014, 06:57 PM
Post: #4
RE: Problems building ohNet on Mac OS X Mavericks
(10-02-2014 05:08 PM)simonc Wrote:  Thanks for this. Our build slaves aren't yet on Mavericks so we'll have to think about whether to add yet more build flags to select MacOS versions or use your patch as-is and update our slaves.

I'll get back to you on this.

I tried this again recently with the latest Makefile and the latest version of Xcode (6.0.1).

The changes in this commit have fixed the problems with building the ohNetDll target but not the OhNetJni target. One of the changes in this commit is to change -mmacosx-version-min=10.4 to -mmacosx-version-min=10.7 and this seems to imply that the resulting ohNet binary won't run on Mac OS X 10.6 (Snow Leopard). Is this correct? If so, I will need to drop support for Snow Leopard in MinimServer.

To get ohNetJni to build, I needed to make the same changes as I described in my earlier post of 10th February (see attached patch). It would be helpful if you could apply these changes so I don't need to reapply them every time I do a checkout and build. I don't think they would cause any problems when building on earlier versions of Mac OS X or Xcode. Many thanks!


Attached File(s)
.zip  mavericks.zip (Size: 607 bytes / Downloads: 1)
Find all posts by this user
08-10-2014, 09:14 PM (This post was last modified: 08-10-2014 09:56 PM by simonc.)
Post: #5
RE: Problems building ohNet on Mac OS X Mavericks
(08-10-2014 06:57 PM)simoncn Wrote:  I tried this again recently with the latest Makefile and the latest version of Xcode (6.0.1).

The changes in this commit have fixed the problems with building the ohNetDll target but not the OhNetJni target. One of the changes in this commit is to change -mmacosx-version-min=10.4 to -mmacosx-version-min=10.7 and this seems to imply that the resulting ohNet binary won't run on Mac OS X 10.6 (Snow Leopard). Is this correct? If so, I will need to drop support for Snow Leopard in MinimServer.

Yes, its correct that ohNet now supports Lion onwards only (i.e. no Snow Leopard). Current betas of Kazoo and Kazoo Server have dropped support for Snow Leopard as a consequence.

(08-10-2014 06:57 PM)simoncn Wrote:  To get ohNetJni to build, I needed to make the same changes as I described in my earlier post of 10th February (see attached patch). It would be helpful if you could apply these changes so I don't need to reapply them every time I do a checkout and build. I don't think they would cause any problems when building on earlier versions of Mac OS X or Xcode. Many thanks!

I must have missed this because our build slaves don't build the Java bindings. I'll try to apply the changes tomorrow.
Find all posts by this user
09-10-2014, 01:15 PM
Post: #6
RE: Problems building ohNet on Mac OS X Mavericks
(08-10-2014 06:57 PM)simoncn Wrote:  To get ohNetJni to build, I needed to make the same changes as I described in my earlier post of 10th February (see attached patch). It would be helpful if you could apply these changes so I don't need to reapply them every time I do a checkout and build. I don't think they would cause any problems when building on earlier versions of Mac OS X or Xcode. Many thanks!

The changes are now committed so should be available to you this evening.
Find all posts by this user
12-10-2014, 04:54 PM
Post: #7
RE: Problems building ohNet on Mac OS X Mavericks
(08-10-2014 09:14 PM)simonc Wrote:  Yes, its correct that ohNet now supports Lion onwards only (i.e. no Snow Leopard). Current betas of Kazoo and Kazoo Server have dropped support for Snow Leopard as a consequence.

In this case, why is ohNet still publishing both 32-bit and 64-bit Mac binaries? Lion is 64-bit only, so how/where could a 32-bit binary be used?

I'm asking this to find out whether I can safely drop 32-bit Mac builds for MinimServer.
Find all posts by this user
12-10-2014, 09:33 PM (This post was last modified: 12-10-2014 09:34 PM by simoncn.)
Post: #8
RE: Problems building ohNet on Mac OS X Mavericks
(08-10-2014 06:57 PM)simoncn Wrote:  I don't think they would cause any problems when building on earlier versions of Mac OS X or Xcode.

Unfortunately, the -Wno-self-assign option causes a compile error when I build the Java bindings for Linux on gcc 4.1. It seems OK on gcc 4.6.3. As this option was added to fix a Mac-specific problem, I think the safest solution is to apply this option only to Mac builds and not to non-Mac builds. The attached patch does this by creating a new variable platform_java_cflags and setting it differently for Mac and non-Mac builds.


Attached File(s)
.zip  javacflags.zip (Size: 657 bytes / Downloads: 1)
Find all posts by this user
13-10-2014, 08:16 AM
Post: #9
RE: Problems building ohNet on Mac OS X Mavericks
(12-10-2014 09:33 PM)simoncn Wrote:  Unfortunately, the -Wno-self-assign option causes a compile error when I build the Java bindings for Linux on gcc 4.1. It seems OK on gcc 4.6.3. As this option was added to fix a Mac-specific problem, I think the safest solution is to apply this option only to Mac builds and not to non-Mac builds. The attached patch does this by creating a new variable platform_java_cflags and setting it differently for Mac and non-Mac builds.

Thanks, I've applied your changes locally.
Find all posts by this user
16-10-2014, 07:09 PM
Post: #10
RE: Problems building ohNet on Mac OS X Mavericks
(12-10-2014 04:54 PM)simoncn Wrote:  
(08-10-2014 09:14 PM)simonc Wrote:  Yes, its correct that ohNet now supports Lion onwards only (i.e. no Snow Leopard). Current betas of Kazoo and Kazoo Server have dropped support for Snow Leopard as a consequence.

In this case, why is ohNet still publishing both 32-bit and 64-bit Mac binaries? Lion is 64-bit only, so how/where could a 32-bit binary be used?

I'm asking this to find out whether I can safely drop 32-bit Mac builds for MinimServer.

I am proceeding on the assumption that it is safe to drop 32-bit Mac builds of MinimServer with the current version of ohNet. I'm still not sure why ohNet is continuing to publish 32-bit Mac binaries and support 32-bit Mac builds in Makefile. If I am missing something, please let me know.
Find all posts by this user


Forum Jump: