Re: Problems with linking older libraries

Re: Problems with linking older libraries

[N8TM]

In a message dated 5/7/99 7:14:57 AM Pacific Daylight Time, hjl@lucon.org 
writes:

> RedHat 6.0 has a modified egcs 1.1.2 which provides the binary
>  compatibility. The good news is the similar patch is in the current
>  egcs.
Binary compatibility how far back?  Would the NAG f95, supporting 
gcc-2.7.2.1, be working better with egcs now?
Tim
tprince@computer.org

Re: Problems with linking older libraries

[N8TM]

In a message dated 5/7/99 7:14:57 AM Pacific Daylight Time, hjl@lucon.org 
writes:

> RedHat 6.0 has a modified egcs 1.1.2 which provides the binary
>  compatibility. The good news is the similar patch is in the current
>  egcs.
Binary compatibility how far back?  Would the NAG f95, supporting 
gcc-2.7.2.1, be working better with egcs now?
Tim
tprince@computer.org

Problems with linking older libraries

[Peter Bender]

Hello,

My Problem:
If just ported some parts of my application for compiling
with egcs 1.1.2 under SUN Solaris 2.5/2.6. This works fine 
for all until now, but not for the GUI which is realized with 
wxWindows. The wxwin libraries are compiled (long time ago) 
with SUN CC.
The source does compile cleanly but in the link stage  there
are *really* many unresolved externals which seems to be all 
related with wxwin-functions.

Is it possible for egcs to link against these old libraries
or do I have to recompile wxWindows?
If yes what else could be wrong?

Many thanks in advance
best regards
Peter
   ________         
  /    /   /\ Peter Bender                   .++,..         .__q"\ /\
 /  __/---/\/ email: pbender@gmx.de        ~~+^v^v^v~~~~~+~ ^>__,'/->
/__/_____/\/  www:   www.iib.bauing.tu-darmstadt.de/~bender    _/ \_>
\__\_____\/                                                   _(._):_.

Re: Problems with linking older libraries

[alex.buell]

On Thu, 6 May 1999, Peter Bender wrote:

> Is it possible for egcs to link against these old libraries or do I
> have to recompile wxWindows? If yes what else could be wrong?

egcs-1.1.2 has changed the ABI interfaces, so yes, you definitely will
have to recompile wxWindows - it's a good idea anyway as egcs-1.1.2
generates better optimised binaries.

Cheers,
Alex
--
"A mind opened by new ideas cannot return to its original limits"

http://www.tahallah.demon.co.uk

Re: Problems with linking older libraries

[Patrick K.]

Sometime in the late 1900s it was said:

> On Thu, 6 May 1999, Peter Bender wrote:
> 
Bender> Is it possible for egcs to link against these old libraries or do I
Bender> have to recompile wxWindows? If yes what else could be wrong?

Alex> egcs-1.1.2 has changed the ABI interfaces, so yes, you definitely will
Alex> have to recompile wxWindows - it's a good idea anyway as egcs-1.1.2
Alex> generates better optimised binaries.


Is there a good reason/logic behind breaking binary compatibility
from version to version?

Seems like this is cuasing extra work and problems:

   1. One would have to recompile ALL libraries needed for the
      application.  This obviously wastes many hours/minutes (more?)
      assuming one can find sources for older libraries needed,
      or even if one has access to such source code.

   2. Basically this seem like limiting developers to using either:

      a. "home-grown" libraries.
      b. GPL'ed or open-source libraries.
      c. or switch to perl (or other script lang) for development  :-)

Is this wise or desirable?

I am sure the reason for this is not simple.  But is there a way
one could minimize this type of binary compatibility problems?
Is there no answer to this?


Just a curious user,

patrick@boxsoft.com
sidster@drink.com

Re: Problems with linking older libraries

[Alex Buell]

On Thu, 6 May 1999, Patrick K. wrote:

> Is there a good reason/logic behind breaking binary compatibility
> from version to version?

There was a very good reason for this breaking in 1.1.2, but I forget what
it was, but I gather it was to do with glibc-2.1/glibc-2.0 problems. 
 
> I am sure the reason for this is not simple.  But is there a way one
> could minimize this type of binary compatibility problems? Is there no
> answer to this?

You could try recompiling egcs-1.1.2 with the new ABI turned off, I think
there is a way to do that, but I am not immediately sure. Perhaps one of
the more experienced members on this mailing list can jump in and help
out?

Cheers, 
Alex 
-- 
"A mind opened by new ideas can never return to its original limits"

http://www.tahallah.demon.co.uk

Re: Problems with linking older libraries

[Alex Buell]

On Thu, 6 May 1999, Patrick K. wrote:

