AIDA Shinra wrote:
If B did not directly refer any neon's symbols,
gcc -o B B.o -lA -lneon
Oh, this line is:
gcc -o B B.o -lA
Of course, not directly referring to these symbols is exceedingly rare,
and most likely doesn't account for the most common case...
--
Benjamin Reed, a.k.a. RangerRick
If B did not directly refer any neon's symbols,
gcc -o B B.o -lA -lneon
Oh, this line is:
gcc -o B B.o -lA
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an
An example is the neon package. Currently we are using neon24, but
in the recent past we used neon23 (and many earlier ones). If you have
neon24 installed and link with -lneon, you will be linked to the
v. 24 of the neon lib because of a symlink from libneon.dylib to
libneon.24.dylib. On
Sorry for jumping on this, but did you keep a note of what was missing from
where? If you could inform the maintainers of missing BuildDepends it would
help a lot.
Sorry, but the list is quite incomplete and outdated.
---
This SF.Net
I guess BuildDependsOnly flag is intended to improve scalability, but
I think it is a bad idea.
The problem is library-to-library dependency. For example, every
applications depending on gtk+2 must also depend on atk1, glib2-dev,
pango1-xft2-dev, gettext-dev and libiconv-dev. This is major source
The reason for the BuildDependsOnly flag is to make it possible to upgrade
a library in the future, if the upgrade is not binary-backwards-compatible.
An example is the neon package. Currently we are using neon24, but
in the recent past we used neon23 (and many earlier ones). If you have
neon24
