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
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 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
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 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
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,
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 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
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
16 matches
Mail list logo
