Dmitrij Tejblum wrote:
> FreeBSD 4.0 currently have a nice feature - libc compatibility with
> FreeBSD 3.x. That is, I can link a program build on 3.x with the libc
> build from src/lib/libc on -current, either dynamically or statically.
> I also can do it in other way around. I _use_ this feature
Dmitrij Tejblum wrote:
> FreeBSD 4.0 currently have a nice feature - libc compatibility with
> FreeBSD 3.x. That is, I can link a program build on 3.x with the libc
> build from src/lib/libc on -current, either dynamically or statically.
> I also can do it in other way around. I _use_ this featur
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
Richard Wackerbarth wrote:
>
> On Thu, 09 Sep 1999, Marcel Moolenaar wrote:
> > Sheldon Hearn wrote:
>
> > I'm more tempted to revert to the major/minor versioning. Every change
> > triggers a minor version bump, but only if the library is still backwards
> > compatible with minor version 0 and t
Dmitrij Tejblum wrote:
>
> > > It is other way around. I don't want half of FreeBSD binaries linked
> > > with libc.so.3 and half is linked with libc.so.4.
> >
> > Recompile. You have the sources.
>
> ??? What recompile? Why do you think I have the sources - there is
> quite a few binary-only Fre
Richard Wackerbarth wrote:
>
> On Thu, 09 Sep 1999, Marcel Moolenaar wrote:
> > Sheldon Hearn wrote:
>
> > I'm more tempted to revert to the major/minor versioning. Every change
> > triggers a minor version bump, but only if the library is still backwards
> > compatible with minor version 0 and
Dmitrij Tejblum wrote:
>
> > > It is other way around. I don't want half of FreeBSD binaries linked
> > > with libc.so.3 and half is linked with libc.so.4.
> >
> > Recompile. You have the sources.
>
> ??? What recompile? Why do you think I have the sources - there is
> quite a few binary-only Fr
On Thu, 09 Sep 1999, Marcel Moolenaar wrote:
> Sheldon Hearn wrote:
> I'm more tempted to revert to the major/minor versioning. Every change
> triggers a minor version bump, but only if the library is still backwards
> compatible with minor version 0 and the same major version. Otherwise a
> major
On Thu, 09 Sep 1999, Nate Williams wrote:
> > I'm more tempted to revert to the major/minor versioning.
>
> ELF has no minor revision number (IMO a mistake, but it's not my call).
I agree that it is a mistake.
However, if you think of "major" changes as different libraries, it does make
sense. W
On Thu, 09 Sep 1999, Marcel Moolenaar wrote:
> Sheldon Hearn wrote:
> I'm more tempted to revert to the major/minor versioning. Every change
> triggers a minor version bump, but only if the library is still backwards
> compatible with minor version 0 and the same major version. Otherwise a
> majo
On Thu, 09 Sep 1999, Nate Williams wrote:
> > I'm more tempted to revert to the major/minor versioning.
>
> ELF has no minor revision number (IMO a mistake, but it's not my call).
I agree that it is a mistake.
However, if you think of "major" changes as different libraries, it does make
sense.
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
> > > gli
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
> > > gl
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 won't work on glibc
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 won't work on glib
> > 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?
Because if you don't have the latest/greatest library (old machines),
newer programs that are compiled against the latest/greates
> 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 ve
> > 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?
Because if you don't have the latest/greatest library (old machines),
newer programs that are compiled against the latest/greate
> 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 v
> > > Yes, we shouldn't version bump every time someone has a whim, ending
> > > up with 10 version bumps/week, but neither should we avoid them
> > > altogether and cause the Linux syndrome of programs refusing to work
> > > because they have the *wrong* version of glibc2.3 (or whatever)
> >
Sheldon Hearn wrote:
>
> On Thu, 09 Sep 1999 10:56:05 CST, Nate Williams wrote:
>
> > Yes, we shouldn't version bump every time someone has a whim, ending
> > up with 10 version bumps/week, but neither should we avoid them
> > altogether and cause the Linux syndrome of programs refusing to work
>
> 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
> intuiti
> > > Yes, we shouldn't version bump every time someone has a whim, ending
> > > up with 10 version bumps/week, but neither should we avoid them
> > > altogether and cause the Linux syndrome of programs refusing to work
> > > because they have the *wrong* version of glibc2.3 (or whatever)
> >
Sheldon Hearn wrote:
>
> On Thu, 09 Sep 1999 10:56:05 CST, Nate Williams wrote:
>
> > Yes, we shouldn't version bump every time someone has a whim, ending
> > up with 10 version bumps/week, but neither should we avoid them
> > altogether and cause the Linux syndrome of programs refusing to work
On Thu, 09 Sep 1999 10:56:05 CST, Nate Williams wrote:
> Yes, we shouldn't version bump every time someone has a whim, ending
> up with 10 version bumps/week, but neither should we avoid them
> altogether and cause the Linux syndrome of programs refusing to work
> because they have the *wrong* v
> 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
> intuit
> > > I strongly disagree. Spitting "unresolved references" is *not* a way to
> > > tell the user that he doesn't have the right libraries.
> >
> > I strongly disagree. This is much better than version bump. After all,
> > we can add suggestion to upgrade libraries to the "unresolved references"
>
On Thu, 09 Sep 1999 10:56:05 CST, Nate Williams wrote:
> Yes, we shouldn't version bump every time someone has a whim, ending
> up with 10 version bumps/week, but neither should we avoid them
> altogether and cause the Linux syndrome of programs refusing to work
> because they have the *wrong*
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 like
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 like
> > > I strongly disagree. Spitting "unresolved references" is *not* a way to
> > > tell the user that he doesn't have the right libraries.
> >
> > I strongly disagree. This is much better than version bump. After all,
> > we can add suggestion to upgrade libraries to the "unresolved references"
> 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
> > > > implementati
> 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
> > > > implementat
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 lib
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 li
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 gener
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 gene
Dmitrij Tejblum wrote:
>
> > 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 implementa
Dmitrij Tejblum wrote:
>
> > 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 implement
> 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 assume that all others automaticly also need a
> version bump then. Am I correct in this assumption?
Libc_r already had a ver
Hi,
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 assume that all others automaticly also need a
version bump then. Am I correct in this assumption?
--
Marcel Moolenaar
> 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 assume that all others automaticly also need a
> version bump then. Am I correct in this assumption?
Libc_r already had a ve
Hi,
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 assume that all others automaticly also need a
version bump then. Am I correct in this assumption?
--
Marcel Moolenaar
46 matches
Mail list logo
