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
thanks
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: