Re: Re: Useless call to ldconfig and shared libraries issue

2015-02-05 Thread Corentin Desfarges
Are you sure that in build time do you need to download some data? is this acceptable? Leopold Yes I need to download the data, else the unit tests can't pass... And I can't include the data into the package, because of its the size (more than 800MB). It has already been discussed in this thre

Re: Re: Useless call to ldconfig and shared libraries issue

2015-02-04 Thread Corentin Desfarges
I'm trying to build the fw4spl, in a pbuild environtment and I got this. [...] Any idea? Leopold Sorry, I've wasted your time. I forgot to push some lines in my CMakeLists.txt. But now the build work, with the commit : a15dbd90a83fe604950123f07e9c4ebf0e81de8b Thanks for your help, Corenti

Re: Re: Useless call to ldconfig and shared libraries issue

2015-02-04 Thread Corentin Desfarges
Hi Leopold, I'm trying to build the package. CMake fails. Needs to be called twice. This is not good. Please, try to patch cmakelist.txt to solve it. I fixed and pushed the changes. CMake shouldn't fail anymore. Thanks for your help! Corentin -- To UNSUBSCRIBE, email to debian-mentors-re

Re: Re: Useless call to ldconfig and shared libraries issue

2015-02-03 Thread Paul Wise
On Tue, Feb 3, 2015 at 9:27 PM, Corentin Desfarges wrote: > corentin@debian:~/dev1/fw4spl$ objdump -x > /home/corentin/dev1/fw4spl/debian/fw4spl/usr/bin/fwLauncher | grep -i rpath > corentin@debian:~/dev1/fw4spl$ objdump -x > /home/corentin/dev1/fw4spl/obj-x86_64-linux-gnu/fwLauncher/bin/fwLau

Re: Re: Useless call to ldconfig and shared libraries issue

2015-02-03 Thread Corentin Desfarges
Sorry for the format of the last message. It's better like it : corentin@debian:~/dev1/fw4spl$ objdump -x /home/corentin/dev1/fw4spl/debian/fw4spl/usr/bin/fwLauncher | grep -i rpath corentin@debian:~/dev1/fw4spl$ objdump -x /home/corentin/dev1/fw4spl/debian/fw4spl/usr/bin/fwLauncher-0.1 | g

Re: Re: Re: Re: Useless call to ldconfig and shared libraries issue

2015-02-03 Thread Paul Wise
On Tue, Feb 3, 2015 at 5:15 PM, Corentin Desfarges wrote: > I'm sorry but this two commands don't work. I still get the same error > when I run the second command (/usr/bin/fwLauncher) : What is the output of these commands? ls -l /usr/lib/fw4spl/libfwCore* file /usr/bin/fwLauncher /usr/lib/fw4s

Re: Re: Re: Re: Useless call to ldconfig and shared libraries issue

2015-02-03 Thread Corentin Desfarges
This pair of commands will work: sudo debi /usr/bin/fwLauncher I'm sorry but this two commands don't work. I still get the same error when I run the second command (/usr/bin/fwLauncher) : fwLauncher: error while loading shared libraries: libfwCore.so.0: cannot open shared object file: No

Re: Re: Re: Useless call to ldconfig and shared libraries issue

2015-02-02 Thread Paul Wise
On Mon, Feb 2, 2015 at 9:17 PM, Corentin Desfarges wrote: > I mean that I get the same error : > > ./debian/fw4spl/usr/bin/fwLauncher: error while loading shared libraries: > libfwCore.so.0: cannot open shared object file: No such file or > directory This pair of commands will work: sudo debi /u

Re: Re: Re: Useless call to ldconfig and shared libraries issue

2015-02-02 Thread Corentin Desfarges
But it doesn't work. What does "doesn't work" mean? I mean that I get the same error : ./debian/fw4spl/usr/bin/fwLauncher: error while loading shared libraries: libfwCore.so.0: cannot open shared object file: No such file or directory -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.

Re: Re: Useless call to ldconfig and shared libraries issue

2015-02-02 Thread Paul Wise
On Mon, Feb 2, 2015 at 7:22 PM, Corentin Desfarges wrote: > I've already try something like : > -Wl,-rpath=/usr/lib/fw4spl > Is it something like it that you were talking by "rpath" ? Yes. > But it doesn't work. What does "doesn't work" mean? -- bye, pabs https://wiki.debian.org/PaulWise -

Re: Re: Useless call to ldconfig and shared libraries issue

2015-02-02 Thread Corentin Desfarges
Since it sounds like libfwCore.so.0 is supposed to be a private library so I think the correct solution here is for upstream to build the binary using an rpath rather than turning it into a public library placed in a different path. I've already try something like : export DEB_LDFLAGS_MAINT_A