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

Re: Ginkgo-CADx package - was: Install on ubuntu 10.04.2 or debian 6



Hi, all.

The openmpi dependency may be caused by ITK because a huge portion of it is template based.

I'll review the "rpath problem explain" reference that Sebastian sent to us, but we are too busy right now to deep in the problem.
[ For some notes about the issue, please read below the mail paste ]

Mathiew, Our response may have lost. It was:

==8<==

El 11/05/2011, a las 14:16, Carlos Barrales escribió:

> Hi Mathieu.
> 
> I'm not sure. It was the only way I was able to pass shlibs scanning.
> 
> --
> Carlos Barrales Ruiz.
> carlos.barrales@metaemotion.com
> http://healthcare.metaemotion.com
> 
> 
> On Wed, May 11, 2011 at 1:13 PM, Mathieu Malaterre <mathieu.malaterre@gmail.com> wrote:
> Carlos,
> 
>  Even after applying your patch I get an error reported by lintian:
> 
> E: ginkgocadx: binary-or-shlib-defines-rpath
> ./usr/lib/ginkgocadx/Plugins/libvisualizator.so.2.4.1.1
> /usr/lib/openmpi/lib
> E: ginkgocadx: binary-or-shlib-defines-rpath
> ./usr/lib/ginkgocadx/libCADxCore.so.2.4.1.1 /usr/lib/openmpi/lib
> 
> 
>  Do you really need to use rpath ?


==>8==

What I mean is: 
If I disable rpath, cmake build is done, but dh_shlibdeps fails so it can't found libCADxCore.so for ginkgocadx binary as well as libvisualization.so

Maybe a easy fix should be to split ginkgo package in three ones with:
* ginkgocadx executable binary and manual.
* libCADxCore.so with its translations.
* libvisualization.so with its translations.

Doing this, dh_shlibdeps should be able to find deps so they must be previously installed.

I don't know if dh_shlibdeps stands for LD_LIBRARY_PATH export or any other kind of path location to find those libraries or wathever. I don't know how this rule works exactly.

El 26/05/2011, a las 10:16, Mathieu Malaterre escribió:

> On Thu, May 26, 2011 at 9:49 AM, Sebastian Hilbert
> <sebastian.hilbert@gmx.net> wrote:
>>> So in summary rpath is an Error.
>>> 
>> 
>> Is this something upstream should take care of (which I have CCed) or is this
>> a packaging issue ?
> 
> I asked upstream why they used rpath in the first place but never got
> an answer ...
> I have not digged any further on why an RPATH for openmpi was there,
> could be a debian only issue. From quick browsing the cmake script it
> looks like RPATH is being forced in upstream build system.
> 
> 2cts
> -- 
> Mathieu


--
Carlos Barrales Ruiz.
carlos.barrales@metaemotion.com
http://www.metaemotion.com/


Reply to: