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
wa
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
>
[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
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 optio
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
shlib
> 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
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: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
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 packa
> 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 my
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 curr
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
Stop
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.
> >Questio
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 kn
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 t
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 inf
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
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
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 " to find the paths to the linked libraries
> > 2) use "objdump -p " to actuall
Frank Lichtenheld <[EMAIL PROTECTED]> writes:
> This isn't quite true I think. The current dpkg-shlibdeps code works
> like this:
> 1) use "ldd " to find the paths to the linked libraries
> 2) use "objdump -p " to actually check which of this libraries
>are listed as NEEDED (Are there cases w
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 n
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
> 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 so
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 prog
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 sou
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 sol
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' targe
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 ca
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 us
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 bui
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 l
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
libr
32 matches
Mail list logo
