[sldev] [VWR] Non standalone 64bit builds of http-texture

Robin Cornelius robin.cornelius at gmail.com
Wed Apr 1 02:51:19 PDT 2009


Hey everyone,

I've been playing with the http-texture branch in a "non-standalone"
capacity on a linux 64 bit host. As everyone knows this is an
unsupported combination and its usual for us on 64bit to build with
--standalone to use system supplied libraries. So i decided to see how
much pain was still involved to complete this process for building the
"LL way" on a 64bit system.

It turns out that the total pain is not that bad, I have noticed that
linux64 packages have appeared in install.xml quite a while back and
the ones that are listed there DO work fine, there are just a few
missing. By substituting the missing ones the build on a 64bit system
completes almost with out hitch (2 pretty minor issues related to
64bit ness already in jira and imported). All the other scripts work
and produce 1) a working viewer built on 64 bit 2) a distribution
tarball. SO everything looks pretty good, it just needs some one to
finish off the last few packages, push to S3 and update install.xml,
which I can't believe is that much work.

The particular packages that seem to be missing are:-

SDL
dbusglib
elfio
fontconfig
glib
google
gtk-atk-pango-glib
libuuid
ndofdev
tut

out of that list the only ones that seemed to break the build were
dbusglib,elfio,glib,gtk-atk-pango-glib and ndofdev.

Its possible that the remaining few were optional extras and cmake
excluded them or they got found in implicit search paths on my system
(SDL should have been a breaker). Anyway by just adding in the missing
header files the build completed successfully and produced a working
viewer. Although mozlib was not found for some reason but that is
listed as a linux64 package as well, but that needs checking.

So basically can we do something about the missing packages?  I've
opened a jira for this VWR-12656

This releases a bunch of pain and even opens the possibility of
automated 64bit builds of the http-texture branch.

Thanks

Robin


More information about the SLDev mailing list