This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Testing 2.16 release candidate with gnulib
- From: Carlos O'Donell <carlos_odonell at mentor dot com>
- To: Bruno Haible <bruno at clisp dot org>
- Cc: <libc-alpha at sourceware dot org>
- Date: Sat, 30 Jun 2012 11:12:16 -0400
- Subject: Re: Testing 2.16 release candidate with gnulib
- References: <4FEBDA04.6010709@mentor.com> <2058186.PDnk2TcgS3@linuix> <4FEDC3FB.6050501@mentor.com> <70599729.sUypURCOaS@linuix>
On 6/29/2012 6:33 PM, Bruno Haible wrote:
> [Carlos sent me the configuration results of testing a gnulib testdir
> with a glibc 2.16 release candidate on x86_64.]
Bruno,
Unfortunately I made a mistake in the last configure I did.
In my hurry to send you the files I failed to set one of the environment
variables that pointed to the sysroot and thus the build used the *native*
environment instead of the 2.16 release-candidate build.
As Joseph correctly surmised that set of configure checks were run against
the native environment and not 2.16.
I've reconfigured gnulib, carefully following your instructions *and*
verifying the output is sensible and matches the results I achieved during
the first test run.
These object files are built by gnulib:
dprintf.o
fclose.o
fcntl.o
fflush.o
fprintf.o
fseek.o
fseeko.o
futimens.o
glob.o
ioctl.o
isfinite.o
linkat.o
log10f.o
logf.o
nanosleep.o
printf.o
remove.o
snprintf.o
sprintf.o
strerror_r.o
strstr.o
utimensat.o
vdprintf.o
vfprintf.o
vprintf.o
vsnprintf.o
vsprintf.o
Only these were new regressions:
log10f.o
logf.o
remove.o
strstr.o
We've identified strstr.o as a glibc issue.
We've identified remove.o as a gnulib issue.
We had not yet tracked down log10f.o or logf.o.
Hopefully with my new and correctly configured logs you can
determine the cause of the problem.
Again, I apologize for wasting your time and Joseph's time.
Cheers,
Carlos.
--
Carlos O'Donell
Mentor Graphics / CodeSourcery
carlos_odonell@mentor.com
carlos@codesourcery.com
+1 (613) 963 1026