XPost: linux.debian.devel.release
From:
[email protected]
(You forgot to cc the bts for the bug in question)
On Wed, Aug 18, 2004 at 04:41:13PM +0200, Steinar H. Gunderson wrote:
[Cc-ing debian-release to reach an RM; please keep the discussion on the bug
as I'm not subscribed to -release.]
On Wed, Aug 18, 2004 at 09:21:34AM -0500, Dirk Eddelbuettel wrote:
But when there is no shared one, the static one is used, which simply does >> not work; this is not pvm's fault. The rpvm configure script assumes that if
Sure is pvm's fault: You are violating Policy by not providing a shared lib.
*sigh* This is obviously hard. Let me summarize:
- rpvm should NOT check for a static library if it cannot use a static
library. This is a bug in rpvm upstream.
Nope: rpvm can only assume static libs, as the rest of the world uses only static libs. We are different, and can be different as __the combination of -Lpath/to/libfoo -lfoo inferred from static libs works for shared libs too__ provided there are working shared libs.
Which is why Policy requires working shared libs.
Which you don't provide.
- pvm should build a shared library for libgpvm3 as of Debian policy (but see
below).
Please provide a shared library.
Would an RM please step in here and assist? To summarize: rpvm refuses to work with static PVM libraries on some (non-i386) platforms. (Due to an rpvm bug, it does not detect this at configure time; this works by accident on i386 and some other platforms but fails on others.) PVM upstream only provides static libraries; Debian PVM has provided a shared libpvm3 for ages but no shared libgpvm3. I am rather reluctant to hacking a shared libgpvm3 into a build system I am not intimately familiar with before sarge (I have not maintained pvm all that long), even though lack of shared libraries is a policy violation (or at least so it seems), as this has obviously been OK with the world for ~3-4 years, and I don't want to possibly break pvm for sarge.
Pvm is broken for sarge AFAICT. I'd expect your mix of shared and static to break with way more packages that just rpvm (which happens to rely on
dyn.lib. loading to extend the functionality of GNU R at run-time).
I don't see what wasting precious RM time gains us here, other than getting
PVM completely blown out of sarge unless fixed.
Dirk
--
Those are my principles, and if you don't like them... well, I have others.
-- Groucho Marx
--
To UNSUBSCRIBE, email to
[email protected]
with a subject of "unsubscribe". Trouble? Contact
[email protected]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)