FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 11-20-2007, 09:40 PM
Stephen Gran
 
Default Early adopters of symbol based dependencies needed

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 don't recall off-hand.) Should these warnings
> just be ignored? Suppressed in some way? Should binary Perl modules
> link against libperl? I haven't worked through the implications in my
> head yet.

See #416266 for an example of why it would be nice if they did. Linking
the binary perl modules to libperl does make this problem go away, but
I've been waiting to push it over to the perl folks until we have
something resembling patches.
--
-----------------------------------------------------------------
| ,'`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
 
Old 11-20-2007, 09:49 PM
Russ Allbery
 
Default Early adopters of symbol based dependencies needed

Stephen Gran <sgran@debian.org> 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
>> traditionally aren't linked directly against libperl. (There was some
>> reason for this that I don't recall off-hand.) Should these warnings
>> just be ignored? Suppressed in some way? Should binary Perl modules
>> link against libperl? I haven't worked through the implications in my
>> head yet.

> See #416266 for an example of why it would be nice if they did. Linking
> the binary perl modules to libperl does make this problem go away, but
> I've been waiting to push it over to the perl folks until we have
> something resembling patches.

Oh, right, that's the problem. /usr/bin/perl doesn't use libperl itself
and instead just exports the same symbols to any modules it loads. So if
the module is linked with libperl, when the module is loaded by the Perl
interpretor, it loads libperl into the same namespace, the Perl
interpretor and libperl both define the same symbols, and the world
explodes.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-20-2007, 10:13 PM
Stephen Gran
 
Default Early adopters of symbol based dependencies needed

This one time, at band camp, Russ Allbery said:
> Stephen Gran <sgran@debian.org> 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
> >> traditionally aren't linked directly against libperl. (There was some
> >> reason for this that I don't recall off-hand.) Should these warnings
> >> just be ignored? Suppressed in some way? Should binary Perl modules
> >> link against libperl? I haven't worked through the implications in my
> >> head yet.
>
> > See #416266 for an example of why it would be nice if they did. Linking
> > the binary perl modules to libperl does make this problem go away, but
> > I've been waiting to push it over to the perl folks until we have
> > something resembling patches.
>
> Oh, right, that's the problem. /usr/bin/perl doesn't use libperl itself
> and instead just exports the same symbols to any modules it loads. So if
> the module is linked with libperl, when the module is loaded by the Perl
> interpretor, it loads libperl into the same namespace, the Perl
> interpretor and libperl both define the same symbols, and the world
> explodes.

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.
--
-----------------------------------------------------------------
| ,'`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
 
Old 11-20-2007, 10:15 PM
Russ Allbery
 
Default Early adopters of symbol based dependencies needed

Raphael Hertzog <hertzog@debian.org> 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 love to
have a lintian check for proper formatting of the symbols file (and
possibly also to check that the proper dpkg-dev and debhelper dependencies
are present if a *.symbols file is found in the debian directory).

I'll probably end up writing one myself eventually, but I don't have much
time to work on it at the moment.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-20-2007, 10:18 PM
Russ Allbery
 
Default Early adopters of symbol based dependencies needed

Stephen Gran <sgran@debian.org> writes:
> This one time, at band camp, Russ Allbery said:

>> Oh, right, that's the problem. /usr/bin/perl doesn't use libperl
>> itself and instead just exports the same symbols to any modules it
>> loads. So if the module is linked with libperl, when the module is
>> loaded by the Perl interpretor, it loads libperl into the same
>> namespace, the Perl interpretor and libperl both define the same
>> symbols, and the world explodes.

> 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?

If /usr/bin/perl linked with libperl on every platform, we should be able
to safely change modules to link with libperl without creating any
problems. But right now, that change would probably break things on i386
in obscure and bizarre ways.

(One of the standard nasty problems with multiple copies of the same
symbols is that different versions of a function get called at different
times and, when they use any static data, that static data is different
between the different instances. It creates incredibly weird problems
that are horrible to debug.)

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-21-2007, 06:28 AM
Raphael Hertzog
 
Default Early adopters of symbol based dependencies needed

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) at the right place and add build-depends on dpkg-dev (>= 1.14.9)
> > and debhelper (>= 5.0.61).
>
> I suppose you'd also want to stop passing -V to dh_makeshlibs,
> since the symbol versioning should take care of setting the version.
> -V without any parameters is evil anyway.
>
> Although, what happens if a package is built against the library on
> a buildd that doesn't have the new dpkg-dev yet? It would generate a
> wrong unversioned dependency in this case.

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.

Cheers,
--
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-21-2007, 06:46 AM
Raphael Hertzog
 
Default Early adopters of symbol based dependencies needed

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 would make sense ?

Maybe, someone else already made the remark, but I like when things are
explicit.

Cheers,
--
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-21-2007, 06:58 AM
Mike Hommey
 
Default Early adopters of symbol based dependencies needed

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 a far reaching change, I'd like some skilled maintainers to try
> it out "for real" and help me flesh out some generic guidelines so that when
> we start using it on more packages, we do it right from the first time.
>
> The wiki page http://wiki.debian.org/UsingSymbolsFiles will be used to
> collect various remarks and prepare some useful documentation that will
> be later spread to maintainers through d-d-a (and maybe merged back in
> some dpkg manual page).

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 might be nice to
support a gzipped format.
- Python modules have the same problem as perl modules: the interpreter
doesn't link against the library, so they can't either. That makes a
whole bunch of warnings for each symbol not found... I'm not sure what
should be done for that.

Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-21-2007, 07:54 AM
Raphael Hertzog
 
Default Early adopters of symbol based dependencies needed

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 removing the Debian revision in cases like
> this to make backporting easier.

Good point. Added to the wiki page.

> * 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 don't recall off-hand.) Should these warnings
> just be ignored? Suppressed in some way? Should binary Perl modules
> link against libperl? I haven't worked through the implications in my
> head yet.

This is not normal.
http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=6e02b2ef46aadde5ce142bb42b58e3 165253eb58

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 exists $self->{flags}{DYNAMIC}) and ...

Replacing "and" by "&&" fixes the problem. It's weird because I'm pretty sure it
worked before and I tested it. Anyway, it's fixed in git and will be in the next
dpkg version.

Cheers,
--
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-21-2007, 08:12 AM
Russ Allbery
 
Default Early adopters of symbol based dependencies needed

Raphael Hertzog <hertzog@debian.org> 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 exists $self->{flags}{DYNAMIC}) and ...
>
> Replacing "and" by "&&" fixes the problem. It's weird because I'm pretty
> sure it worked before and I tested it. Anyway, it's fixed in git and
> will be in the next dpkg version.

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 the argument to defined or
exists because they're most often the functions that get bitten by this.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 09:47 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org