On Thu, Jan 20, 2000 at 03:34:29PM +0100, Ronald van Loon wrote:
> program needs on the command line. While it may be true that it is
> sufficient to be *dependent* only on imlib, it is still necessary to
> specify all those other implicit libraries to the linker. The linker is
> not smart enough
> "Julian" == Julian Gilbey <[EMAIL PROTECTED]> writes:
Julian> How do we ensure that someone upgrading a package from
Julian> potato to woody pulls in all of the required libraries?
Julian> As a "concrete" example, /usr/bin/foo in the foo package
Julian> depends upon libbar di
> "Brian" == Brian May <[EMAIL PROTECTED]> writes:
Brian> I thought the solution was obvious - change the shared
Brian> library dependancy information on libbar
I meant to cancel this post, not send it! ARGGHHH!!!
Anyway, now I have sent it, I might as well complete what I was saying.
On 21 Jan 2000, Brian May wrote:
> It doesn't seem to work for the Kerberos libraries. For instance,
> libcyrus-sasl needs to link in the gssapi library, from heimdal-lib.
>
> Ideally, putting -lgssapi on the command line would be good
> enough - it isn't. I get lots of symbol undefined errors.
> "Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
Wichert> Previously Ronald van Loon wrote:
>> This is not true. Direct dependencies and the libraries needed
>> for compiling are two different things. Unless the linker has
>> become extremely smart, it is still neces
On Thu, 20 Jan 2000, Ronald van Loon wrote:
> This is not true. Direct dependencies and the libraries needed for
> compiling are two different things. Unless the linker has become
> extremely smart, it is still necessary to specify all libraries a
No, this is wrong. With dynamic linking it is pr
On Thu, 20 Jan 2000, Roman Hodek wrote:
> However (as already said in a previous mail) I think that most shlib
> packages already do depend on other libs they need. What about
> checking for libs that have no such dependencies first?
It would be a nasty bug if this is not the case, consider doin
On Thu, Jan 20, 2000 at 02:35:33PM +0100, Wichert Akkerman wrote:
> Previously Julian Gilbey wrote:
> > [I think that some version of the original message should be posted at
> > some point to -devel-announce, probably once the new dpkg-shlibdeps is
> > installed in woody. We also might need some
Greetings list. About a week ago, Julian posted a diff to policy, bu 55048,
and I sent an email of encouragement directly to Julian. Since that time, I
don't recall any other comments towards his diff, so I thought I would try
to help stir things up.
So, here is the email I have sent to Julian per
Previously Roman Hodek wrote:
> I guess imlib-config lists those libraries for the case of static
> libs. Then you don't have automatic link-in of secondary libs...
Hmm, valid point. Anyone care to harass the GNOME people into adding
--static and --dynamic options to *-config? :)
Wichert.
--
Previously Ronald van Loon wrote:
> This is not true. Direct dependencies and the libraries needed for
> compiling are two different things. Unless the linker has become
> extremely smart, it is still necessary to specify all libraries a
> program needs on the command line.
Then explain to my why
> So imlib-config shouldn't list any of those libraries since libImlib
> is already linked to them.
I guess imlib-config lists those libraries for the case of static
libs. Then you don't have automatic link-in of secondary libs...
Roman
> Right, and I'm willing to bet that happens. Not everyone uses
> debhelper..
Sure, not everyone, but many. And not to forget, (AFAIK) debstd does
the same. Indeed, I always thought that shlib packages should depend
on the libs they need already... :-)
> I guess it could be done as a lintian che
> People using gtk and imlib are supposed to use gtk-config and
> imlib-config to get the right compile and link flags. Now look
> at this:
>
> [tornado;~/sources/original/dpkg/dpkg]-10> imlib-config --libs
> -L/usr/lib -lImlib -ljpeg -ltiff -lungif -lpng -lz -lm -lXext
> -L/usr/X11R6/lib -lSM -lIC
Previously Matthew Vernon wrote:
> What about packages using debstd, or dpkg-gencontrol? I presume dpkg
> will be patched such that such packages will still build?
You are completely misunderstanding what debstd and dpkg-gencontrol do.
dpkg-gencontrol *always* has to be called since it is what gen
Previously Julian Gilbey wrote:
> [I think that some version of the original message should be posted at
> some point to -devel-announce, probably once the new dpkg-shlibdeps is
> installed in woody. We also might need some NMUs if this occurs
> during the potato freeze and many developers are wor
Previously Roman Hodek wrote:
> Don't most packages do this already? I guess at least debhelper and
> debstd should run dpkg-shlibdeps on libs already... So the change
> shouldn't affect too many packages.
Looking at the db_shlibdeps code it indeed does so already. I mostly
checked some GNOME stu
Previously Roman Hodek wrote:
> The problem you describe can exist. But only if libbar doesn't depend
> yet on libbaz in potato.
Right, and I'm willing to bet that happens. Not everyone uses
debhelper..
> However (as already said in a previous mail) I think that most shlib
> packages already do d
> How do we ensure that someone upgrading a package from potato to woody
> pulls in all of the required libraries? As a "concrete" example,
> /usr/bin/foo in the foo package depends upon libbar directly and
> libbar depends upon libbaz indirectly. In potato, libbar does not
> declare a dependenc
> What about packages using debstd, or dpkg-gencontrol? I presume dpkg
> will be patched such that such packages will still build?
Hae? debstd can call dpkg-shlibdeps in the by Wichert says; no change
in the package itself. dpkg-gencontrol is totally independent. Any why
patch dpkg???
Roman
[I think that some version of the original message should be posted at
some point to -devel-announce, probably once the new dpkg-shlibdeps is
installed in woody. We also might need some NMUs if this occurs
during the potato freeze and many developers are working on frozen
rather than unstable mach
Wichert Akkerman writes:
> In woody dpkg will use a different method to determine on which
> libraries a package should depend. Until now dpkg-shlibdeps has
> used the output of ldd to determine which libraries are needed.
> This will be changed to using objdump. This however changes
> will n
> 1) It allows for cross compilation (without the dpkg-shlibdeps
> replacement in dpkg-cross)
What Wichert wants is basically the objdump-based variant in
dpkg-cross. It does nothing else than he plans to do.
Aehm, wait, one change is needed: dpkg-cross' shlibdeps current
expects all libraries t
> In woody dpkg will use a different method to determine on which
> libraries a package should depend. Until now dpkg-shlibdeps has used
> the output of ldd to determine which libraries are needed. This will
> be changed to using objdump.
[...]
> And now for the connection to package management: a
On Wed, Jan 19, 2000 at 03:56:15PM +0100, Wichert Akkerman wrote:
> Package: debian-policy
>
> In woody dpkg will use a different method to determine on which
> libraries a package should depend. Until now dpkg-shlibdeps has
> used the output of ldd to determine which libraries are needed.
> This
Package: debian-policy
(This is being resend because the BTS apparently can't handle PGP/MIME
messages with attachments).
In woody dpkg will use a different method to determine on which
libraries a package should depend. Until now dpkg-shlibdeps has
used the output of ldd to determine which libra
On Wed, Jan 19, 2000 at 03:56:15PM +0100, Wichert Akkerman wrote:
> Package: debian-policy
>
> In woody dpkg will use a different method to determine on which
> libraries a package should depend. Until now dpkg-shlibdeps has
> used the output of ldd to determine which libraries are needed.
> This
Previously Matthew Vernon wrote:
> Which error are you referring to?
Please see the REJECT message you got from dinstall, that has a full
explanation.
Wichert.
--
/ Generally uninteresting signature - ignore at your convenienc
28 matches
Mail list logo
