This is the mail archive of the 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 6 April 2017 at 23:26, Toebs Douglass wrote:
> On 06/04/17 23:22, Paul Smith wrote:
>> On Thu, 2017-04-06 at 22:58 +0200, Toebs Douglass wrote:
>>> I wish to compile the library, the test application and the benchmark
>>> application on every released version of GCC, starting with version
>>> 4.1.2, using the appropriate glibc.
>> Can you describe what you mean by "the appropriate glibc"?  There's no
>> direct relationship between the versions of glibc and GCC, for the most
>> part.
> I inspected the release archives of gcc, binutils, glibc, libmpfr,
> libgmp and libmpc and ascertained their release dates, either from the
> archive date or in the cases where the archive date was wrong, from the
> files inside the archive.
> 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.

> These versions then I thought would be the "appropriate" versions, for a
> given GCC.
>> It's not clear to me why a suite of lock-free data structures would
>> care about which version of glibc was being used for test; do these
>> implementations depend on glibc functions in some way?
> That is a good question.
> The library itself does not use even a freestanding implementation; it
> compiles on a bare C compiler.
> 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.

It sounds as though you're making your life extremely complicated for
no reason. Just compile GCC and forget about creating custom sysroots
with different glibc and binutils versions.

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