rubygem-passenger - FTBFS on f20 - need help

Lars Seipel lars.seipel at
Wed Sep 18 23:45:57 UTC 2013

On Wed, Sep 18, 2013 at 03:29:19PM -0500, Troy Dawson wrote:
> What is a good way to track down a solution to "error: reference to
> 'uint32_t' is ambiguous"?

Sorry for the multiple mails but after looking at the source I think I
see the actual problem. So in e.g. ext/common/Utils/MessageIO.h we have:

#include <boost/cstdint.hpp>
using namespace std;
using namespace boost;
use uint32_t <- error: reference to 'uint32_t' is ambiguous

The bundled boost cstdint header is including stdint.h on systems that
have it.  So ::uint32_t is provided by that. Additionally it emits
typedefs for the stdint types in the boost namespace with a declaration
conflicting with glibc's. As the passenger code is importing the boost
namespace 'uint32_t' could refer to ::uint32_t (from stdint.h included
through boost) or boost::uint32_t. That's what leads to the error.

Looking at our system boost cstdint.hpp it is doing something smarter.
Instead of coming up with its own uint32_t it's just referring to the
one from stdint.h (by means of a using ::uint32_t; declaration), so it
can't ever conflict.

After looking at the passenger-bundled boost header (instead of only
cpp's output) its intention seems to be the same but it's broken. Our
boost RPM carries a patch that fixes it. Ah, the joys of bundled
libraries.  ;-)

You could apply that patch to the bundled boost copy to fix the issue.
Another way would be to just delete the bundled ext/boost/cstdint.hpp
file in %prep and let it pick up the system cstdint.hpp. You'd obviously
have to buildrequire: boost-devel for that.

Hope that helps,

More information about the devel mailing list