[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



On Fri, Aug 20, 2004 at 01:22:44PM +0200, Steinar H. Gunderson wrote:
> I think you've missed a point here (all times converted to UTC):
> 
> 2004-08-19 11:38: #266837 gets filed as a serious bug against rpvm.
> 2004-08-19 21:26: Dirk reassigns #266837 to pvm.
> 2004-08-19 21:30: I set #266837 to wishlist, to merge it with #266762.
> 
> As #266837 was assigned to pvm at that point, I cannot see how I would be
> tampering in someone else's packages.

Yes, I did miss that.

My apologies.

> > It's appropriate for 266762 to be wishlist, but that has no bearing
> > on 266837.
> 
> The entire discussion here is whether #266762 is wishlist or not. I claim it
> is; the rpvm people claim it is serious.

It's a serious bug for rpvm, it's a wishlist bug for pvm.

> > I know this leaves rpvm in an awkward state.  I'd suggest [for sarge]
> > making it build statically against pvm (maybe with strict requirements on
> > the associated installed version of pvm), and incorporating all the bulk
> > that implies.  Yes, this places a disproportionate storage requirement
> > on rpvm, but this close to release I think stupid simple changes are
> > better than more elegant but riskier changes.
> 
> The problem is, this is not possible: rpvm _must_ be a shared library (as far
> as I've understood, anyhow) to work, and a shared library _cannot_ link
> against a static library (well, a non-PIC-compiled one, anyway) on
> non-i386/arm.

Understood.

For now: rpvm hasn't been ported to those platforms.

-- 
Raul



Reply to: