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

Bug#871912: frama-c FTBFS on ppc64el/s390x/mips*: configure: error: native dynlink does not work.



Hi,

On Sat, Aug 12, 2017 at 03:03:11PM -0400, Mehdi Dogguy wrote:
> Hi,
> 
> Thank you for this report.
> 
> On 12/08/2017 09:33, Adrian Bunk wrote:
> > configure: *******************************************************
> > configure: * CONFIGURE TOOLS AND LIBRARIES USED BY SOME PLUG-INS *
> > configure: *******************************************************
> > Ocamlfind -> using +lablgtk2.(/usr/lib/ocaml/lablgtk2,/usr/lib/ocaml/lablgtk2)
> > checking for /usr/lib/ocaml/lablgtk2/lablgtksourceview2.cma... yes
> > checking for /usr/lib/ocaml/lablgtk2/lablgnomecanvas.cma... yes
> > checking for /usr/lib/ocaml/lablgtk2/lablgtk.cma... yes
> > checking for dot... yes
> > configure: error: native dynlink does not work.
> > debian/rules:13: recipe for target 'override_dh_auto_configure' failed
> > make[1]: *** [override_dh_auto_configure] Error 2
> > 
> 
> For reference: After seeing this build failure after my upload, I have sent
> a mail to upstream asking whether bytecode architectures are still supported.
> I didn't want to patch Frama-C to make it build again there is there is no
> will from upstream to support those architectures (It is trivial to fix but
> might a useless effort). I am still waiting for their reply.

I agree with Mehdi, if upstream doesn't want to support bytecode
architecturd any longer then I don't think it is worth our time to fix
this. BTW, why (which seems to be the only reverse dependency of
frama-c) also dropped support for bytecode architectures.

-Ralf.


Reply to: