Adding HHVM Portfile

[c9s (Yo-An Lin)]

here is the portfile for HHVM

[c9s (Yo-An Lin)]

patch file

[ryandesign (Ryan Carsten Schmidt)]

Some remarks:

• The maintainers line must be your valid email address in our obfuscated host:user format.
• A build dependency on cmake should not be added since the cmake portgroup already does so
• The text you have written in the description field would make a good long description, if you remove the URL (set that in the homepage variable instead). Write a shorter description.
• Since this software is hosted at github, the github portgroup should be used.
• Fetching from master (which you do in the hhvm-devel subport) is not permitted. All ports must use specific upstream versions, tags, or commits.
• Why has the compiler been set to macports-gcc-4.8? Usually that is not desired.
• I see mysql55 is being used. There should be variants for each version of MySQL offered by MacPorts (mysql51, mysql55, mysql56, percona, mariadb, mariadb-10.0, mariadb-10.1)
• I see lots of specific library version numbers mentioned in the configure.args; that should be avoided.
• I'm surprised at the invocation of install_name_tool in the pre-destroot block; I did not know that we have a Tcl wrapper around that system command. Ideally, fix the cmake files so that manually editing the install_name later is not necessary.

[larryv (Lawrence Velázquez)]

Replying to ryandesign@…:

I'm surprised at the invocation of install_name_tool in the pre-destroot block; I did not know that we have a Tcl wrapper around that system command.

Pretty sure we don’t.

[c9s (Yo-An Lin)]

Here is the updated Portfile:

​https://github.com/c9s/hhvm-macports/blob/master/facebook/hhvm/Portfile

• gcc 4.8 is required because hhvm can't be built with clang (the built-in compiler on Mac OS X)
• mysql55 is required because hhvm requires mysql55 (not percona, mariadb or anything else)
• do you have any suggestion to avoid version number for this line?

-DLIBIBERTY_LIB=${prefix}/lib/gcc48/x86_64/libiberty.a

• install_name_tool system call is fixed.

[larryv (Lawrence Velázquez)]

Replying to cornelius.howl@…:

• gcc 4.8 is required because hhvm can't be built with clang (the built-in compiler on Mac OS X)

Seriously? Does it interface with any external C++ libraries? If so, this won’t work unless all the external libraries were also built with GCC.

• do you have any suggestion to avoid version number for this line?

-DLIBIBERTY_LIB=${prefix}/lib/gcc48/x86_64/libiberty.a

There’s no way around that.

[c9s (Yo-An Lin)]

It uses some gcc48 extensions like (features.h) which is not supported by clang, so we need gcc48 extensions to build the binary.

External libraries built by clang are compatible with gcc48 binary. (all my other libraries were built with clang)

[larryv (Lawrence Velázquez)]

Replying to cornelius.howl@…:

External libraries built by clang are compatible with gcc48 binary. (all my other libraries were built with clang)

They are binary-compatible but will use different C++ runtimes (clang++ uses libc++ abi, g++ uses libsupc++) and thus cannot be mixed. Doing so might appear to work at build time but will manifest at runtime in subtle but unpleasant ways.

[neverpanic (Clemens Lang)]

system "install_name_tool -change libjemalloc.1.dylib ${prefix}/lib/libjemalloc.1.dylib ${prefix}/bin/hhvm"

in post-destroot changes a file in ${prefix}. The destroot phase must not touch files in ${prefix} (and actually, sandboxing will prevent it from doing so). Please prefix the last argument of the install_name_tool call with ${destroot}.

I'm pretty sure this will end up mixing libc++ and libstdc++ in the same process, e.g. coming from mysql55-connector-cpp and gcc. Even if it links (for whatever reason), it will crash at runtime with weird runtime library errors. If the software can only be compiled with GCC, maybe that's a good place to use ​http://stackoverflow.com/questions/22228208/using-g-with-libc?

[c9s (Yo-An Lin)]

Ah, I remind that I compiled boost with gcc48, that's the only one library that I compiled with gcc48.

And the mysql55-connector-cpp seems not used by HHVM.

[c9s (Yo-An Lin)]

Portfile updated:

1. Replace ${prefix} with ${destroot}

[neverpanic (Clemens Lang)]

Well, if hhvm links against boost and must be built with gcc48 that's a deal-breaker. Boost in MacPorts can currently only be built with GCC because of a mistake that will be fixed. Compiling boost with GCC will break all other software that uses it and is compiled with clang.

As I said, the binary must use libc++ in the end on platforms where that is the default (i.e., 10.9 and later). The approach linked from the Stack Overflow post might work here, the one currently in the Portfile will most certainly not.

[c9s (Yo-An Lin)]

though hhvm 3.2 can only be built with gcc, but in the future, 3.3 will be able to be built with clang.

what if we show a note to notice user that boost must be compiled with gcc48 before 3.3 is out?

[neverpanic (Clemens Lang)]

Replying to cornelius.howl@…:

though hhvm 3.2 can only be built with gcc, but in the future, 3.3 will be able to be built with clang.

what if we show a note to notice user that boost must be compiled with gcc48 before 3.3 is out?

The active_variants 1.1 PortGroup can do that, but it's not a valid solution because installing boost compiled with GCC *will* break other ports (e.g., if they are downloaded in binary form from our buildbot). See #44911, #44856 for examples of why using boost+gcc* is not a good idea. We could, in theory, install a private copy of boost compiled with GCC within the hhvm port. Wrapping GCC so it uses libc++ as explained in the stack overflow link is a lot easier than that, though.

[c9s (Yo-An Lin)]

I am trying to build HHVM 3.2 with clang, see if it works with clang. :)

[c9s (Yo-An Lin)]

OK, the final linking phase didn't work. what if we link hhvm with boost statically? e.g. build another boost with gcc and static linking with it.

[smaxims@…]

+1

[c9s (Yo-An Lin)]

Hi there,

HHVM 3.11 now can be compiled with boost with "-no_static"

[c9s (Yo-An Lin)]

Here is the build script of 3.11

​https://gist.github.com/46d57e4be2c3b8d98fd1

However hhvm should be built with macports clang, the build-in clang doesn't support thread-local storage. It will throw error "thread-local storage is not supported in this target"