> Is there a good reason/logic behind breaking binary compatibility
> from version to version?

There was a very good reason for this breaking in 1.1.2, but I forget what
it was, but I gather it was to do with glibc-2.1/glibc-2.0 problems. 
 
> I am sure the reason for this is not simple.  But is there a way one
> could minimize this type of binary compatibility problems? Is there no
> answer to this?

You could try recompiling egcs-1.1.2 with the new ABI turned off, I think
there is a way to do that, but I am not immediately sure. Perhaps one of
the more experienced members on this mailing list can jump in and help
out?

Cheers, 
Alex 
-- 
"A mind opened by new ideas can never return to its original limits"

http://www.tahallah.demon.co.uk

Re: Problems with linking older libraries

[Martin v. Loewis]

> Is there a good reason/logic behind breaking binary compatibility
> from version to version?

You don't seem to have much trust into people doing compiler
development. Do you think they break binary compatibility just for the
fun of it?

There are always good reasons for breaking it. Typically, a serious
bug can be only fixed by breaking the ABI. In case of egcs 1.1,
exception handling was not thread-safe in 1.0. In case of egcs 1.2,
the standard template library shipped with egcs 1.1 did not comply
with the standard.

Another reason is that the code might be more efficient if the binary
compatibility can be broken. egcs already contains a number of such
changes, which are not activated yet because they break binary
compatibility.

Regards,
Martin

Re: Problems with linking older libraries

[patrick]

Hello,


Sometime in the late 1900s it was said:

   sid> Is there a good reason/logic behind breaking binary compatibility
   sid> from version to version?

Martin> You don't seem to have much trust into people doing compiler
Martin> development. Do you think they break binary compatibility just for the
Martin> fun of it?

Martin> There are always good reasons for breaking it. Typically, a serious
Martin> bug can be only fixed by breaking the ABI. In case of egcs 1.1,
Martin> exception handling was not thread-safe in 1.0. In case of egcs 1.2,
Martin> the standard template library shipped with egcs 1.1 did not comply
Martin> with the standard.


You know, I understand what you are trying to say.  But as a developer
even though I do see what you mean, at the same time I am trying to point
out my perspective of this problem.

In a way you are saying (almost to the point of forcing) that every
piece of code going into the development of an application *must* be
compiled by a certain compiler.  This means I no longer have a choice
of picking and choosing available 3rd party libraries to include in
an application I am involved in developing (I am talking about non-
open source libraries here).

I think everyone would agree that it would be quite unreasonable for
a small company to call Oracle up and tell them that they must provide
egcs-{insert version here} compiled libraries of their software
since the company's developers can't link their application with
the provided C libraries for Oracle, which seem to be compiled by a
different compiler or even a different version of the egcs compiler.

This type of a situation leaves one no choice but to be bound by the
compiler the 3rd party vendor used to develop their products.

Please do *not* get me wrong.  I totally appreciate what individual
professionals like yourself are doing with egcs' development.  I
am certain everyone knows the great benefits we derive from a very
capable and freely available compiler for our systems.  However, I
am wondering if situations like I described above should not be
given more consideration?

I work for (well used to work for) a major US bank.  Fortunately
we were big enough to be able to use our "weight" to get our vendor
to consider using gcc to work around a problem we were running into
with their library, which later was determined to be mis-information
in their library documentation -- pointed out after weeks of fruitless
finger-pointing to compilers and ego-belittling.

But I doubt we would have similar impact on a bigger vendor like
Oracle, for example.

Consider this:  These binary-compatibility breaks seem to introduce
a new factor in development/deployment targets.  Not only do we have
to consider architecture and operating systems (as before) we now
must consider the compiler as well.  This seems quite skrange to me.

But please please, do not under-estimate my greatfulness for egcs
and its developers!



Best regards,


patrick@boxsoft.com
sidster@drink.com

Re: Problems with linking older libraries

[Martin v. Loewis]

> This type of a situation leaves one no choice but to be bound by the
> compiler the 3rd party vendor used to develop their products.

Yes. This may be unfortunate, but you have discovered one of the key
problems of current C++. For C, there are well-defined ABI standards,
that change rarely. For C++, there aren't.

Please note that this is not specific to egcs. Any available compiler
breaks binary compatibility from version to version, at least once the
standard library comes into play.

> However, I am wondering if situations like I described above should
> not be given more consideration?

Sure they should. But the solution is not a technical, it is on the
level of project management. Since chances are low of compatibility
between versions (let alone between different compilers), you have to
standardize on a single one.

