compiling Proto 7 on Mac OS X 10.9.4

When I tried to compile proto 7 on Mac OsX 10.9.4 and I bumped into several problems,
so after succeeding in building it I decided to write this short post,
hoping that it will be useful to others users.

Problems:

  1. autogen.sh may get libtool name wrong.
  2. The standard compiler and linker shipped with Command Line Tools in Xcode (5.1.1) seem to have problems in compiling proto source code and interpreting the -rdynamic flag to export all symbols.

Solution:

1) I suggest the following patch to solve the first problem concerning autogen.sh


--- autogen.sh 2010-01-05 15:22:41.000000000 +0100
+++ autogenNew.sh 2014-09-12 18:19:57.000000000 +0200
@@ -6,7 +6,7 @@
rm -f configure

# select right libtoolize name:
-if [ `uname -s` = Darwin ]
+if hash glibtoolize 2> /dev/null
then
LIBTOOLIZE=glibtoolize
else

For those ones who do not know how to manage it,
copy and paste the plain code into a X.patch file and type:

patch < X.patch

2) Instead of trying to understand why clang gets stuck on compilation errors, I directly switched to gcc. I suggest having a user-compiled version of the GNU compiler, it turns to be useful in situations like this one.
Notice that in Command Line Tools ld '-rdynamic' as option for exporting all symbols is not recognized, so let's convert it in '-export-dynamic':

find . -type f -name "Makefile*" | xargs sed -i '' 's/-rdynamic/-export-dynamic/g'; find . -type f -name "configure" | xargs sed -i '' 's/export_dynamic_flag_spec=-rdynamic/export_dynamic_flag_spec=-export-dynamic/g'

Summarizing:

  1. Apply autogen.sh patch
  2. Convert '-rdynamic' flag into '-export-dynamic'
  3. Run configure (with parameters)
  4. Build (make) with gcc
Groups:

Comments

jakebeal

Thank you for the patch

Thank you for the patch --- I'm working on cutting a release 7.1 that patches these, and will check to see if I can understand and resolve the issue.  I may ask for your help in testing that it works on your machine as well.

The compiler issues come from a strengthening of the default warn vs. error in various compilers --- over the past few years, some previously accepted dubious C code practices have become warnings and now errors. This is why switching your compiler resolved the issue for you --- you switched to an earlier and less picky version. I have a patch that fixes these, which will go into 7.1.

f_dea

Sorry for cross-posting, the

Sorry for cross-posting, the other copy of the post can be deleted.

Yes sure, I can keep testing next patches/versions.

Concerning the error I agree with you, it seems that clang-503.0.40 is a little bit stricter than gcc-4.9.1: I found an interesting discussion here: http://clang.llvm.org/compatibility.html, in which several differences concerning the language compatibility are highlighted (maybe it can be used as starting point).

If you want I can test next versions with both compilers, to assure better compatibility.