* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > Looks good to me. It can't go into policy yet, though. Not enough
> > machinery, and we really need to have all core libs converted and working to
> > whatever policy we choose before we propose it.
>
> Yes, and I consider libpkg-guide to be a place
> Looks good to me. It can't go into policy yet, though. Not enough
> machinery, and we really need to have all core libs converted and working to
> whatever policy we choose before we propose it.
Yes, and I consider libpkg-guide to be a place to
start documenting things before policy is changed
On Thu, 20 Mar 2003, Junichi Uekawa wrote:
> I consider the following portion may be suitable for inclusion in the
> policy; if it is more precisely worded:
>
> If library or application dlopens a module, that module and its chain of
> dependencies have a chance of being loaded in two versions a
> > > dlopening with RTDL_GLOBAL, where there is an option to
> > > dlopen with RTDL_LOCAL.
> >
> > hmm... how does that behaves when the conflict is two or more libs down the
> > chain from the PoV of the stuff being dlopened?
>
> I have thought that symbols are resolved locally, as to allow
>
t
symbol resolution. There are a number of complex cases (increasingly
common) that are not addressed by -Bsymbolic; and the only viable fix
for those same cases (i.e., versioned symbols) renders -Bsymbolic
unnecessary.
See bug #184509 for another real-world bug not addressed by -Bsymbolic.
dlopening RTLD_LOCAL does not actually solve the problem. Symbols
from the namespace of the application can override symbols pulled in
by the libraries.
RTLD_GROUP, not supported by glibc, comes fairly close to being
sufficient in most cases.
> > dlopening with RTDL_GLOBAL, where there is an option to
> > dlopen with RTDL_LOCAL.
>
> hmm... how does that behaves when the conflict is two or more libs down the
> chain from the PoV of the stuff being dlopened?
I have thought that symbols are resolved locally, as to allow
modules to be li
On Wed, 12 Mar 2003, Junichi Uekawa wrote:
> That is caused by dlopen used by PAM, which I assume is caused by
Or dlopen used by glibc (nss modules), or dlopen used by anything else.
Apache modules can kill apache that way too, for example (afaik anyway).
> dlopening with RTDL_GLOBAL, where there
> Sorry, I did not follow the discussion closely, so I may
> understand this wrong. But how does your proposal solve the
> following situation?
>
> libfoo1 Build-Depends on libssl0.9.6-dev
> libfoo2 Build-Depends on libssl0.9.7-dev
> libbreakseverything Build-Depends on libfoo1-dev an
> At time X libssl0.9.6-dev is in Debian.
> At time X ssh is built against libssl0.9.6-dev.
> At time Y libssl0.9.7-dev is uploaded to Debian.
> At time Y libldap2 is built against libssl0.9.7-dev.
> At time Z a user installs libssl0.9.6, libssl0.9.7, ssh, libldap2
> and libpam-ldap, all of which
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > What about it would avoid libssl0.9.6 problems? Nothing I saw would
> > solve the problems of multiple versions of a library ending up linked
> > into the same process except the symbol versioning portion, which is
> > what I'm advocating here but yo
* Richard Braakman ([EMAIL PROTECTED]) wrote:
> I think it would avoid the problem, but it would be a major headache
> to deal with in practice. It would be as bad as tcl4.* used to be,
> and I'm glad we left THAT behind.
It won't solve the problem, please read my reply to him for a better
unders
On Wed, 12 Mar 2003, Anthony Towns wrote:
> On Tue, Mar 11, 2003 at 10:47:34AM -0300, Henrique de Moraes Holschuh wrote:
> > It doesn't need to, either. Whatever isn't in the LSB doesn't matter as far
> > as interoperatibility is concerned [if the LSB is done right].
>
> Uh, libqt isn't standard
On Tue, Mar 11, 2003 at 10:47:34AM -0300, Henrique de Moraes Holschuh wrote:
> It doesn't need to, either. Whatever isn't in the LSB doesn't matter as far
> as interoperatibility is concerned [if the LSB is done right].
Uh, libqt isn't standardised by the LSB, and probably won't be.
Cheers,
aj
On Tue, 11 Mar 2003, Anthony Towns wrote:
> On Mon, Mar 10, 2003 at 10:47:40AM -0300, Henrique de Moraes Holschuh wrote:
> > Agreed. As far as "programs build on Debian systems won't run elsewhere",
> > it is just a matter of pushing the versioning of said core libraries to the
> > LSB, which shou
On Tue, Mar 11, 2003 at 08:14:50AM +0100, Jochen Voss wrote:
> Sorry, I did not follow the discussion closely, so I may
> understand this wrong. But how does your proposal solve the
> following situation?
>
> libfoo1 Build-Depends on libssl0.9.6-dev
> libfoo2 Build-Depends on libssl0.9.7-
On Mon, Mar 10, 2003 at 10:47:40AM -0300, Henrique de Moraes Holschuh wrote:
> Agreed. As far as "programs build on Debian systems won't run elsewhere",
> it is just a matter of pushing the versioning of said core libraries to the
> LSB, which shouldn't be too difficult if we do it right and send
On Mon, Mar 10, 2003 at 09:22:53AM -0500, Stephen Frost wrote:
> ...
>
> This doesn't solve the problem, and -Bsymbolic only solves a portion of
> the problem.
>
> ...
I have looked at -Bsymbolic, and it seems to be doing about the
same as my proposed change (see elsewhere), however the docs on
Hello,
On Tue, Mar 11, 2003 at 02:02:30PM +0900, Junichi Uekawa wrote:
> You could also take an approach of pulling out libssl-dev,
> and making packages to Build-Depend on libssl0.9.7-dev libssl0.9.6-dev
> explicitly, and starting to rebuild packages against them.
>
> That way, within Debian, it
> What about it would avoid libssl0.9.6 problems? Nothing I saw would
> solve the problems of multiple versions of a library ending up linked
> into the same process except the symbol versioning portion, which is
> what I'm advocating here but you seem to be against while offering
> 'solutions' th
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > > Consider libpng2/3 problem, and see if it possible to
> > > still possible to cause problem while following libpkg-guide.
> >
> > Yes, and I think it's frightening that you advocate staticly linking
> > things in your libpkg-guide and the fact tha
> > Consider libpng2/3 problem, and see if it possible to
> > still possible to cause problem while following libpkg-guide.
>
> Yes, and I think it's frightening that you advocate staticly linking
> things in your libpkg-guide and the fact that you even wrote one while
> apparently not entirely u
l not be satisfied until they are fixed,
> and when they are fixed, they won't be linked with the wrong
> libraries, so the problem will not happen.
I'm not entirely sure what problem you're talking about but it must not
be the one I described and that is fixed by versioned sy
> ssh-krb5 was built a while ago using libssl0.9.6. libldap2 will shortly
> be uploaded and links against libssl0.9.7. ssh-krb5 ends up linked
> against libldap2 though libpam-ldap and the PAM modules (or libnss-ldap
> and the nsswitch.conf, either way). The ssh-krb5 process ends up linked
> aga
hey are fixed,
> > > packages work.
> > >
> > > see libpkg-guide for fuller story.
> > > And I think it is one way of going without versioned symbols.
> >
> > This doesn't solve the problem, and -Bsymbolic only solves a portion of
>
gt; > see libpkg-guide for fuller story.
> > And I think it is one way of going without versioned symbols.
>
> This doesn't solve the problem, and -Bsymbolic only solves a portion of
> the problem.
It does solve the problem.
When implemented, it is impossible to link
work.
>
> see libpkg-guide for fuller story.
> And I think it is one way of going without versioned symbols.
This doesn't solve the problem, and -Bsymbolic only solves a portion of
the problem.
> Using versioned symbols is a workaround which is, although
> available within all
On Sun, 09 Mar 2003, Sam Hartman wrote:
> >> I think that we should implement versioned symbols.
> Anthony> Uhh, versioned symbols means that programs built on
> Anthony> Debian systems won't run elsewhere. That's not something
> Anthony> we sho
.
see libpkg-guide for fuller story.
And I think it is one way of going without versioned symbols.
Using versioned symbols is a workaround which is, although
available within all Debian architectures, not available on
everywhere, and considering free software as a whole,
it might be better to n
perly handle multiple library
> versions ending up linked into the same process. A few of the options
> that I've heard, though they may not be the best, are:
>
> - Implement versioned symbols
> - May cause binary compatibility issues
> - Doesn't follow L
>>>>> "Anthony" == Anthony Towns writes:
Anthony> On Sat, Mar 08, 2003 at 04:16:47PM -0500, Sam Hartman
Anthony> wrote:
>> I think that we should implement versioned symbols.
Anthony> Uhh, versioned symbols means that programs built
On Sat, Mar 08, 2003 at 04:16:47PM -0500, Sam Hartman wrote:
> I think that we should implement versioned symbols.
Uhh, versioned symbols means that programs built on Debian systems won't
run elsewhere. That's not something we should be doing, except in very
specific cases w
I think that we should implement versioned symbols. If you have not
already done so please look at the log for bug#136707. I believe my
writeup in that bug log of how versioned symbols interact with symbol
resolution and under what circumstances it will cause ABI
compatibility issues with other
As an example: for SASL (which currently causes breakage encompassing LDAP
(and through it, glibc nss modules), we would have to force-feed upstream a
SASL2 enabled source of postfix and sendmail, for example. We would also
have to drop our old openldap 2.0 and somehow get 2.1 ready.
> > -
it doesn't use ELF versioned symbols. I don't
see any evidence of version tricks in libpng3 sources.
> I agree, which is why I feel the right thing to do is get versioned
> symbols in our libraries.
Versioned symbols is a lot of work and creates a maintenance headache
for whoever main
he libdb2/libdb3 and libpng2/libpng3 bug #s for the same issue in those
libraries.
> > - Implement versioned symbols
> > - May cause binary compatibility issues
> > - Doesn't follow LSB (I believe..)
> > - Could be difficult to do correctly
>
> Very h
Previously Stephen Frost wrote:
> We need to make a decision on how to properly handle multiple library
> versions ending up linked into the same process.
I think what we should do is simple: 'do not do that'.
> - Implement versioned symbols
> - May cause binar
that I've heard, though they may not be the best, are:
- Implement versioned symbols
- May cause binary compatibility issues
- Doesn't follow LSB (I believe..)
- Could be difficult to do correctly
- Conflict between library versions
- Wouldn't allow valid s
38 matches
Mail list logo
