On 09/17/2010 06:49 PM, Pere Mato Vila wrote:
> You are completely right, the library I was using to import has
> no SONAME field. I know exactly what I am doing wrong.
Great. I'm glad you got it working.
> Thanks very much for your patience.
You're welcome. It paid off for me because I found
Hi Brad,
> This is why I was asking all those questions. I bet the library
> has not been built with a proper SONAME field.
You are completely right, the library I was using to import has no SONAME
field. I know exactly what I am doing wrong. I did build a proper library with
the SONAME set wi
On 09/17/2010 01:06 PM, Brad King wrote:
> In the case of an imported target it checks
> for the IMPORTED_NO_SONAME property:
[snip]
> Try setting that for your imported target (to value "1"). It looks
> like this property is missing from the documentation though! I'll
> fix that.
Documentation
On 09/17/2010 12:31 PM, Pere Mato Vila wrote:
> Thanks for your interest. In fact your questions made me think
> in the direction that the problem must be in the way the
> library libGaudiKernel.so was built or installed. In fact I
> remembered that I have a soft link in the installation
> path. T
Hi Brad,
Thanks for your interest. In fact your questions made me think in the
direction that the problem must be in the way the library libGaudiKernel.so was
built or installed. In fact I remembered that I have a soft link in the
installation path. The directory /build/mato/GAUDI/GAUDI_v21
Hi Pere,
What platform are you using (uname -a)? Does it use ELF binaries?
On 09/17/2010 11:24 AM, Pere Mato Vila wrote:
> $ ldd libLHCbMathLib.so
>
> /build/mato/GAUDI/GAUDI_v21r10p1/InstallArea/x86_64-slc5-gcc43-opt/lib/libGaudiKernel.so
> (0x2afdec07d000)
>...
> $ ldd
> /
>> The problem I have is that when have already built and
>> installed B I can not move anymore the location of the A. This
>> is because the libraries created in B contains the absolute
>> path to exported libraries in A.
>
> The binaries in B would at most contain RPATH entries to point at the
On 09/17/2010 09:31 AM, Pere Mato Vila wrote:
> The problem I have is that when have already built and
> installed B I can not move anymore the location of the A. This
> is because the libraries created in B contains the absolute
> path to exported libraries in A.
The binaries in B would at most c
On Fri, Sep 17, 2010 at 7:43 AM, Brad King wrote:
> On 09/17/2010 07:19 AM, Pere Mato Vila wrote:
> > I am using the nice feature of exporting targets from one CMake
> > project to another. This works really nicely since it avoids
> > explicitly linking my executables and shared libraries with th
Dear Brad,
Thanks for the prompt reply, but still I do not understand. I agree that if I
have a project A that is exporting targets of the install tree and a project B
that is using project A, I can move the install tree of A and I can still
continue to build project B because the properties
On 09/17/2010 07:19 AM, Pere Mato Vila wrote:
> I am using the nice feature of exporting targets from one CMake
> project to another. This works really nicely since it avoids
> explicitly linking my executables and shared libraries with the
> dependent libraries of the imported library target. The
Hi,
I am using the nice feature of exporting targets from one CMake project to
another. This works really nicely since it avoids explicitly linking my
executables and shared libraries with the dependent libraries of the imported
library target. The problem is that imported library is linked
12 matches
Mail list logo
