Marcel Moolenaar wrote:
You have the problem; you also have the solution. I don't want the complete
history of development bundled in a library. That's my problem. Now tell me
how do I solve it?
Well, yes, this is a problem, and I cannot offer a solution. I only
will say the following only
Marcel Moolenaar wrote:
You have the problem; you also have the solution. I don't want the complete
history of development bundled in a library. That's my problem. Now tell me
how do I solve it?
Well, yes, this is a problem, and I cannot offer a solution. I only
will say the following only as
Marcel Moolenaar wrote:
I suggest to try to avoid the version bump. NetBSD-like way to do it:
Give new implementations another names in object files, so that they
don't conflict with old implementations, and preserve old
implementations in the library too. To make the compiler generate
Dmitrij Tejblum wrote:
Marcel Moolenaar wrote:
I suggest to try to avoid the version bump. NetBSD-like way to do it:
Give new implementations another names in object files, so that they
don't conflict with old implementations, and preserve old
implementations in the library
Dmitrij Tejblum wrote:
Other OSes started to avoid version bumps. Linux promises to not bump
the libc version since glibc2.
Yes, we now have a multitude of patches floating around for all those
glibc2 binaries that just won't work on glibc2.1. Instead of a simple and
intuitive
For what it's worth, I agree with Marcel. Version bumps should be
discouraged, but not totally avoided.
What is the reason to not avoid the version bump?
Carrying around old libraries
with older version numbers is *hardly* a burden for the users, and those
folks who are running old
Marcel Moolenaar wrote:
Dmitrij Tejblum wrote:
Dmitrij Tejblum wrote:
Other OSes started to avoid version bumps. Linux promises to not bump
the libc version since glibc2.
Yes, we now have a multitude of patches floating around for all those
glibc2 binaries that just
Marcel Moolenaar wrote:
I suggest to try to avoid the version bump. NetBSD-like way to do it:
Give new implementations another names in object files, so that they
don't conflict with old implementations, and preserve old
implementations in the library too. To make the compiler generate
Dmitrij Tejblum wrote:
Marcel Moolenaar wrote:
I suggest to try to avoid the version bump. NetBSD-like way to do it:
Give new implementations another names in object files, so that they
don't conflict with old implementations, and preserve old
implementations in the library
Dmitrij Tejblum wrote:
Other OSes started to avoid version bumps. Linux promises to not bump
the libc version since glibc2.
Yes, we now have a multitude of patches floating around for all those
glibc2 binaries that just won't work on glibc2.1. Instead of a simple and
intuitive message
For what it's worth, I agree with Marcel. Version bumps should be
discouraged, but not totally avoided.
What is the reason to not avoid the version bump?
Carrying around old libraries
with older version numbers is *hardly* a burden for the users, and those
folks who are running old
Marcel Moolenaar wrote:
Dmitrij Tejblum wrote:
Dmitrij Tejblum wrote:
Other OSes started to avoid version bumps. Linux promises to not bump
the libc version since glibc2.
Yes, we now have a multitude of patches floating around for all those
glibc2 binaries that just
Another issue when sigset_t changes is the version numbers of shared
libraries. Since libc and libc_r have changed on the interface level, they
need a version bump.
I suggest to try to avoid the version bump. NetBSD-like way to do it:
Give new implementations another names in object files,
Another issue when sigset_t changes is the version numbers of shared
libraries. Since libc and libc_r have changed on the interface level, they
need a version bump.
I suggest to try to avoid the version bump. NetBSD-like way to do it:
Give new implementations another names in object files, so
Just a few comments...
2) The casting of VFS ops to eopnotsupp() has been removed and
vfs_nop*() functions have been put into kern/vfs_default.c
This makes it more clear that certain VFS-ops are giving default
behavior, either returning automatic success or returning EOPNOTSUPP.
Just a few comments...
2) The casting of VFS ops to eopnotsupp() has been removed and
vfs_nop*() functions have been put into kern/vfs_default.c
This makes it more clear that certain VFS-ops are giving default
behavior, either returning automatic success or returning EOPNOTSUPP.
I don't think that this dump is useful for debugging this problem. Perhaps,
if
you compile the kernel with DEBUG_LOCKS, you will get more useful info.
I checked through the source for DEBUG_LOCKS, it doesn't appear to do anything
other than to printout information information that
I am trying to trace down the cause of the recursive lock and I stumbled upon
this:
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
#1 0xc014b3f4 in at_shutdown (
function=0xc0234aca
__set_sysuninit_set_sym_M_KTRACE_uninit_sys_uninit+154, arg=0x10002,
18 matches
Mail list logo
