On Tue, Nov 20, 2007 at 01:20:33PM -0500, Joey Hess wrote:
Raphael Hertzog wrote:
With debhelper 5.0.61, dh_makeshlibs will also call dpkg-gensymbols if it
finds debian/package.symbols (or debian/package.symbols.arch). So
for packages using debhelper, the only thing to do is to drop the
On Tue, Nov 20, 2007 at 04:22:56PM +0100, Raphael Hertzog wrote:
Hello,
since the upload of dpkg 1.14.8 to unstable, it's now possible for
library packages to generate symbols control files that will be used by
other packages to get more accurate (and less strict) dependencies.
As this is
On Tue, 20 Nov 2007, Russ Allbery wrote:
I always use dependencies like = 2.10 in shlibs files rather than the
more specific 2.10-1 because of this problem. I'm not sure if that's
the right general solution, but people who start from the seed files
should at least consider
On Wed, 21 Nov 2007, Mike Hommey wrote:
FWIW, I'm testing this on libxml2. I'd have some remarks:
- The .symbols file in /var/lib/dpkg/info is bigger than all the other
maintainer files there for libxml2. If a significant amount of packages
implement this, it can start to make a difference. It
Raphael Hertzog [EMAIL PROTECTED] writes:
This change was precisely meant to silence those warnings. But it looks
like this line is problematic:
return exists $self-{flags}{DYNAMIC} and $self-{flags}{DYNAMIC}
and exists $self-{SONAME} and $self-{SONAME};
It's parsed as:
(return
On Wed, 21 Nov 2007, Russ Allbery wrote:
Be careful about because you can get the opposite problem.
exists $self-{flags}{DYNAMIC $self-{flags}{DYNAMIC}
will be parsed as
exists ($self-{flags}{DYNAMIC $self-{flags}{DYNAMIC})
It's often good style to always use parens with
This one time, at band camp, Florian Weimer said:
* Russ Allbery:
As I understand it, this is only the case on i386 - on other arches,
/usr/bin/perl links to libperl, although the modules don't.
...indeed. That's bizarre. Why is i386 different than all the other
platforms?
Raphael Hertzog wrote:
Given that shlibs are still used as fallback, I don't see a reason to
remove -V, in particular given that unofficial archs might not have
symbols files when they are arch-specific and when something specific
needs to be done to add support for a new arch.
I thought that
Florian Weimer wrote:
* Russ Allbery:
As I understand it, this is only the case on i386 - on other arches,
/usr/bin/perl links to libperl, although the modules don't.
...indeed. That's bizarre. Why is i386 different than all the other
platforms?
Performance penalty of PIC code
On Wed, 21 Nov 2007, Joey Hess wrote:
Raphael Hertzog wrote:
Given that shlibs are still used as fallback, I don't see a reason to
remove -V, in particular given that unofficial archs might not have
symbols files when they are arch-specific and when something specific
needs to be done to
On Wed, Nov 21, 2007 at 10:35:50AM +0100, Raphael Hertzog wrote:
On Wed, 21 Nov 2007, Mike Hommey wrote:
FWIW, I'm testing this on libxml2. I'd have some remarks:
- The .symbols file in /var/lib/dpkg/info is bigger than all the other
maintainer files there for libxml2. If a significant
Raphael Hertzog wrote:
And shlibs files are ignored if dpkg-shlibdeps is able to find
symbols files.
Ah, that wasn't clear, I must have missed that in the documentation.
--
see shy jo
signature.asc
Description: Digital signature
* Joey Hess:
Performance penalty of PIC code due to register pressure, I guess.
I seem to remember it was a threading issue, but I didn't manage to
track down an explanation.
Well, Perl should use __thread anyway, so it's unlikely that the issue
is still present.
--
To UNSUBSCRIBE, email
Le mardi 20 novembre 2007 à 16:22 +0100, Raphael Hertzog a écrit :
2/ Watch out if adding support of symbols files break unofficial
architectures (like armel or kfreebsd-i386/amd64). Because the
pre-generated files only take into account the current list of official
architectures, so you might
Hello,
since the upload of dpkg 1.14.8 to unstable, it's now possible for
library packages to generate symbols control files that will be used by
other packages to get more accurate (and less strict) dependencies.
As this is a far reaching change, I'd like some skilled maintainers to try
it out
So FWIW, I have aalib using a symbol file, it's what I used to test the
debhelper modifications. Haven't uploaded it yet because it will have to
build-depend on the recent dpkg bugfix. Also because dpkg-shlibdeps is
now smart enough to complain about some unnecessary linkages to things
like libm
Raphael Hertzog wrote:
With debhelper 5.0.61, dh_makeshlibs will also call dpkg-gensymbols if it
finds debian/package.symbols (or debian/package.symbols.arch). So
for packages using debhelper, the only thing to do is to drop the right
symbol file(s) at the right place and add build-depends on
On Tue, 20 Nov 2007, Joey Hess wrote:
I also thought about using symbol files for the not very shared
libraries in the fbreader source package, but there's C++ symbol
mangling going on, so I think I can't.
You can, but it generally means having to handle arch-specific symbols
files because
On Tue, Nov 20, 2007 at 01:20:33PM -0500, Joey Hess wrote:
Raphael Hertzog wrote:
With debhelper 5.0.61, dh_makeshlibs will also call dpkg-gensymbols if it
finds debian/package.symbols (or debian/package.symbols.arch). So
for packages using debhelper, the only thing to do is to drop the
Raphael Hertzog [EMAIL PROTECTED] writes:
Hello,
since the upload of dpkg 1.14.8 to unstable, it's now possible for
library packages to generate symbols control files that will be used
by other packages to get more accurate (and less strict) dependencies.
As this is a far reaching change,
On Tue, Nov 20, 2007 at 04:22:56PM +0100, Raphael Hertzog wrote:
Some pre-generated symbols files can be downloaded on
http://qa.debian.org/cgi-bin/mole/seedsymbols/
Beware, those files have been auto-generated and should be verified by the
maintainer (check that the version are correct, I
On Tue, Nov 20, 2007 at 10:05:41PM +0100, Mike Hommey wrote:
On Tue, Nov 20, 2007 at 01:20:33PM -0500, Joey Hess wrote:
Raphael Hertzog wrote:
With debhelper 5.0.61, dh_makeshlibs will also call dpkg-gensymbols if it
finds debian/package.symbols (or debian/package.symbols.arch). So
for
Raphael Hertzog [EMAIL PROTECTED] writes:
since the upload of dpkg 1.14.8 to unstable, it's now possible for
library packages to generate symbols control files that will be used
by other packages to get more accurate (and less strict) dependencies.
As this is a far reaching change, I'd like
This one time, at band camp, Russ Allbery said:
* The new warnings from the dpkg-* tools warn about any binary Perl
module because all binary Perl modules use symbols from Perl itself but
traditionally aren't linked directly against libperl. (There was some
reason for this that I
This one time, at band camp, Russ Allbery said:
Stephen Gran [EMAIL PROTECTED] writes:
This one time, at band camp, Russ Allbery said:
* The new warnings from the dpkg-* tools warn about any binary Perl
module because all binary Perl modules use symbols from Perl itself but
Raphael Hertzog [EMAIL PROTECTED] writes:
Integrated documentation
The existing documentation is integrated in various dpkg manual pages:
- dpkg-gensymbols(1)
- dpkg-shlibdeps(1)
- deb-symbols(5)
In case anyone would like to do some minor coding around this, I'd
On Tue, 20 Nov 2007, Joey Hess wrote:
Raphael Hertzog wrote:
With debhelper 5.0.61, dh_makeshlibs will also call dpkg-gensymbols if it
finds debian/package.symbols (or debian/package.symbols.arch). So
for packages using debhelper, the only thing to do is to drop the right
symbol file(s)
On Tue, 20 Nov 2007, Mike Hommey wrote:
Are the @Base in these files really necessary ?
With the current code, IIRC yes.
I mean, most packages have no symbol versioning and thus use the Base
version. Does it work without it being explicitly put ?
Probably not.
If not, don't you think it
28 matches
Mail list logo
