[prev in list] [next in list] [prev in thread] [next in thread] 

List:       zeromq-dev
Subject:    Re: [zeromq-dev] Build failure in python?
From:       Adrian von Bidder <avbidder () fortytwo ! ch>
Date:       2010-01-25 13:55:41
Message-ID: 201001251455.41375 () fortytwo ! ch
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 25 January 2010 12.43:46 Martin Sustrik wrote:
> Hi Adrian,
> 
> > Note that I'd like to use -Wl,-z,defs to get rid of a few unneeded
> > package dependencies, but that's a minor issue really (and in the
> > specific case of zeromq, IIRC there's just one or two dependencies.)
> >
> > So I'll just skip that for now.  Should I open a bug report or do you
> > take care of it?
> 
> What ld man page says about -z defs:
> 
>             Report unresolved symbol references from regular object
> files.  This is done even if the linker is creating a non-symbolic
> shared library.  The switch --[no-]allow-shlib-undefined controls
>             the behaviour for reporting unresolved references found in
> shared libraries being linked in.
> 
> So as far as I understand, the only effect of the option is to generate
> additional errors. How does it help you to remove the dependencies?

Sorry, my memory was not quite exact.  Here's what's actually happens:

Package dependencies on libraries in Debian are generated automatically 
based on what symbols are used by the binaries contained in a package.  (In 
earlier times these dependencies had to be maintained manually and 
maintainers had to keep track of which library changed version, which is 
quite an error prone process when packages like openoffice or KDE use 20 or 
more libraries.)

So -z defs together with --as-needed (which I forgot to specify, sorry) are 
required to ensure that all libraries are linked against the libraries they 
need, and (the 2nd half, by --as-needed) only to those they directly need 
and not all those that are linked indirectly (libfoo uses to libbar which in 
turn linnks libbrabbel -- we don't want a dependency from bar to foo but not 
from foo to brabbel.)  

Specifically: it is good practice to have the python extension being linked 
to libpython2.5.so, which is what apparently doesn't happen.  Obviously, 
since it's a python extension, it will be loaded by the python interpreter 
which has libpython2.5.so loaded already, so the unresolved symbols in the 
extension will get resolved at load time.

For now: as I said, I'll just do the package without -z defs and hope I 
catch all necessary dependencies.

cheers
-- vbi


-- 
Lenny will have significantly better Debian support than Etch.
        -- Russel Coker

A few hours later correcting himself with:
It is unfortunately easy when using many technical terms to dereference
the wrong mental pointer.  In the above I meant to say "Lenny will have
significantly better SE Linux support than Etch".

["signature.asc" (application/pgp-signature)]

_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


[prev in list] [next in list] [prev in thread] [next in thread]