Hi,
On Thu, 2016-01-07 at 17:43 -0500, John Harvey wrote:
> H
> I'm having a bit of trouble building SFCGAL / CGAL, and I wanted to
> ask a
> couple of questions about the toolchain used to build the code.
> Specifically, I was wondering about builds on EL-6.
I could not build SFCGAL on RHEL 6, due to boost issues, which you also
encountered.
> 1) For EL-6 builds, what version of rpmbuild is installed (and how is
> it installed)?
> The latest version I found via yum install is 4.8.
Other than that, we don't use any toolchain which is not included in
the repo. If we make an exception, we add it to our repo.
$ rpm -qv rpm-build
rpm-build-4.8.0-47.el6.x86_64
> With the spec-file as written, I encounter the following build errors
> on
> SFCGAL:
>
> File must begin with "/": GLPLv2
> File must begin with "/": LICENSE
>
> From my research, this happens because non-absolute paths were added
> in RPM 4.11. So, the 4.8 standard install causes problems.
Err, actually it is the new %license macro that was introduced
recently, and I forgot to add conditionals. See line 50 in here as an
example of what I missed:
http://git.postgresql.org/gitweb/?p=pgrpms.git;a=blob;f=rpm/redhat/9.5/
pgcenter/EL-
6/pgcenter.spec;h=de5f77709b0be85bbc7bd50bbc8678b4609247ef;hb=f5c0cfbbf
53c0a9b69689b3e4034c8fb44620e7f#l50
> 2) For EL-6 builds, what version of boost-devel is installed (and how
> is it installed)?
As above: We all stick to OS supplied packages, so:
$ rpm -qv boost-devel
boost-devel-1.41.0-27.el6.x86_64
We also use EPEL repo a lot.
> It seems like Boost is a tricky thing on EL-6. The latest RPM that
> is
> available for installation is 1.41.0. However, without a later
> version, there's a compile error on CGAL 4.7:
>
> /usr/include/CGAL/Kd_tree.h:34:37: fatal error:
> boost/container/deque.hpp: No such file or directory
Yep, I got the same.
> From what I gather, deque.hpp has been relocated elsewhere in code
> for later versions of boost. And, while there is a boost148 package
> available, it unfortunately puts the Boost include files into
> /usr/include/boost148 instead of /usr/include/boost. Unless there's
> a way to notify the build of this differing path, the only workaround
> that I've found is to build a new version of boost (i.e. 1.53.0 from
> source). So I'm curious how the PGDG toolchain handles this case.
We don't do it, as it will break more dependencies. For the same
reason, we disabled raster support on RHEL 6 RPMs.
Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR