Mail Archives: cygwin/1999/07/13/16:25:15
Christoph Kukulies <kuku AT gilberto DOT physik DOT RWTH-Aachen DOT DE> writes:
> On Tue, Jul 13, 1999 at 02:17:25PM +0200, Christoph Kukulies wrote:
> >
> > I was a bit suprised when I compiled a library (libf2c.a)
> > under B19 (ld -r -x -o , btw, didn't work under that version),
> > took the library to a B20.1 (resp. latest) machine and
> > linked a program for which the main program was compiled
> > under the latter.
> >
> > The result was that the program got hung and didn't write out
> > anything. It was a hello world type program. I could interrupt
> > with ^C though.
> >
> > Is it normal, that .o files or .a files are incompatible between releaes?
>
> Thinking of it I came to the conclusion that the problem might be in
> differing stdio.h structures (iob or what that is). f2c's runtime
> library that I was compiling (libf2c) relies heavily on these
> stdio structures and they may have changed from b19 to b20.
>
> Can anyone confirm this?
This issue has come up a few times; Cygwin team does strive for
binary compatibility, but it hasn't said much in terms of link
level compatibility.
Here's my take on this -- Cygwin is *beta* software, and you have to
expect a level of incompatibility from release to release. It has
done very well in terms of *binary* compatibility, but compatibility
at the *link-level*, ie., being able to link object files together
from different releases, is sometimes simply not possible.
Just consider what happens when Cygwin release R+1 fixes a bug in
some globally visible symbol in release R. You've just lost link
level compatibility. Can it be prevented or worked around? Possibly.
But IMO that's not worth the mess that's likely to show up in the
long run. Let's fix it now while it's still called beta.
Regards,
Mumit
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -