This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.0 Release Criteria
>>>>> "Chip" == Chip Salzenberg <chip@valinux.com> writes:
Chip> According to Joerg Faschingbauer:
>> >>>>> "Chip" == Chip Salzenberg <chip@valinux.com> writes:
Chip> If by "serious" you mean "targeting unknown systems",
Chip> then you probably want to link with static libc also, yes?
>>
>> - First, usually every system - even unknown - has a libc installed
>> somewhere around (which tries to be bincompatible as far as possible
>> - but read on). This is not generally the case with libstdc++ [...]
Chip> Not at present. But if you read the critera for gcc 3.0, especially
Chip> the work that's been done on the "new ABI" for C++, I suspect you'll
Chip> find that the groundwork is being laid for a libstdc++ that is just as
Chip> universal as libc6.
>> - Second, from what I heard - correct me if I'm wrong - you must build
>> libstdc++ with the same compiler you use to build your program with.
Chip> I'd say that's a good rule of thumb today. But, again, the "new ABI"
Chip> work seems likely to make compiler independence achievable.
What I wanted to express in my original mail is that it is simply a
bit early to risk all the problems involved - hesitating sometimes
pays. (H.J. Lu pointed out a few possible problems yesterday.)
>> - Third (no joke), because of an incompatibility (I assume in libio)
>> introduced somewhere between glibc 2.0.6 and 2.1.<dunno>, the
>> programs linked statically against the libstdc++.a (which was built
>> against glibc 2.0.6) failed running on a 2.1.<dunno> system. Of
>> course, employing libstdc++.so would have solved this, but
>> unfortunately there's the second point above. Solution: link libc
>> static. (Mad laughter here!)
Chip> If I were in your shoes, I'd include an appropriate libstdc++.so in an
Chip> application-specific library directory. That would solve two problems
Chip> at once.
Maybe, but not mine.
Joerg