Re: Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
On Sat, Sep 29, 2007 at 12:58:12AM +1000, skaller wrote:
> On Fri, 2007-09-28 at 14:26 +0100, Richard Jones wrote:
> > On Fri, Sep 28, 2007 at 03:17:27PM +0200, Stefano Zacchiroli wrote:
> > > On Fri, Sep 28, 2007 at 02:10:45PM +0100, Richard Jones wrote:
> > > > In particular I could do it if INRIA said that they would support the
> > > > change in some future release (see the exception "Patches Heading
> > > > Upstream"). But otherwise this is quite a large ABI change -- if
> > > > Fedora users started to build lots of 64 bit shared libraries linked
> > > > with -lcamlrun I could end up maintaining it separately forever.
> >
> > [I meant to say -lcamlrun_shared here]
> >
> > > I think you misunderstood my proposal. I don't want to apply your
> > > initial fix which changes libcamlrun.a into libcamlrun.so. I want to add
> > > a libcamlrun_shared.so, so there would be no ABI change, just the added
> > > possibility to link against it.
> > >
> > > Or maybe you're concerned about having to drop in the future support for
> > > libcamlrun_shared.so, but I think the user impact of that new library
> > > would be quite low. In fact I don't think anything else that
> > > mod_caml-like projects will need it ...
> >
> > That would also need to go upstream before Fedora could accept it.
>
> Why? I would have thought it is close to *policy* to provide
> libraries for both static and dynamic link.
Please don't get me wrong here: I want the patch in OCaml, I want
Fedora to follow Debian's packaging decisions where possible, and I
want to have mod_caml & ocamlnet + Apache working. But this patch is
a big potential change to the API and it can't go in to Fedora unless
INRIA accept it upstream, and that concern overrides other issues.
Hopefully INRIA will indicate that they want to accept this in which
case it can go in to Fedora straightaway.
Rich.
--
Richard Jones
Red Hat
Reply to: