Re: dpkg packaging problems
Hi, Shared libraries losing the executable flag is the correct behaviour, you s'shouldn't try to override that. -- Cheers, Andrew
Re: dpkg packaging problems
On Fri, Jan 02, 2015 at 06:16:17PM +0100, Enrico Weigelt, metux IT consult wrote: > On 02.01.2015 17:08, Martin Pitt wrote: > > Yes, man dh_fixperms. Shared libraries don't need to and should not be > > executable. > > Oh, wasn't aware of that. Just used to that as gcc sets that flag. > Is it a bug in gcc, or are there platforms where +x is required ? https://unix.stackexchange.com/questions/40587/why-are-shared-libraries-executable reports it as being necessary on HP-UX. It's indeed not needed on Linux except for the odd special case, though. -- Colin Watson [cjwat...@ubuntu.com] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150102181618.ga16...@riva.ucam.org
Re: dpkg packaging problems
On Fri, 2015-01-02 at 18:16 +0100, Enrico Weigelt, metux IT consult wrote: > On 02.01.2015 17:08, Martin Pitt wrote: > > Hi, > > > Yes, man dh_fixperms. Shared libraries don't need to and should not be > > executable. > > Oh, wasn't aware of that. Just used to that as gcc sets that flag. > Is it a bug in gcc, or are there platforms where +x is required ? ld sets the flag, and I suspect this is because it can't tell the difference between a shared library and a PIE. A shared library may work as a executable anyway, e.g.: $ /lib/i386-linux-gnu/libc.so.6 GNU C Library (Debian GLIBC 2.19-13) stable release version 2.19, by Roland McGrath et al. Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [...] Ben. -- Ben Hutchings Theory and practice are closer in theory than in practice. - John Levine, moderator of comp.compilers signature.asc Description: This is a digitally signed message part
Re: dpkg packaging problems
On 02.01.2015 17:08, Martin Pitt wrote: Hi, > Yes, man dh_fixperms. Shared libraries don't need to and should not be > executable. Oh, wasn't aware of that. Just used to that as gcc sets that flag. Is it a bug in gcc, or are there platforms where +x is required ? cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54a6d261.9070...@gr13.net
Re: dpkg packaging problems
Hello Enrico, Enrico Weigelt, metux IT consult [2015-01-02 16:52 +0100]: > Unfortunately, the .so's loose the +x flag in the package > (while usual 'make install' is okay) - it seems that some of the > dh stuff drops that flag :( Yes, man dh_fixperms. Shared libraries don't need to and should not be executable. If you have a corner case where that's desirable, use -X to exclude those from permission fixes. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150102160840.gd3...@piware.de
Re: dpkg packaging problems
On Fri, 02 Jan 2015 16:52:10 +0100 "Enrico Weigelt, metux IT consult" wrote: > Hi folks, > > I'm just packaging some library to various deb distros using > pbuilder + git-buildpackage. > > Unfortunately, the .so's loose the +x flag in the package > (while usual 'make install' is okay) - it seems that some of the > dh stuff drops that flag :( This is correct. Why would a .so be executable? $ find /usr/lib/x86_64-linux-gnu/ -type f -executable -name '*.so*' $ $ find /usr/lib/x86_64-linux-gnu/ -type f -executable -name '*.so' $ https://www.debian.org/doc/debian-policy/ch-files.html#s-libraries Shared object files (often .so files) that are not public libraries, that is, they are not meant to be linked to by third party executables (binaries of other packages), should be installed in subdirectories of the /usr/lib directory. Such files are exempt from the rules that govern ordinary shared libraries, except that they must not be installed executable and should be stripped. A common example are the so-called "plug-ins", internal shared objects that are dynamically loaded by programs using dlopen(3). -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp009n6nQZ7x.pgp Description: OpenPGP digital signature
Re: dpkg packaging problems
On 01/02/2015 at 10:52 AM, Enrico Weigelt, metux IT consult wrote: > Hi folks, > > > I'm just packaging some library to various deb distros using pbuilder > + git-buildpackage. > > Unfortunately, the .so's loose the +x flag in the package (while > usual 'make install' is okay) - it seems that some of the dh stuff > drops that flag :( Are .so files really supposed to have +x? On my system, the only *.so files under /lib*/ /usr/lib*/ /usr/local/lib*/ which appear to have any executable bit set are ld.so, libpthread, libc, and the many .so files from my locally-built (and not dpkg-installed) copy of Wine. That leads me to suspect that it's intentional that .so files are not marked executable in Debian. According to the Debian Policy Manual section 8.1 [1], "Shared libraries should not be installed executable, since the dynamic linker does not require this and trying to execute a shared library usually results in a core dump.". Also, there appears to be a lintian tag warning against doing this [2], which states that "Shared libraries should be mode 0644.". Is there a particular reason why these library files need to be executable in this particular case? [1] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime [2] https://lintian.debian.org/tags/shlib-with-executable-bit.html -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
dpkg packaging problems
Hi folks, I'm just packaging some library to various deb distros using pbuilder + git-buildpackage. Unfortunately, the .so's loose the +x flag in the package (while usual 'make install' is okay) - it seems that some of the dh stuff drops that flag :( maybe some of you guys might have an idea ? See: https://github.com/metux/fskit/tree/jessie/master https://github.com/metux/fskit/tree/trusty/master the build process is driven by: https://github.com/metux/packaging cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54a6beaa.8060...@gr13.net
