This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: building every released version of GCC starting with 4.1.2, with appropriate matching glibc


On 07/04/17 00:54, Jonathan Wakely wrote:
> On 6 April 2017 at 23:26, Toebs Douglass wrote:

>> Now, I may be wrong, but it seems to me when a new GCC is being
>> released, it will be compiled for sure with the most recently published
>> glibc, libmpfr, libgmp and libmpc.  Similarly, it will be created with
>> the most recently release binutils.
> 
> No, not necessarily.
> 
> When GCC is released it's compiled by users, and so will use whatever
> glibc a user has on their machine.

I may be wrong, but I think generally people using a distro will use and
only use the compiler and glibc which came with the distro.

It is unusual for a person using a distro to compile a new GCC or glibc.

It seems to me then in practise GCC and glibc versions in the field will
bear a strong correspondence, although I do understand from what you
have said it is not actually *fixed*; it might for example be a distro
update ships a new GCC, but keeps the original glibc.

>> However, the benchmark app also benchmarks normal locking data
>> structures, as provided by the OS.  For Linux, all the usual suspects.
>> I assume - but I do not *actually* know, now I think about it to answer
>> the question - that these will depend, directly or indirectly, upon glibc.
> 
> But I see no reason they would depend on the glibc version.

I may also be wrong here too, but I think the pthreads source code is
part of glibc.  I am thinking the pthreads code will change over glibc
releases, and it is the pthread code which contains the OS provided
locking mechanisms - mutexes, rwlocks, etc.

The benchmark app also benchmarks normal locking data structures.

The lock-free benchmarks are interesting, but they only really make
sense when you can compare them to the alternatives.  For that
comparison to be fair, I should use the GCC and glibc in use by the user.

Perhaps I in fact need to build every GCC against every version of
glibc, so to have benchmarks for every possible combination.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]