RFS: sword-text-rst
Dear mentors, I am looking for a sponsor for my package sword-text-rst. * Package name: sword-text-rst Version : 1.6-1 * URL : http://www.crosswire.org/sword/modules/ModInfo.jsp?modName=RST * License : Public Domain Section : text It builds these binary packages: sword-text-rst - Russian Synodal Translation Bible for SWORD The package is lintian clean. The upload would fix these bugs: 377937 The package can be found on mentors.debian.net at http://mentors.debian.net/debian/pool/main/s/sword-text-rst Or just apt-get source sword-text-rst if your sources.list contains: deb-src http://mentors.debian.net/debian unstable main contrib non-free I would be glad if someone uploaded this package for me. Kind regards Artem Zolochevskiy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
how to fix shlib-with-non-pic-code ?
hi, i've got a lintian error: E: libstrigihtmlgui0: shlib-with-non-pic-code usr/lib/libstrigihtmlgui.so.0.3.2 N: N: The listed shared libraries contain object code that was compiled N: without -fPIC. All object code in shared libraries should be N: recompiled separately from the static libraries with the -fPIC option. N: N: Another common mistake that causes this problem is linking with gcc N: -Wl,-shared instead of gcc -shared. N: N: In some cases, exceptions to this rule are warranted. If this is such N: a case, follow the procedure outlined in Policy and then please N: document the exception by adding a lintian override to this package. N: N: Refer to Policy Manual, section 10.2 for details. N: * the build gives me : Linking CXX shared library libstrigihtmlgui.so cd /tmp/buildd/strigi-0.3.2/./obj-i486-linux-gnu/src/htmlgui /usr/bin/cmake -P CMakeFiles/strigihtmlgui.dir/cmake_clean_target.cmake cd /tmp/buildd/strigi-0.3.2/./obj-i486-linux-gnu/src/htmlgui /usr/lib/ccache/c++ -fPIC -g -Wall -O2 -O2 -g -shared -Wl,-soname,libstrigihtmlgui.so.0 -o libstrigihtmlgui.so.0.3.2 CMakeFiles/strigihtmlgu i.dir/strigihtmlgui.o -L/tmp/buildd/strigi-0.3.2/./obj-i486-linux-gnu/src/daemon -L/tmp/buildd/strigi-0.3.2/./obj-i486-linux-gnu/src/streamindexer -L/tmp/buildd/strigi-0.3.2/./obj-i486-linux-gnu/src/stream s -lsearchclient -lstreamindexer -lstreams -lz -lbz2 -lcrypto -lxml2 -Wl,-rpath,/tmp/buildd/strigi-0.3.2/./obj-i486-linux-gnu/src/daemon:/tmp/buildd/strigi-0.3.2/./obj-i486-linux-gnu/src/streamindexer:/tmp/ buildd/strigi-0.3.2/./obj-i486-linux-gnu/src/streams Linking CXX shared library CMakeFiles/CMakeRelink.dir/libstrigihtmlgui.so cd /tmp/buildd/strigi-0.3.2/./obj-i486-linux-gnu/src/htmlgui /usr/bin/cmake -P CMakeFiles/strigihtmlgui.dir/cmake_clean_target.cmake cd /tmp/buildd/strigi-0.3.2/./obj-i486-linux-gnu/src/htmlgui /usr/lib/ccache/c++ -fPIC -g -Wall -O2 -O2 -g -shared -Wl,-soname,libstrigihtmlgui.so.0 -o CMakeFiles/CMakeRelink.dir/libstrigihtmlgui.so.0.3 .2 CMakeFiles/strigihtmlgui.dir/strigihtmlgui.o -L/tmp/buildd/strigi-0.3.2/./obj-i486-linux-gnu/src/daemon -L/tmp/buildd/strigi-0.3.2/./obj-i486-linux-gnu/src/streamindexer -L/tmp/buildd/strigi-0.3.2/./ob j-i486-linux-gnu/src/streams -lsearchclient -lstreamindexer -lstreams -lz -lbz2 -lcrypto -lxml2 cd /tmp/buildd/strigi-0.3.2/./obj-i486-linux-gnu/src/htmlgui /usr/bin/cmake -E cmake_symlink_library CMakeFiles/CMakeRelink.dir/libstrigihtmlgui.so.0.3.2 CMakeFiles/CMakeRelink.dir/libstrigihtmlgui.so.0 C MakeFiles/CMakeRelink.dir/libstrigihtmlgui.so It seems to use -fPIC and shared as mentionned by lintian and i didn't find any assembly code. If i override C/CXXFLAGS: CFLAGS = -g -Wall -O2 -fPIC -shared CXXFLAGS = -g -Wall -O2 -fPIC -shared it builds, i don't have anymore the lintian error but a nice segmentation fault with a strace: strace strigiclient execve(/usr/bin/strigiclient, [strigiclient], [/* 41 vars */]) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Process 31790 detached Any ideas how i can fix ? cheers, Fathi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
binary-or-shlib-defines-rpath documentation
Hi, A package I am creating from scratch is giving me the lintian warning binary-or-shlib-defines-rpath. lintian-info in turn tells me Please contact debian-devel@lists.debian.org if you have questions about this. My search revealed two possible solutions: 'configure --disable-rpath' where supported, or 'chrpath -d'. It seems that if removing unwanted rpaths is really this simple, it could be stated within the lintian info. For that matter, it would even be nice for lintian to refer to some external documentation on the matter, to avoid users having to repeatedly filter through years of mailing list archives. So, my questions are: Have I succesfully identified the currently accepted ways of fixing this warning? Should I file a bug with lintian to provide more information on this, possibly suggesting the use of chrpath? Should I file a bug with developers-reference asking for a section documenting this problem and its solutions? thanks, Charles -- This will never Come to pass A back-seat Driver Out of gas Burma-Shave http://burma-shave.org/jingles/1960/this_will_never signature.asc Description: Digital signature
Re: binary-or-shlib-defines-rpath documentation
Charles Fry wrote: A package I am creating from scratch is giving me the lintian warning binary-or-shlib-defines-rpath. I've looked for this kind of answer before - it's not as simple as it appears. rpath arises from libraries in non-standard locations, either alone or when linked to a binary. 1. Dependencies can bring in rpath: See Bug # 374797 (amd64 specific) 2. linking binaries against pkglib_LTLIBRARY libs as opposed to lib_LTLIBRARY libs brings in rpath because the pkglib isn't in a standard library location. e.g. test programmes commonly need rpath which is OK as they aren't installed but this can catch you out if an installed binary is built in the same way. 3. Sometimes linda reports problems with rpath when lintian does not - this happens with one of my packages that has a GModule plugin. Packages available at: deb http://www.linux.codehelp.co.uk/ packages/ deb-src http://www.linux.codehelp.co.uk/ packages/ cashutil, gpe-expenses and pilot-qof. (Any tips gratefully received!) For me, it usually involves repeatedly using grep against the configure scripts, Makefiles and object files trying to isolate the problem. My search revealed two possible solutions: 'configure --disable-rpath' where supported, or 'chrpath -d'. It seems that if removing unwanted rpaths is really this simple, it could be stated within the lintian info. --disable-rpath is not always supported and even when it is, it might not cover all circumstances (although that would be a bug upstream). For that matter, it would even be nice for lintian to refer to some external documentation on the matter, to avoid users having to repeatedly filter through years of mailing list archives. I fear there isn't usually a one-size-fits-all answer for rpath problems. I may be wrong. So, my questions are: Have I succesfully identified the currently accepted ways of fixing this warning? Depends. Does it actually fix the warning? Should I file a bug with lintian to provide more information on this, possibly suggesting the use of chrpath? chrpath doesn't look like it would solve my rpath problem. Should I file a bug with developers-reference asking for a section documenting this problem and its solutions? I'd certainly like to know just what others have done to solve rpath issues. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: OpenPGP digital signature
Re: binary-or-shlib-defines-rpath documentation
I've looked for this kind of answer before - it's not as simple as it appears. rpath arises from libraries in non-standard locations, either alone or when linked to a binary. 1. Dependencies can bring in rpath: See Bug # 374797 (amd64 specific) 2. linking binaries against pkglib_LTLIBRARY libs as opposed to lib_LTLIBRARY libs brings in rpath because the pkglib isn't in a standard library location. e.g. test programmes commonly need rpath which is OK as they aren't installed but this can catch you out if an installed binary is built in the same way. 3. Sometimes linda reports problems with rpath when lintian does not - this happens with one of my packages that has a GModule plugin. So are there times when this is acceptable? When I remove rpath from my binary it won't execute as it can't find the needed library. For that matter, it would even be nice for lintian to refer to some external documentation on the matter, to avoid users having to repeatedly filter through years of mailing list archives. I fear there isn't usually a one-size-fits-all answer for rpath problems. I may be wrong. In that case it sounds like it would be helpful to have all of the current Debian knowledge on the matter aggregated in a single location. Then even if it is complex, someone encountering the warning can get a sense of different ways it is dealt with. So, my questions are: Have I succesfully identified the currently accepted ways of fixing this warning? Depends. Does it actually fix the warning? Yes, but it also broke my binary, which can no longer find the needed library. Any suggestions? Is rpath okay in this case? The needed library is coming from /usr/lib/courier-authlib. Charles -- My neck was sore In front before And also Sore behind Before Burma-Shave http://burma-shave.org/jingles/1937/my_neck_was signature.asc Description: Digital signature
Re: binary-or-shlib-defines-rpath documentation
On Wed, Jul 12, 2006 at 09:58:25PM +0100, Neil Williams wrote: Charles Fry wrote: A package I am creating from scratch is giving me the lintian warning binary-or-shlib-defines-rpath. I've looked for this kind of answer before - it's not as simple as it appears. rpath arises from libraries in non-standard locations, either alone or when linked to a binary. I'd certainly like to know just what others have done to solve rpath issues. In my case (sawfish) I run configure then delete the -Wl--rpath,... stuff from where it appears in the Makefiles before running make. But this case is easy, because it's only put in one place (by rep-config) and I checked manually that everything still compiles/runs afterwards. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: binary-or-shlib-defines-rpath documentation
On Wed, Jul 12, 2006 at 05:05:36PM -0400, Charles Fry wrote: So, my questions are: Have I succesfully identified the currently accepted ways of fixing this warning? Depends. Does it actually fix the warning? Yes, but it also broke my binary, which can no longer find the needed library. Any suggestions? Is rpath okay in this case? The needed library is coming from /usr/lib/courier-authlib. In this case, I believe it is correct. rpath is bad when it points to a system dir such as /usr/lib. Is good when it points to an application private dir. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: binary-or-shlib-defines-rpath documentation
Depends. Does it actually fix the warning? Yes, but it also broke my binary, which can no longer find the needed library. Any suggestions? Is rpath okay in this case? The needed library is coming from /usr/lib/courier-authlib. In this case, I believe it is correct. rpath is bad when it points to a system dir such as /usr/lib. Is good when it points to an application private dir. So is the lintian test wrong? Should it only be checking for rpaths that aren't system directories? thanks for the help, Charles -- Holler Half a pound for Half a dollar Oh boy! Shaving joy Complexion save Burma-Shave http://burma-shave.org/jingles/1928/holler signature.asc Description: Digital signature
Re: binary-or-shlib-defines-rpath documentation
On Wed, Jul 12, 2006 at 05:32:12PM -0400, Charles Fry wrote: So is the lintian test wrong? Should it only be checking for rpaths that aren't system directories? good question! -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: binary-or-shlib-defines-rpath documentation
So is the lintian test wrong? Should it only be checking for rpaths that aren't system directories? good question! I finally found some pseudo-official documentation on this: http://wiki.debian.org/RpathIssue which confirms what you said: Currently, the only valid use of this feature in Debian is to add non-standard library path (like /usr/lib/package) to libraries that are only intended to be used by the executables (or other libraries) within the package. cheers, Charles -- The answer to A maiden's prayer Is a man Most anywhere Using Burma-Shave http://burma-shave.org/jingles/1941/the_answer_to signature.asc Description: Digital signature
Re: binary-or-shlib-defines-rpath documentation
Charles Fry wrote: I finally found some pseudo-official documentation on this: http://wiki.debian.org/RpathIssue which confirms what you said: Currently, the only valid use of this feature in Debian is to add non-standard library path (like /usr/lib/package) to libraries that are only intended to be used by the executables (or other libraries) within the package. Shouldn't those cases be fixed via LD_LIBRARY_PATH? cheers, Charles -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: binary-or-shlib-defines-rpath documentation
Felipe Sateler [EMAIL PROTECTED] writes: Charles Fry wrote: I finally found some pseudo-official documentation on this: http://wiki.debian.org/RpathIssue which confirms what you said: Currently, the only valid use of this feature in Debian is to add non-standard library path (like /usr/lib/package) to libraries that are only intended to be used by the executables (or other libraries) within the package. Shouldn't those cases be fixed via LD_LIBRARY_PATH? No. Basically, you should never use LD_LIBRARY_PATH if you can possibly help it; it causes a bunch of really obnoxious problems like causing sub-proceses run by that process to potentially get the wrong libraries. It's too large of a lever. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
