Bug#570709: packaging hhvm
>You have access to upstream source VCS? If not, an own Git repository
>under the hood of GitHub would be nice. It has the advantage that
>users may report bugs directly to FB.
Ok, let me look into it. I liked pulling from theirs in the build
instructions and it looked official.
>But let me rewind first. You can create a basic Debian chroot environment
>with:
>debootstrap --arch selected_arch sid /place/the/chroot/dir/here/
>http://http.debian.net/debian/
>Where selected_arch can be i386 or amd64 (or any architecture FB may use).
>Then download, build and install my patched libevent 1.4.x to that
>chroot environment.
>The following build dependencies are identified for HHVM 2.0:
>cmake
>binutils-dev
>libevent-dev
>libreadline-dev
>libedit-dev
>libncurses5-dev
>libbz2-dev
>libxml2-dev
>libmemcached-dev
>libicu-dev
>libgd-dev
>libcap-dev
>libmcrypt-dev
>libcurl4-gnutls-dev
>libtbb-dev
>libc-client2007e-dev
>libpcre3-dev
>libinotifytools0-dev
>libmysqld-dev
>libboost1.54-dev
>libboost-system1.54-dev
>libboost-program-options1.54-dev
>libboost-filesystem1.54-dev
>libboost-regex1.54-dev
>libgoogle-glog-dev
>libelf-dev
>libdwarf-dev
>libonig-dev
>Yes, that page is highly outdated. I think Standards-Version 3.9.2 is
>obsoloted now (the current one is 3.9.5) and that page uses 3.8.1!
>Debhelper level should be 9 and not 7, debian/rules may use the short
>debhelper format.
Yikes. Can yo update it please?
>Last but not least that wiki forces HHVM to be amd64
>only. Any reason to do that? Any known problem to run HHVM on
>kfreebsd-*, mips{,el}, sparc or any other archs that Debian supports?
Absolutely. HHVM is a Just-In-Time compiler which emits assembly code into
memory then executes it. We currently only emit 64bit x86. We are looking
at other backends, but they require a lot of effort to implement and
optimize.
>To answer your question, the proper package build is using pbuilder or
>sbuild (I prefer the former). But until I can't build HHVM by hand, I
>don't want to put time into packaging. I've just realized that HHVM
>embeds other codes under hphp/third_party/ , even folly which is an
>other FB FOSS software and should be packaged separately.
Folly is pulled in with a git submodule, but yes, the others are copied in.
> Especially
>that now (for me) building HHVM fails with:
>Linking CXX executable gen-class-map
>CMakeFiles/gen-class-map.dir/gen-class-map.cpp.o: In function
>`folly::TypeError::TypeError(std::string const&,
>folly::dynamic::Type)':
>gen-class-map.cpp:(.text._ZN5folly9TypeErrorC2ERKSsNS_7dynamic4TypeE[_ZN5f
>olly9TypeErrorC5ERKSsNS_7dynamic4TypeE]+0x2a):
>undefined reference to
>`folly::dynamic::TypeInfo<std::vector<folly::dynamic,
>std::allocator<folly::dynamic> > >::name'
>[...and so on...].
>
>But the embedded folly was compiled normally (the problem can be that
>it's a static library but gen-class-map linking may look for a dynamic
>one):
>Linking CXX static library ../../../bin/libfolly.a
>[ 3%] Built target folly
>
>This further emphasize that folly[1] should be packaged separately.
Hmm, try
rm CMakeCache.txt
And follow the instructions
https://github.com/facebook/hhvm/wiki/Building-and-installing-HHVM-on-Debia
n-7 . That worked for me last week.
>System libsqlite3-dev should be used as well, instead of embedding it
>and so on. An other library which is in my hand in Debian and some
>extra compilation options may be discussed if needed.
Sure, we¹d be happy to take patches to do that. I think they are embedded
since those libraries aren¹t readily available easily and this is the best
way to alleviate developer pain.
Reply to: