[opensuse-packaging] A package fails in devel project but not in Factory
Hi! Currently kdelibs3 fails in devel project against Factory with the following error: /opt/kde3/bin/mcopidl: error while loading shared libraries: libmcop.so.1: cannot open shared object file: No such file or directory If to insert an ls command before build, it shows that this file exists in /opt/kde3/lib. https://build.opensuse.org/package/live_build_log?arch=i586&package=kdelibs3&project=KDE%3AKDE3&repository=openSUSE_Factory In Factory and in 12.1 the package builds well. The error happens in both 32-bit and 64-bit builds. I have no clue why it cannot find the file. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Dnia czwartek, 14 czerwca 2012 14:04:13 Ilya Chernykh pisze:
Hi!
Currently kdelibs3 fails in devel project against Factory with the following error:
/opt/kde3/bin/mcopidl: error while loading shared libraries: libmcop.so.1: cannot open shared object file: No such file or directory
If to insert an ls command before build, it shows that this file exists in /opt/kde3/lib. https://build.opensuse.org/package/live_build_log?arch=i586&package=kdelibs 3&project=KDE%3AKDE3&repository=openSUSE_Factory
In Factory and in 12.1 the package builds well. The error happens in both 32-bit and 64-bit builds.
I have no clue why it cannot find the file.
Because it is not in ldconfig? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 15.06.2012 21:43, Křištof Želechovski wrote:
I have no clue why it cannot find the file.
Because it is not in ldconfig? Exactly, I fixed it in now in arts. arts shouldn't rely on rpaths.
Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, 18 Jun 2012 09:27, Stephan Kulow
On 15.06.2012 21:43, Křištof Želechovski wrote:
I have no clue why it cannot find the file.
Because it is not in ldconfig? Exactly, I fixed it in now in arts. arts shouldn't rely on rpaths.
I'd like to rise a question here: Would it be acceptable for a package simply to include a file /etc/ld.so.conf.d/<package>.conf to work around a missing ldconfig entry? Or is for such a file a security audit needed? A example I see on my system would be /etc/ld.so.conf.d/graphviz.conf which is owned by the graphviz - package. Or is there more than a simple file needed? A call to /sbin/ldconfig with [params] perhaps, see example (code from graphviz - package) postinstall scriptlet (using /bin/sh): /sbin/ldconfig # run "dot -c" to generate plugin config /usr/lib64/graphviz/config dot -c test -s /usr/lib64/graphviz/config || echo "/usr/lib64/graphviz/config doesn't exist! Check installation." postuninstall scriptlet (using /bin/sh): /sbin/ldconfig if ! test -x $RPM_INSTALL_PREFIX0/bin/dot; then rm -f $RPM_INSTALL_PREFIX0/lib64/graphviz/config; fi (end of code) Is this the "right" way to go to avoid rpath? -- Yamaban.
On 18.06.2012 10:45, Yamaban wrote:
Is this the "right" way to go to avoid rpath?
Well, you don't need to avoid rpath if the rpath makes sense, we're not debian. ld.so.conf.d files have a huge disadvantage: they extend the search path for *every* library. If you know dot will be the only app ever looking for libraries in this path, use a rpath. This is different to /opt/kde3/lib though - there are tons of libraries in there and tons of binaries looking there, so ld.so.conf.d file is a good compromise. And as a matter of fact, we block rpaths entries for that path in our binaries (and other "system paths"). Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Monday 18 June 2012 13:07:41 Stephan Kulow wrote:
Well, you don't need to avoid rpath if the rpath makes sense, we're not debian. ld.so.conf.d files have a huge disadvantage: they extend the search path for *every* library. If you know dot will be the only app ever looking for libraries in this path, use a rpath.
This is different to /opt/kde3/lib though - there are tons of libraries in there and tons of binaries looking there, so ld.so.conf.d file is a good compromise. And as a matter of fact, we block rpaths entries for that path in our binaries (and other "system paths").
I only wonder why other packages that look for libraries located in that place work well. Is there a global setting where the libraries can be located? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 18.06.2012 12:57, Ilya Chernykh wrote:
On Monday 18 June 2012 13:07:41 Stephan Kulow wrote:
Well, you don't need to avoid rpath if the rpath makes sense, we're not debian. ld.so.conf.d files have a huge disadvantage: they extend the search path for *every* library. If you know dot will be the only app ever looking for libraries in this path, use a rpath.
This is different to /opt/kde3/lib though - there are tons of libraries in there and tons of binaries looking there, so ld.so.conf.d file is a good compromise. And as a matter of fact, we block rpaths entries for that path in our binaries (and other "system paths").
I only wonder why other packages that look for libraries located in that place work well. Is there a global setting where the libraries can be located?
They work because they buildrequire kdelibs3, which has a ld.so.conf.d file. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (4)
-
Ilya Chernykh -
Křištof Želechovski -
Stephan Kulow -
Yamaban