On 2011-04-12 06:57, Steve Langasek wrote:
Package: grads
Version: 2.0.a8-2
Severity: normal
Tags: patch
User: vor...@debian.org
Usertags: multiarch
Hi Alistair,
The grads package fails to build in a multiarch environment because it
hard-codes the paths to .so files it wants to link against. If instead it
allows the compiler to resolve the library paths via "-l" options, as in the
attached patch, the package builds fine. This is strongly preferred over
hard-coded paths, not only for multiarch but also for any other cases where
a user might like to rebuild the package against local versions of
libraries.
As there were two existing patches in debian/patches which partially dealt
with this issue, this patch drops one of these patches and uses the other to
fully address the problem.
Hi Steve,
I'm testing your fix, along with an upgrade to grads 2.0.a.9, and the
build breaks.
Whats happening is that supp_include_dir is no longer set; there are no
references
to supp* in Makefile.am or Makefile.in, but there are in the
autogenerated Makefile.
(This comes from the acinclude.m4, configure.ac in the main directory).
The build breaks because with supp_include_dir not included,
-I$(supp_include_dir)/geotiff breaks to -I/geotiff rather than
-I/usr/include/geotiff
and files are not found. So my first answer is to add
$(supp_include_dir) back,
but not $(supp_lib_dir).
But will this cause issues with multiarch?
Regards
Alastair
--
Alastair McKinstry ,<alast...@sceal.ie> ,<mckins...@debian.org>
http://blog.sceal.ie
Anyone who believes exponential growth can go on forever in a finite world
is either a madman or an economist - Kenneth Boulter, Economist.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
