4:22 p.m.
Hello,
Sometimes changes in the compiler leads to binary incompatibility. How
to deal with these kind of incompatibilitites? I don't think that using
the soname for those kind of incompatibilities is right, are there other
technniques?
The transition I have in mind is the g77 -> gfortran transition. In fact
some (many?) packages are already transitionned, but I am not sure that
this issue has been taken into account. And it also applies to C++ and
C binary compatibility issues arising from the compiler changes.
--
Pat
3:23 a.m.
Patrice Dumas writes:
Sometimes changes in the compiler leads to binary incompatibility. How
to deal with these kind of incompatibilitites? I don't think that using
the soname for those kind of incompatibilities is right, are there other
technniques?
The soname is the right way to do it. Why do you believe otherwise?
Andrew.
--
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903
3:23 a.m.
On Tue, Apr 17, 2007 at 09:23:46AM +0100, Andrew Haley wrote:
Patrice Dumas writes:
>
> Sometimes changes in the compiler leads to binary incompatibility. How
> to deal with these kind of incompatibilitites? I don't think that using
> the soname for those kind of incompatibilities is right, are there other
> technniques?
The soname is the right way to do it. Why do you believe otherwise?
It seemed to me that the soname was used to track the ABI compatibility
issues arising from changes in the library. This means using the
upstream soname scheme (at least when it is not broken). But I may be
wrong.
--
Pat
3:38 a.m.
Patrice Dumas writes:
On Tue, Apr 17, 2007 at 09:23:46AM +0100, Andrew Haley wrote:
> Patrice Dumas writes:
> >
> > Sometimes changes in the compiler leads to binary incompatibility. How
> > to deal with these kind of incompatibilitites? I don't think that using
> > the soname for those kind of incompatibilities is right, are there other
> > technniques?
>
> The soname is the right way to do it. Why do you believe otherwise?
It seemed to me that the soname was used to track the ABI compatibility
issues arising from changes in the library.
Yes.
This means using the upstream soname scheme (at least when it is
not broken).
That's right. So what is the problem you want to solve?
Andrew.
--
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903
3:59 a.m.
On Tue, Apr 17, 2007 at 09:38:31AM +0100, Andrew Haley wrote:
> It seemed to me that the soname was used to track the ABI
compatibility
> issues arising from changes in the library.
Yes.
> This means using the upstream soname scheme (at least when it is
> not broken).
That's right. So what is the problem you want to solve?
I am trying to solve the issue of binary incompatibility introduced by ABI
changes triggered by changes in the compiler (for example g77 ->
gfortran transition, C or C++ ABI change).
--
Pat
4:28 a.m.
Patrice Dumas writes:
On Tue, Apr 17, 2007 at 09:38:31AM +0100, Andrew Haley wrote:
> > It seemed to me that the soname was used to track the ABI compatibility
> > issues arising from changes in the library.
>
> Yes.
>
> > This means using the upstream soname scheme (at least when it is
> > not broken).
>
> That's right. So what is the problem you want to solve?
I am trying to solve the issue of binary incompatibility introduced by ABI
changes triggered by changes in the compiler (for example g77 ->
gfortran transition, C or C++ ABI change).
This is exhausting. Please explain why the soname scheme does not
work for changes in the compiler as well as for changes in the
library!
Andrew.
--
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903
4:35 a.m.
On Tue, Apr 17, 2007 at 10:28:48AM +0100, Andrew Haley wrote:
Patrice Dumas writes:
This is exhausting. Please explain why the soname scheme does not
work for changes in the compiler as well as for changes in the
library!
Maybe it does, but is it that way that such issues should be handled
in fedora? changing soname upon a compiler-related ABI breaking leads
to following another soname versionning scheme than upstream, I doubt
this is right, and I don't think such issues are handled that way in
fedora.
--
Pat
4:45 a.m.
Patrice Dumas writes:
On Tue, Apr 17, 2007 at 10:28:48AM +0100, Andrew Haley wrote:
> Patrice Dumas writes:
>
> This is exhausting. Please explain why the soname scheme does not
> work for changes in the compiler as well as for changes in the
> library!
Maybe it does, but is it that way that such issues should be handled
in fedora? changing soname upon a compiler-related ABI breaking leads
to following another soname versionning scheme than upstream, I doubt
this is right, and I don't think such issues are handled that way in
fedora.
Maybe I'm having difficulty understanding you. Is the problem that a
Red Hat compiler version is binary incompatible with the upstream
compiler? And we have not handled library versioning correctly?
Andrew.
--
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903
5:23 a.m.
On Tue, Apr 17, 2007 at 10:45:27AM +0100, Andrew Haley wrote:
Maybe I'm having difficulty understanding you. Is the problem that a
Red Hat compiler version is binary incompatible with the upstream
compiler? And we have not handled library versioning correctly?
No, the issue is that the library compiled with the fedora compiler
in previous fedora release isn't ABI compatible with the library compiled
with the fedora compiler in current release. This is not an issue as such,
but the problem I see is that the user can only know that when there are
runtime crashs or misbehaving if there was no soname change. With a
soname change it is a bit better because there will be a typical error
message right when starting the application.
--
Pat
5:42 a.m.
On Tue, Apr 17, 2007 at 10:45:27AM +0100, Andrew Haley wrote:
> Maybe it does, but is it that way that such issues should be
handled
> in fedora? changing soname upon a compiler-related ABI breaking leads
> to following another soname versionning scheme than upstream, I doubt
> this is right, and I don't think such issues are handled that way in
> fedora.
Maybe I'm having difficulty understanding you. Is the problem that a
Red Hat compiler version is binary incompatible with the upstream
compiler? And we have not handled library versioning correctly?
If I understand him well this is not about compiler support library
SONAMEs, which are matching upstream (except for libgcj libs ;) )
and even use completely different library name sometimes (libg2c vs.
libgfortran), but about various tiny packages written in fortran/java
or perhaps C++ (if/once we change libstdc++ SONAME again).
For these *.a libs are unquestionable, backward compatibility
is only guaranteed for shared libraries and executables, so *.a
has to be always rebuilt on the target distro (as it has always been
the case).
But, if you have package foo, which uses upstream SONAME for its
library libfoo.so.13 and it used to be compiled with g77 and say in
F7 we start building it with gfortran, i.e. different ABI, although
there is a tiny differentiator that before the library dependent on
libg2c.so.0 and now on libgfortran.so.1, there is really nothing
which will immediately tell that you really can't run program
bar that was linked with g77 against that g77 built libfoo.so.13.
In this case I think we need a different SONAME for libfoo.so,
but how it looks like should result from discussions with upstream.
It can be libfoo.so.14, libfoo.so.13gfortran, libfoo_gfortran.so.13
or something, whatever upstream prefers.
Jakub
8:24 a.m.
On Tue, Apr 17, 2007 at 06:42:06AM -0400, Jakub Jelinek wrote:
In this case I think we need a different SONAME for libfoo.so,
but how it looks like should result from discussions with upstream.
It can be libfoo.so.14, libfoo.so.13gfortran, libfoo_gfortran.so.13
or something, whatever upstream prefers.
That's exactly what I was looking for, much thanks. In my precise case
upstream doesn't ship shared libs, and it is more with the debian
maintainer that there is coordination.
I think it would be nice, in the future, to have guidance for
packagers when there is a change in compiler generated library ABI like
the g77 -> gfortran change or past C++ ABI breakage I remember. If I
recall well these issues were more or less announced, but not
necessarily with enough precisions for the maintainers. I don't know
exactly who should be responsible of such things, but it would be nice
to have some information.
--
Pat
3:38 a.m.
On Mon, 16 Apr 2007, Patrice Dumas wrote:
Sometimes changes in the compiler leads to binary incompatibility.
How
to deal with these kind of incompatibilitites? I don't think that using
the soname for those kind of incompatibilities is right, are there other
technniques?
The Fedora technique has been to rebuild all packages when a new compiler
breaking the ABI is introduced. This means new compiler ABIs can only
coincide with new Fedora releases, and it's been working quite well.
Linus
3:59 a.m.
On Tue, Apr 17, 2007 at 10:38:32AM +0200, Linus Walleij wrote:
On Mon, 16 Apr 2007, Patrice Dumas wrote:
>Sometimes changes in the compiler leads to binary incompatibility. How
>to deal with these kind of incompatibilitites? I don't think that using
>the soname for those kind of incompatibilities is right, are there other
>technniques?
The Fedora technique has been to rebuild all packages when a new compiler
breaking the ABI is introduced. This means new compiler ABIs can only
coincide with new Fedora releases, and it's been working quite well.
But what about user compiled programs that are not in the Fedora
collection?
--
Pat
5:25 a.m.
On Tue, Apr 17, 2007 at 11:43:55AM +0200, Emmanuel Seyman wrote:
* Patrice Dumas [17/04/2007 11:15] :
>
> But what about user compiled programs that are not in the Fedora
> collection?
IMHO, they should probably be rebuilt for each new Fedora release as well.
Is that documented/advertised somewhere?
--
Pat
5:39 a.m.
Patrice Dumas writes:
On Tue, Apr 17, 2007 at 11:43:55AM +0200, Emmanuel Seyman wrote:
> * Patrice Dumas [17/04/2007 11:15] :
> >
> > But what about user compiled programs that are not in the Fedora
> > collection?
>
> IMHO, they should probably be rebuilt for each new Fedora release as well.
Is that documented/advertised somewhere?
It depends on which libraries you're talking about. For those that
don't have a stable ABI, you have to rebuild; for those that do have a
standard ABI (libc and libgcj-bc, for example) you don't.
Andrew.
--
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903
1:25 p.m.
On Tue, 17 Apr 2007, Patrice Dumas wrote:
> The Fedora technique has been to rebuild all packages when a new
compiler
> breaking the ABI is introduced. This means new compiler ABIs can only
> coincide with new Fedora releases, and it's been working quite well.
But what about user compiled programs that are not in the Fedora
collection?
Include the program into Fedora if it is generally useful.
Or release new binaries with each new Fedora release (.fc6 package, .fc7
package ...)
That's the current rationale.
This is also the reason why EDA vendors and whathaveyou proprietary
software tie their software to RHEL (Red Hat Enterprise Linux). That
product has a slow release cycle and long support cycle and that's exactly
what someone packaging binary software wants.
For a mainly source-recompile-based distro like Fedora, we can break the
ABI with each release and also happily do so :)
Linus
4:28 p.m.
On Tue, Apr 17, 2007 at 08:25:31PM +0200, Linus Walleij wrote:
Include the program into Fedora if it is generally useful.
Don't worry about that, I package a lot, in Fedora or in private repos,
but it doesn't make sense to package every code. For a personal case,
numerical models are not to be packaged.
Or release new binaries with each new Fedora release (.fc6 package,
.fc7
package ...)
That's the current rationale.
Ok, but it is better if linking fails instead of having runtime issues.
I don't want to recompile for the sake of recompiling. Not to mention
that some compilation may be resource hungry.
This is also the reason why EDA vendors and whathaveyou proprietary
software tie their software to RHEL (Red Hat Enterprise Linux). That
product has a slow release cycle and long support cycle and that's exactly
what someone packaging binary software wants.
You have a use case in mind which is far from the general use case of
libraries. As a side note, and unless I'm wrong on Centos 4 I get an
ICE on some of my compilations, while at some points I could run the
programs dynamically linked on fedora just fine on Centos (nowadays
time it is not possible anymore and I compile statically, but at some
point it was possible).
For a mainly source-recompile-based distro like Fedora, we can break
the
ABI with each release and also happily do so :)
Ok, but this should really be said explicitely somewhere. Maybe it is,
but I never stumbled on it.
Anyway Jakub proposed to use the soname to add this information, this
seems more user-friendly to me.
--
Pat
6268
days inactive
6269
days old
17 comments
5 participants
participants (5)
-
Andrew Haley -
Emmanuel Seyman -
Jakub Jelinek -
Linus Walleij -
Patrice Dumas