jeroen / protolite

Fast and Simple Object Serialization to Protocol Buffers
Other
48 stars 8 forks source link

Build fails under CENTOS 7 and Microsoft R Open 3.4.0 #5

Closed mjmg closed 7 years ago

mjmg commented 7 years ago

As Microsoft R Open 3.4.0 was released recently, I rebuilt my MRO CENTOS docker images based on that.

Upon installing OpenCPU 2.0.1 from source rpms, it fails with the following message:

* installing *source* package 'protolite' ...
** package 'protolite' successfully unpacked and MD5 sums checked
Found pkg-config cflags and libs!
Using PKG_CFLAGS= 
Using PKG_LIBS=-lprotobuf -lpthread  

Using libprotoc 2.5.0 from /usr/bin/protoc

** libs
Error in .shlib_internal(args) : 
  C++11 standard requested but CXX11 is not defined
* removing '/home/mockbuild/rpmbuild/BUILD/opencpu-server-2.0/opencpu-lib/build/protolite'

I'm assuming R/MRO 3.4.0 has better support for C++11 standard. But the gcc compiler from CENTOS 7 is really quite old.

What would be the workaround for this?

martynplummer commented 7 years ago

Looks like a bug in MRO to me. I unpacked the RPM microsoft-r-open-mro-3.4.rpm and looked in the file etc/Makeconf. This contains the following lines for C++ configuration:

CXX = g++
CXXCPP = $(CXX) -E
CXXFLAGS = -DU_STATIC_IMPLEMENTATIN -O2 -g $(LTO)
CXXPICFLAGS = -fpic
CXX1X =
CXX1XFLAGS =
CXX1XPICFLAGS =
CXX1XSTD = 

But this is out of date It is not the correct configuration for R 3.4.0 (Note also the spelling mistake).

In the source tarball for MRO the file etc/Makeconf.in is correct. It contains the lines

CXX = @CXX@ @CXXSTD@
CXXCPP = @CXXCPP0@
CXXFLAGS = @CXXFLAGS@ $(LTO)
CXXPICFLAGS = @CXXPICFLAGS@
CXX98 = @CXX98@
CXX98FLAGS = @CXX98FLAGS@
CXX98PICFLAGS = @CXX98PICFLAGS@
CXX98STD = @CXX98STD@
CXX11 = @CXX11@
CXX11FLAGS = @CXX11FLAGS@
CXX11PICFLAGS = @CXX11PICFLAGS@
CXX11STD = @CXX11STD@
CXX14 = @CXX14@
CXX14FLAGS = @CXX14FLAGS@
CXX14PICFLAGS = @CXX14PICFLAGS@
CXX14STD = @CXX14STD@
CXX17 = @CXX17@
CXX17FLAGS = @CXX17FLAGS@
CXX17PICFLAGS = @CXX17PICFLAGS@
CXX17STD = @CXX17STD@

As you can see, this contains many more CXX flags, reflecting the increased support for C++14, C++17 in R 3.4.0 and explicit flags for C++98 (Previously the default). Something went wrong with the creation of the MRO rpm. Microsoft do not make their source RPMs available, but I suspect an obsolete patch is being applied.

jeroen commented 7 years ago

Thank you for the debugging @martynplummer. I have reported this to @revodavid.

mjmg commented 7 years ago

Thanks also to @martynplummer

It's funny though that Microsoft blames this issue upstream https://github.com/Microsoft/microsoft-r-open/issues/26

aarongrider commented 7 years ago

I was mistaken! This one is our MRO bug :) I'll try to get a fix out soon.

aarongrider commented 7 years ago

We will targeting a fix for this in our next release. Unfortunately it's not as simple as just updating our compiler flags since we are using a different toolchain to enable support for older platforms.

In the meantime, you should be able to copy the correct flags into your /etc/Makeconf. The provided Makeconf configuration should work for CentOS 7.

Makeconf.txt

mjmg commented 7 years ago

@aarongrider Oh my what a messy patch....and I thought CXX1X is no longer honored on R 3.4.0?

From CRAN R 3.4.0 release notes:

An alternative compiler for C++11 is now specified with CXX11, not CXX1X. Likewise C++11 flags are specified with CXX11FLAGS and the standard (e.g., -std=gnu++11 is specified with CXX11STD.

Please do confirm that the exact file to replace is at "/usr/lib64/microsoft-r/3.4/lib64/R/etc/Makeconf" and this will also be valid on Debian/Ubuntu platforms.

Thanks for the quick reply though will be testing this soon.

I'm not sure if this issue can be considered closed.

aarongrider commented 7 years ago

It's a workaround for sure :) I wanted to get you going with a temporary fix. No need to replace the whole file, just replace the CXX flags. This should work for most distros but I've only tested it on Ubuntu 16 and CentOS 7 so far.

Like I said, we will have a more permanent fix soon!

The changes should go to: ${R_HOME}/etc/Makeconf.

Hope this helps.

mjmg commented 7 years ago

Protolite and a host of other packages is now working for my system using Microsoft R Open 3.4. Closing this issue.

The fix was for all instances of "CXX1X" should be replaced with "CXX11" in your

${R_HOME}/etc/Makeconf

for system changes or

~/.R/Makevars

for per user changes to resolve the

C++11 standard requested but CXX11 is not defined

error when building some packages that depend on C++11 code.

chendaniely commented 7 years ago

Just putting a reference to this issue https://github.com/Microsoft/microsoft-r-open/issues/26 since this post shows up in a google search for the c++11 problem.

Just a note: you have to make sure the right flags are in the Makeconf file, simply doing a find/replace of CXX1X with CXX11 isn't enough. the copy/paste solution mjmg has in the linked issue fixes the problem for me.

replacing the existing Makeconf with the one aarongrider provided above also did not work for me (yes I removed the .txt extension).

jmurray6 commented 6 years ago

@mjmg Just to clarify: does your fix include the changes on aarongrider's Makeconf, or not? I'm encountering the same issue on redhat and want to make the changes to install some R packages. I just want to make sure I'm using the right solution. Should I use aarongrider's Makeconf and AND THEN replace all instances of "CXX1X" with "CXX11"? Or should I skip his file and just replace the tags I have?

Thanks

jeroen commented 6 years ago

I think the problem has been fixed upstream, so perhaps the solution is just upgrading?

jmurray6 commented 6 years ago

Upgrading Microsoft R? I just upgraded to 3.4.1 and my Makeconf file still has CXX1X tags.

jeroen commented 6 years ago

So try upgrading to 3.4.2 ;)

jmurray6 commented 6 years ago

Ah jeez! That's not really an option for me at the moment so I will try the Makeconf changes in my development environment.

mjmg commented 6 years ago

@jmurray6 I used the Makeconf provided with MRO 3.4.1 and made the edits there. The issue was fixed upstream in MRO 3.4.2 and you can probably use the Makeconf provided there. https://github.com/Microsoft/microsoft-r-open/issues/26

However, I'm still stuck in 3.4.1 since it seems MRO 3.4.2 was not configured and built as a shared library not allowing me to build rApache. https://github.com/Microsoft/microsoft-r-open/issues/47