For example, when RedHat shipped 5.0, they included egcs 1.0 as the
C++ compiler. When 5.3 (I believe) came out, 1.1 was available and 1.0
had a lot of limitations. Still, RedHat continues to include egcs 1.0,
because of binary compatibility. Therefore, this version is the
current de-facto standard on Linux. Anybody offering binary-only
libraries for Linux is likely to offer 1.0-compiled libraries. Anybody
using precompiled libraries has to get her code working with 1.0, even
if that means to make compromises in terms of readability of the code,
efficiency, and thread-safety.

I hope that RedHat will adopt 1.2 when it comes out, and then
sooner-or-later drop 1.0.

> Consider this:  These binary-compatibility breaks seem to introduce
> a new factor in development/deployment targets.  Not only do we have
> to consider architecture and operating systems (as before) we now
> must consider the compiler as well.

Yes. If the pain eventually gets strong enough, perhaps users sit down
and define C++ ABI specifications, telling compiler vendors that this
is the ABI a compiler must use, or they won't use the compiler.

My guess is that this won't happen. Users will find this much to
difficult to define, cluttered with patents all over the
place. Compiler vendors hope that the ABI breakage will stop sooner or
later, once their compilers provide all features that are required by
the C++ standard.

> But please please, do not under-estimate my greatfulness for egcs
> and its developers!

I don't take it as an offense. I just try to tell you that everybody
knows and considers the problem, but that it likely will remain a
user's problem for a couple more years.

Some people conclude that they better write C when they want to sell
libraries.

Regards,
Martin

Re: Problems with linking older libraries

[Andi Kleen]

In muc.lists.egcs.misc, you wrote:
>For example, when RedHat shipped 5.0, they included egcs 1.0 as the
>C++ compiler. When 5.3 (I believe) came out, 1.1 was available and 1.0
>had a lot of limitations. Still, RedHat continues to include egcs 1.0,
>because of binary compatibility. Therefore, this version is the
>current de-facto standard on Linux. Anybody offering binary-only
>libraries for Linux is likely to offer 1.0-compiled libraries. Anybody
>using precompiled libraries has to get her code working with 1.0, even
>if that means to make compromises in terms of readability of the code,
>efficiency, and thread-safety.
>
>I hope that RedHat will adopt 1.2 when it comes out, and then
>sooner-or-later drop 1.0.

They already did, RH 6.0 does not include egcs-1.0, it only includes 1.1.
I don't know how they handled the binary compatibility issues (i guess 
they didn't) 

-Andi

Re: Problems with linking older libraries

[H.J. Lu]

> 
> In muc.lists.egcs.misc, you wrote:
> >For example, when RedHat shipped 5.0, they included egcs 1.0 as the
> >C++ compiler. When 5.3 (I believe) came out, 1.1 was available and 1.0
> >had a lot of limitations. Still, RedHat continues to include egcs 1.0,
> >because of binary compatibility. Therefore, this version is the
> >current de-facto standard on Linux. Anybody offering binary-only
> >libraries for Linux is likely to offer 1.0-compiled libraries. Anybody
> >using precompiled libraries has to get her code working with 1.0, even
> >if that means to make compromises in terms of readability of the code,
> >efficiency, and thread-safety.
> >
> >I hope that RedHat will adopt 1.2 when it comes out, and then
> >sooner-or-later drop 1.0.
> 
> They already did, RH 6.0 does not include egcs-1.0, it only includes 1.1.
> I don't know how they handled the binary compatibility issues (i guess 
> they didn't) 
> 

RedHat 6.0 has a modified egcs 1.1.2 which provides the binary
compatibility. The good news is the similar patch is in the current
egcs.


-- 
H.J. Lu (hjl@gnu.org)

Re: Problems with linking older libraries

[H.J. Lu]

> 
> In muc.lists.egcs.misc, you wrote:
> >For example, when RedHat shipped 5.0, they included egcs 1.0 as the
> >C++ compiler. When 5.3 (I believe) came out, 1.1 was available and 1.0
> >had a lot of limitations. Still, RedHat continues to include egcs 1.0,
> >because of binary compatibility. Therefore, this version is the
> >current de-facto standard on Linux. Anybody offering binary-only
> >libraries for Linux is likely to offer 1.0-compiled libraries. Anybody
> >using precompiled libraries has to get her code working with 1.0, even
> >if that means to make compromises in terms of readability of the code,
> >efficiency, and thread-safety.
> >
> >I hope that RedHat will adopt 1.2 when it comes out, and then
> >sooner-or-later drop 1.0.
> 
> They already did, RH 6.0 does not include egcs-1.0, it only includes 1.1.
> I don't know how they handled the binary compatibility issues (i guess 
> they didn't) 
> 

