ert Akkerman <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [PROPOSED] Changes in handling library dependencies
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="
Roman Hodek wrote:
>
> > 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 d
> "Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes:
Jason> One other little clarification, if the library does not
Jason> properly declare the libraries it needs then it is up to
Jason> programs linking to that library to specify them - just
Jason> like for static librarie
On Fri, 21 Jan 2000, Ronald van Loon wrote:
> had to request an address to load your library. Things have come quite a
> ways since then. But I digress.
Welcome to ELF..
> I can only say: great. Just keep in mind that this does not work on all
> systems - but maybe that does not apply to the a
> *static* libraries are conisiderably different and in that case you
> do need to mention all of the libraries that all of the sub
> libraries touch. However, I thought gnome used libtool which takes
> care of that through its .la files, making this whole point moot.
Yep, libtool tries to overco
> Then explain to my why it worked perfectly for me even if I did not
> list all those libraries in the link command? Seems like the linker
> is smart enough..
Yes, it is. (But only for shared libs, of course, static libs have no
NEEDED entries.)
Roman
> No, this is wrong. With dynamic linking it is proper to
> specify ONLY the
> libraries whos functions you explicitly use. For instance if
> you only call
> imlib functions then you should link only to imlib. In turn, imlib's
> shared library can link to or dlopen whatever other shared
> libraries
> "Brian" == Brian May <[EMAIL PROTECTED]> writes:
Brian> From the documentation:
Brian>(1) However, you should never use `-L' or `-l' flags to
Brian> link against an uninstalled libtool library. Just specify
Brian> the relative path to the `.la' file, such as
Brian>
> "Ben" == Ben Collins <[EMAIL PROTECTED]> writes:
Ben> Shared library information in the .la is just redundancy of
Ben> what info can be gotten from the library itself. It is only
Ben> useful to the human reader (who understands little about ldd
Ben> and objdump). Ld does not
On 21 Jan 2000, Brian May wrote:
> Jason> gcc -L ./libs -lkerb5 -o libgssapi.so [...]
>
> Like I said earlier, that doesn't work if you put libtool in front of
> the command line.
If libtool doesn't do that for you but writes that info to a .la file then
it is plain and simple Broken(tm) fo
> "Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes:
Jason> gcc -L ./libs -lkerb5 -o libgssapi.so [...]
Like I said earlier, that doesn't work if you put libtool in front of
the command line.
--
Brian May <[EMAIL PROTECTED]>
On Fri, Jan 21, 2000 at 12:41:03PM +1100, Brian May wrote:
> > "Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes:
>
> Jason> On 21 Jan 2000, Brian May wrote:
>
> >> Hang on. You can't do it!!! At least, not with libtool.
>
> Jason> What? .la files are only for static linking,
> "Mark" == Mark Baker <[EMAIL PROTECTED]> writes:
Mark> On Thu, Jan 20, 2000 at 03:34:29PM +0100, Ronald van Loon
Mark> 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 s
On 21 Jan 2000, Brian May wrote:
> How would you do it?
If you are using libtool and the .la has the correct information but the
.so does not have the proper depends then I think we should start
tormenting the libtool authors to fix it.
It is not hard, you just throw the right -L and -l options
> "Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes:
Jason> On 21 Jan 2000, Brian May wrote:
>> Hang on. You can't do it!!! At least, not with libtool.
Jason> What? .la files are only for static linking, we are talking
Jason> about dynamic. It is good that libtool compla
On 21 Jan 2000, Brian May wrote:
> Hang on. You can't do it!!! At least, not with libtool.
What? .la files are only for static linking, we are talking about dynamic.
It is good that libtool complains :>
Look inside the .la file, it is just a text file.
Jason
> "Brian" == Brian May <[EMAIL PROTECTED]> writes:
Jason> You can link a library with missing symbols but when you
Jason> link a program to that library the linker will complain.
Brian> Yes, I see you are right. ldd shows libresolv (which was
Brian> included on the command line
> "Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes:
Jason> Without seeing the full details, it is more likely that you
Jason> do not have proper depends on the libraries. When you build
Jason> libhgssapi makes sure to tack on -lkrb5 -ldes -lasn1
Jason> ... etc You can use
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
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
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 will be changed to using objdump. This however changes
will need a couple of c
45 matches
Mail list logo
