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=cWoXeonUoKmBZSoM
User-Agent: Mutt/1.0i
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 does not
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 libraries. This is a
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), but
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
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 complains :
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
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, we are talking
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 specify all those
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 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) for
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 use it, and
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
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 it
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
*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 overcome
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
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 will
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
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 to
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 need
[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
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 dependency upon
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
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 stuff
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
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
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 -lICE
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 check
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
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 it
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.
--
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 NMUs
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 doing
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
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 necessary to specify
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.
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.
If you
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 directly and
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 to
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
41 matches
Mail list logo