RedHat 6.0 has a modified egcs 1.1.2 which provides the binary
compatibility. The good news is the similar patch is in the current
egcs.


-- 
H.J. Lu (hjl@gnu.org)

Re: Problems with linking older libraries

[Andi Kleen]

In muc.lists.egcs.misc, you wrote:
>For example, when RedHat shipped 5.0, they included egcs 1.0 as the
>C++ compiler. When 5.3 (I believe) came out, 1.1 was available and 1.0
>had a lot of limitations. Still, RedHat continues to include egcs 1.0,
>because of binary compatibility. Therefore, this version is the
>current de-facto standard on Linux. Anybody offering binary-only
>libraries for Linux is likely to offer 1.0-compiled libraries. Anybody
>using precompiled libraries has to get her code working with 1.0, even
>if that means to make compromises in terms of readability of the code,
>efficiency, and thread-safety.
>
>I hope that RedHat will adopt 1.2 when it comes out, and then
>sooner-or-later drop 1.0.

They already did, RH 6.0 does not include egcs-1.0, it only includes 1.1.
I don't know how they handled the binary compatibility issues (i guess 
they didn't) 

-Andi

Re: Problems with linking older libraries

[Martin v. Loewis]

> This type of a situation leaves one no choice but to be bound by the
> compiler the 3rd party vendor used to develop their products.

Yes. This may be unfortunate, but you have discovered one of the key
problems of current C++. For C, there are well-defined ABI standards,
that change rarely. For C++, there aren't.

Please note that this is not specific to egcs. Any available compiler
breaks binary compatibility from version to version, at least once the
standard library comes into play.

> However, I am wondering if situations like I described above should
> not be given more consideration?

Sure they should. But the solution is not a technical, it is on the
level of project management. Since chances are low of compatibility
between versions (let alone between different compilers), you have to
standardize on a single one.

For example, when RedHat shipped 5.0, they included egcs 1.0 as the
C++ compiler. When 5.3 (I believe) came out, 1.1 was available and 1.0
had a lot of limitations. Still, RedHat continues to include egcs 1.0,
because of binary compatibility. Therefore, this version is the
current de-facto standard on Linux. Anybody offering binary-only
libraries for Linux is likely to offer 1.0-compiled libraries. Anybody
using precompiled libraries has to get her code working with 1.0, even
if that means to make compromises in terms of readability of the code,
efficiency, and thread-safety.

I hope that RedHat will adopt 1.2 when it comes out, and then
sooner-or-later drop 1.0.

> Consider this:  These binary-compatibility breaks seem to introduce
> a new factor in development/deployment targets.  Not only do we have
> to consider architecture and operating systems (as before) we now
> must consider the compiler as well.

Yes. If the pain eventually gets strong enough, perhaps users sit down
and define C++ ABI specifications, telling compiler vendors that this
is the ABI a compiler must use, or they won't use the compiler.

My guess is that this won't happen. Users will find this much to
difficult to define, cluttered with patents all over the
place. Compiler vendors hope that the ABI breakage will stop sooner or
later, once their compilers provide all features that are required by
the C++ standard.

> But please please, do not under-estimate my greatfulness for egcs
> and its developers!

I don't take it as an offense. I just try to tell you that everybody
knows and considers the problem, but that it likely will remain a
user's problem for a couple more years.

Some people conclude that they better write C when they want to sell
libraries.

Regards,
Martin

Re: Problems with linking older libraries

[patrick]

Hello,


Sometime in the late 1900s it was said:

   sid> Is there a good reason/logic behind breaking binary compatibility
   sid> from version to version?

Martin> You don't seem to have much trust into people doing compiler
Martin> development. Do you think they break binary compatibility just for the
Martin> fun of it?

Martin> There are always good reasons for breaking it. Typically, a serious
Martin> bug can be only fixed by breaking the ABI. In case of egcs 1.1,
Martin> exception handling was not thread-safe in 1.0. In case of egcs 1.2,
Martin> the standard template library shipped with egcs 1.1 did not comply
Martin> with the standard.


You know, I understand what you are trying to say.  But as a developer
even though I do see what you mean, at the same time I am trying to point
out my perspective of this problem.

In a way you are saying (almost to the point of forcing) that every
piece of code going into the development of an application *must* be
compiled by a certain compiler.  This means I no longer have a choice
of picking and choosing available 3rd party libraries to include in
an application I am involved in developing (I am talking about non-
open source libraries here).

I think everyone would agree that it would be quite unreasonable for
a small company to call Oracle up and tell them that they must provide
egcs-{insert version here} compiled libraries of their software
since the company's developers can't link their application with
the provided C libraries for Oracle, which seem to be compiled by a
different compiler or even a different version of the egcs compiler.

