This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Do not report build errors in bugzilla
- From: prj at po dot cwru dot edu (Paul Jarc)
- To: Roland McGrath <roland at redhat dot com>
- Cc: GNU libc devel <libc-alpha at sources dot redhat dot com>
- Date: Tue, 17 Aug 2004 16:35:32 -0400
- Subject: Re: Do not report build errors in bugzilla
- Organization: What did you have in mind? A short, blunt, human pyramid?
- References: <200408171951.i7HJpTbD009432@magilla.sf.frob.com>
Roland McGrath <roland@redhat.com> wrote:
> Would you like to figure out what the exact requirements are and
> help us document them?
I don't have time to coordinate that effort, but I can contribute data
points as I find them.
> However, if you fix it yourself and send us clean patches that make
> glibc's build work with any POSIX.2-compliant sh, we will certainly
> put those in.
SUSv3 doesn't specify -e or -E for echo, and csu/Makefile uses -e, so
it's already less portable than intended, I guess. Here's a slightly
different patch for my case that uses -e instead of -E, though, so at
least it won't reduce portability any further; I'm testing it now:
* csu/Makefile: Use "echo -e" whenever we care how backslash
is handled.
Index: csu/Makefile
===================================================================
RCS file: /cvs/glibc/libc/csu/Makefile,v
retrieving revision 1.73
diff -u -r1.73 Makefile
--- csu/Makefile 8 Mar 2004 21:28:15 -0000 1.73
+++ csu/Makefile 17 Aug 2004 20:14:06 -0000
@@ -231,13 +231,13 @@
if [ -z "$$os" ]; then \
os=Linux; \
fi; \
- echo "\"Compiled on a $$os $$version system" \
- "on `date +%Y-%m-%d`.\\n\"" ;; \
+ echo -e "\"Compiled on a $$os $$version system" \
+ "on `date +%Y-%m-%d`.\\\\n\"" ;; \
*) ;; \
esac; \
files="$(all-Banner-files)"; \
if test -n "$$files"; then \
- echo "\"Available extensions:\\n\""; \
+ echo -e "\"Available extensions:\\\\n\""; \
sed -e '/^#/d' -e 's/^[[:space:]]*/ /' \
-e 's/^\(.*\)$$/\"\1\\n\"/' $$files; \
fi) > $@T
>> There's also the __i686 macro defined by gcc
...
> In fact, I don't know what you are talking about.
Passing -march=i686 makes gcc implicitly define __i686 to 1, but some
of glibc's assembly code uses __i686 without expecting it to be a
macro. I think this is the least disruptive change to handle it:
http://sources.redhat.com/ml/libc-alpha/2002-10/msg00157.html
More threads:
http://sources.redhat.com/ml/libc-alpha/2003-05/msg00125.html
http://sources.redhat.com/ml/libc-alpha/2003-01/msg00119.html
paul