[CCing Joey Hess. As debhelper maintainer he might want to add something
to the discussion and I don't know if he reads it already]
On Tue, Jan 24, 2006 at 04:35:54PM -0800, Steve Langasek wrote:
If you don't handle the -l, you won't be able to resolve a full path for
these libs. If you have a
Frank Lichtenheld wrote:
Yeah, that's indeed a problem. But that isn't solved by the current
implementation either. When I think about it there is now way the
-l option (if pointing to a directory that is not known to dpkg)
changes anything about the build currently since the local shlibs
On Wed, Jan 25, 2006 at 01:18:55PM -0500, Joey Hess wrote:
BTW, dpkg-shlibdeps -l does not seem to be documented in its manual page
or help text ATM.
I was talking about dh_shlibdeps -l and the LD_LIBRARY_PATH handling in
dpkg-shlibdeps. dpkg-shlibdeps has indeed no -l option. Sorry if that
was
On Sun, Jan 22, 2006 at 10:14:16PM +0100, Frank Lichtenheld wrote:
I've implemented this option. Patch and new script (since the patch is
garbled with a little code clean-up I did while going through the
script) are attached.
Comments and/or testing welcome.
Comment to myself: The current
On Tue, Jan 24, 2006 at 06:05:43PM +0300, Nikita V. Youshchenko wrote:
On Sun, Jan 22, 2006 at 10:14:16PM +0100, Frank Lichtenheld wrote:
Comment to myself: The current patch probably breaks dh_shlibdeps
-l option because it doesn't honor LD_LIBRARY_PATH. Can someone
tell me a package
On Sun, Jan 22, 2006 at 10:14:16PM +0100, Frank Lichtenheld wrote:
I've implemented this option. Patch and new script (since the patch is
garbled with a little code clean-up I did while going through the
script) are attached.
Comments and/or testing welcome.
Comment to myself: The
On Tue, Jan 24, 2006 at 06:43:02PM +0300, Nikita V. Youshchenko wrote:
dpkg-shlibdeps calls ldd, which will just fail if LD_LIBRARY_PATH won't
point to directories with local libraries.
That's not true. ldd will just happily print libfoo.so.1 = not found
and exit with exit code 0. So this
On Tue, Jan 24, 2006 at 06:43:02PM +0300, Nikita V. Youshchenko wrote:
dpkg-shlibdeps calls ldd, which will just fail if LD_LIBRARY_PATH
won't point to directories with local libraries.
That's not true. ldd will just happily print libfoo.so.1 = not found
and exit with exit code 0. So this
On Tue, Jan 24, 2006 at 07:06:47PM +0300, Nikita V. Youshchenko wrote:
But if ldd does not dislike unresolved libraries, I see no other problems
with dropping -l. Library files from non-standard paths won't be found by
dpkg anyway, so can't be processed in way other than shlibs.local
On Tue, Jan 24, 2006 at 06:05:43PM +0300, Nikita V. Youshchenko wrote:
On Sun, Jan 22, 2006 at 10:14:16PM +0100, Frank Lichtenheld wrote:
Comment to myself: The current patch probably breaks dh_shlibdeps
-l option because it doesn't honor LD_LIBRARY_PATH. Can someone
tell me a
On Tue, Jan 24, 2006 at 04:34:43PM +0100, Frank Lichtenheld wrote:
On Tue, Jan 24, 2006 at 06:05:43PM +0300, Nikita V. Youshchenko wrote:
On Sun, Jan 22, 2006 at 10:14:16PM +0100, Frank Lichtenheld wrote:
Comment to myself: The current patch probably breaks dh_shlibdeps
-l option because
tags 317082 patch
tags 317082 - moreinfo
thanks
On Fri, Jan 20, 2006 at 03:47:35AM -0800, Steve Langasek wrote:
On Thu, Jan 19, 2006 at 12:14:35AM +0100, Frank Lichtenheld wrote:
1) use dpkg --search but only with the library name from objdump, not
with the full path.
Questions: -
Processing commands for [EMAIL PROTECTED]:
tags 317082 patch
Bug#317082: libc6-s390x: missing depends on lib64gcc1
Tags were: moreinfo
Tags added: patch
tags 317082 - moreinfo
Bug#317082: libc6-s390x: missing depends on lib64gcc1
Tags were: patch moreinfo
Tags removed: moreinfo
thanks
Hello people.
objdump isn't a solution either, while it sometimes can read the
other shared library, it doesn't provide the linker search patch
which is of critical importance to get this stuff right.
Hmm...
But what for is that search path?
As far as I understand, dpkg-shlibdeps
On Fri, Jan 20, 2006 at 11:57:28AM +0300, Nikita V. Youshchenko wrote:
2) we could try to use the ldconfig cache to make to work of ldd for
ourself.
Questions: - Is this really an advantage? Or has the cache the same
problems ldd has?
Hmm. In theory, ldconfig
On Thu, Jan 19, 2006 at 12:14:35AM +0100, Frank Lichtenheld wrote:
So looks it is safe to remove any path processing from dpkg-slibdeps, and
use only objdump. If something breaks, it should be fixed elsewhere (i.e.
proper shlibs data added to packages).
If we don't use the path
On Fri, Jan 20, 2006 at 03:36:36AM -0800, Steve Langasek wrote:
On Fri, Jan 20, 2006 at 11:57:28AM +0300, Nikita V. Youshchenko wrote:
2) we could try to use the ldconfig cache to make to work of ldd for
ourself.
Questions: - Is this really an advantage? Or has the cache the same
On Fri, Jan 20, 2006 at 11:57:28AM +0300, Nikita V. Youshchenko wrote:
I sometimes have to work with MontaVista toolchains. They to provide
cross-ldd tool that just implements the same library-searching logic for
non-native binaries as dynamic libker implements for native ones.
I don't know
On Wed, Jan 18, 2006 at 08:00:55PM -0800, Russ Allbery wrote:
Frank Lichtenheld [EMAIL PROTECTED] writes:
This isn't quite true I think. The current dpkg-shlibdeps code works
like this:
1) use ldd binary to find the paths to the linked libraries
2) use objdump -p binary to actually
Let's revive this discussion.
On Sun, Aug 21, 2005 at 07:42:54PM +0400, Nikita V. Youshchenko wrote:
objdump isn't a solution either, while it sometimes can read the other
shared library, it doesn't provide the linker search patch which is of
critical importance to get this stuff right.
On Thu, Jan 19, 2006 at 12:14:35AM +0100, Frank Lichtenheld wrote:
If we don't use the path information from ldd there are several ways to
go:
1) use dpkg --search but only with the library name from objdump, not
with the full path.
Questions: - Are there cases where the library name
Frank Lichtenheld [EMAIL PROTECTED] writes:
This isn't quite true I think. The current dpkg-shlibdeps code works
like this:
1) use ldd binary to find the paths to the linked libraries
2) use objdump -p binary to actually check which of this libraries
are listed as NEEDED (Are there cases
objdump isn't a solution either, while it sometimes can read the other
shared library, it doesn't provide the linker search patch which is of
critical importance to get this stuff right.
Hmm...
But what for is that search path?
As far as I understand, dpkg-shlibdeps should just get NEEDED
At Wed, 17 Aug 2005 22:05:42 +0200,
Andreas Jochens wrote:
I guess you will generally have many more issues than this one when you
try to build 64-bit packages on a 32-bit buildd (e.g. compiling and
running 64-bit programs from configure scripts, running 'make check' or
'make test' targets,
On 05-Aug-18 14:47, GOTO Masanori wrote:
At Wed, 17 Aug 2005 22:05:42 +0200,
Andreas Jochens wrote:
In the end it will be much easier to require a 64-bit machine to be
used to build 32/64-bit biarch packages instead of trying to circumvent
all these issues.
Yes, that's one solution.
At Thu, 18 Aug 2005 10:24:14 +0200,
Andreas Jochens wrote:
There is already an inofficial buildd for the ppc64 architecture
running for 'unstable'. The respective ppc64 package archive is located at
deb http://debian-ppc64.alioth.debian.org/gcc4 unstable main
and almost 95% of all source
On Thu, Aug 18, 2005 at 02:47:46PM +0900, GOTO Masanori wrote:
At Wed, 17 Aug 2005 22:05:42 +0200,
Andreas Jochens wrote:
I guess you will generally have many more issues than this one when you
try to build 64-bit packages on a 32-bit buildd (e.g. compiling and
running 64-bit programs
reassign 317082 libc6-dev,dpkg-dev
thanks
I managed to grab Matthias Klose and he helped me get a working demo of
the problem on my lowly i386, and I understand the bug now -- there's
some missing context in the above mails.
For those following, the problem is that people are building 64-bit
On 05-Aug-17 17:00, Scott James Remnant wrote:
For those following, the problem is that people are building 64-bit
libraries on a 32-bit platform (or the other way around) as part of the
package build. dpkg-shlibdeps uses plain old ldd to find out the
dependencies of a binary or shared
On 05-Aug-17 12:52, Steve Langasek wrote:
No, that doesn't solve the problem. How are you supposed to invoke a
64-bit linker for a bi-arch build being done on a 32-bit buildd?
I guess you will generally have many more issues than this one when you
try to build 64-bit packages on a 32-bit
On Wed, Aug 17, 2005 at 08:26:46PM +0200, Andreas Jochens wrote:
On 05-Aug-17 17:00, Scott James Remnant wrote:
For those following, the problem is that people are building 64-bit
libraries on a 32-bit platform (or the other way around) as part of the
package build. dpkg-shlibdeps uses
At Wed, 17 Aug 2005 17:00:23 +0100,
Scott James Remnant wrote:
I don't think this is just a dpkg-dev bug, these bi-arch systems need
to provide ldd or an equivalent that can read either form of shared
library that it would support.
objdump isn't a solution either, while it sometimes can read
32 matches
Mail list logo