This type of a situation leaves one no choice but to be bound by the
compiler the 3rd party vendor used to develop their products.

Please do *not* get me wrong.  I totally appreciate what individual
professionals like yourself are doing with egcs' development.  I
am certain everyone knows the great benefits we derive from a very
capable and freely available compiler for our systems.  However, I
am wondering if situations like I described above should not be
given more consideration?

I work for (well used to work for) a major US bank.  Fortunately
we were big enough to be able to use our "weight" to get our vendor
to consider using gcc to work around a problem we were running into
with their library, which later was determined to be mis-information
in their library documentation -- pointed out after weeks of fruitless
finger-pointing to compilers and ego-belittling.

But I doubt we would have similar impact on a bigger vendor like
Oracle, for example.

Consider this:  These binary-compatibility breaks seem to introduce
a new factor in development/deployment targets.  Not only do we have
to consider architecture and operating systems (as before) we now
must consider the compiler as well.  This seems quite skrange to me.

But please please, do not under-estimate my greatfulness for egcs
and its developers!



Best regards,


patrick@boxsoft.com
sidster@drink.com

Re: Problems with linking older libraries

[Martin v. Loewis]

> Is there a good reason/logic behind breaking binary compatibility
> from version to version?

You don't seem to have much trust into people doing compiler
development. Do you think they break binary compatibility just for the
fun of it?

There are always good reasons for breaking it. Typically, a serious
bug can be only fixed by breaking the ABI. In case of egcs 1.1,
exception handling was not thread-safe in 1.0. In case of egcs 1.2,
the standard template library shipped with egcs 1.1 did not comply
with the standard.

Another reason is that the code might be more efficient if the binary
compatibility can be broken. egcs already contains a number of such
changes, which are not activated yet because they break binary
compatibility.

Regards,
Martin

Re: Problems with linking older libraries

[Patrick K.]

Sometime in the late 1900s it was said:

> On Thu, 6 May 1999, Peter Bender wrote:
> 
Bender> Is it possible for egcs to link against these old libraries or do I
Bender> have to recompile wxWindows? If yes what else could be wrong?

Alex> egcs-1.1.2 has changed the ABI interfaces, so yes, you definitely will
Alex> have to recompile wxWindows - it's a good idea anyway as egcs-1.1.2
Alex> generates better optimised binaries.


Is there a good reason/logic behind breaking binary compatibility
from version to version?

Seems like this is cuasing extra work and problems:

   1. One would have to recompile ALL libraries needed for the
      application.  This obviously wastes many hours/minutes (more?)
      assuming one can find sources for older libraries needed,
      or even if one has access to such source code.

   2. Basically this seem like limiting developers to using either:

      a. "home-grown" libraries.
      b. GPL'ed or open-source libraries.
      c. or switch to perl (or other script lang) for development  :-)

Is this wise or desirable?

I am sure the reason for this is not simple.  But is there a way
one could minimize this type of binary compatibility problems?
Is there no answer to this?


Just a curious user,

patrick@boxsoft.com
sidster@drink.com

Re: Problems with linking older libraries

[alex.buell]

On Thu, 6 May 1999, Peter Bender wrote:

> Is it possible for egcs to link against these old libraries or do I
> have to recompile wxWindows? If yes what else could be wrong?

egcs-1.1.2 has changed the ABI interfaces, so yes, you definitely will
have to recompile wxWindows - it's a good idea anyway as egcs-1.1.2
generates better optimised binaries.

Cheers,
Alex
--
"A mind opened by new ideas cannot return to its original limits"

http://www.tahallah.demon.co.uk

Problems with linking older libraries

[Peter Bender]

Hello,

My Problem:
If just ported some parts of my application for compiling
with egcs 1.1.2 under SUN Solaris 2.5/2.6. This works fine 
for all until now, but not for the GUI which is realized with 
wxWindows. The wxwin libraries are compiled (long time ago) 
with SUN CC.
The source does compile cleanly but in the link stage  there
are *really* many unresolved externals which seems to be all 
related with wxwin-functions.

Is it possible for egcs to link against these old libraries
or do I have to recompile wxWindows?
If yes what else could be wrong?

Many thanks in advance
best regards
Peter
   ________         
  /    /   /\ Peter Bender                   .++,..         .__q"\ /\
 /  __/---/\/ email: pbender@gmx.de        ~~+^v^v^v~~~~~+~ ^>__,'/->
/__/_____/\/  www:   www.iib.bauing.tu-darmstadt.de/~bender    _/ \_>
\__\_____\/                                                   _(._):_.