[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#266837: rpvm_0.6.2-1_hppa: FTBFS: relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC

[Resending this to debian-ctte@lists.debian.org, as I was not subscribed at
 the time and thus the mail bounced]

reassign 266762 tech-ctte

On Fri, Aug 20, 2004 at 10:40:52AM +1000, Anibal Monsalve Salazar wrote:
> Invoking the ctte, as per sgunderson's suggestion. In another message
> edd didn't oppose to bring this matter to the ctte. I think, the three
> parties involved agree to request the ctte's opinion to this problem.

Trying to follow the procedure of http://www.debian.org/devel/tech-ctte here,
reassigning #266762 to the ctte. The discussion spans over multiple bugs, but
here is my current understanding of the dispute I've summarized into #266762
(which #266837 is merged into):

- pvm does, for historical reasons, provide a shared libpvm3 but no libgpvm3.
  (libpvm3 is the shared library used for almost all PVM programs, libgpvm3
  is a library supplementing libpvm3 with a few extra functions.) pvm
  upstream does only supply static libraries, and the shared libpvm3 is a
  Debian-specific extension; I guess the previous maintainer (I took over
  maintainership for pvm some time ago) simply forgot libgpvm3.
- rpvm, an extension for integrating GNU R with PVM, gets FTBFS bugs with
  current pvm in Debian, as it tries to do "gcc -shared -o rpvm.so <object
  files> -lpvm3 -lgpvm3", and -lgpvm3 resolves to libgpvm3.a, which fails on
  all platforms except i386 and arm (since libgpvm3.a is not built with
  -fPIC). rpvm's configure script never checks for the presence of shared
  libpvm3.so or libgpvm3.so files; first it tries to link to -lpvm3 and if
  that fails, it does "test -f /usr/local/lib/libpvm3.a" and then optionally
  a third place (PVM's library directory).
- Dirk Eddelbuettel claims that pvm is violating policy (section 8.3, I
  presume) by not providing a shared library for libgpvm3. Furthermore, he
  claims that the pvm package is broken for "mixing" shared and static
  libraries (ie. providing both shared and static libraries for libpvm3, but
  only static for libgpvm3). This is bug #266762.
- I claim that pvm is not violating policy section 8.3, as PVM's libraries
  are explicitly not intended for anything but static linking from upstream
  (section 8.3, third exception); this is simply for performance reasons.
  Anybody doing high-performance computing in a cluster would link statically
  to get lower call overhead, which is (AFAIK) the reason why PVM upstream
  only builds static libraries. Furthermore, I claim that the "mix" of static
  and shared libraries does not pose a problem at all; se my build log on
  hppa with all-static libraries in bug #266837.
- I intend to make a shared libgpvm3 part of the pvm package, but as this
  requires hacking into PVM's build process (which I am not intimately
  familiar with) I do not intend to do this and potentially destabilize pvm
  right before the sarge release.
- It should also be noted that there _was_ a bug in PVM that was at fault for
  some rpvm build failures (an unescaped call to "tr" in a shell script).
  This is bug #264403, but several of our arguments have been Cc-ed to that
  bug as well. This was fixed in pvm 3.4.2-12. I claim this is completely
  unrelated to the bug we're discussing here -- Dirk has claimed otherwise in
  the past, but I'm unsure of his current position on this.

In short, the question is: Must the pvm package provide a shared libgpvm3 or
not? If it does not, I intend to keep the pvm package as it is (except for
the "build for i386 on amd64 kernel" bug, which I will fix shortly, and which
is again a separate issue) for sarge.

> A serious bug, #266837, has been downgraded to whislist.

For the record, #266762 (which is the one I'm reassigning to debian-ctte) is
merged with #266837; it's the same dispute.

/* Steinar */
Homepage: http://www.sesse.net/

Reply to: