tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
recent x changes, solaris compiler-options-with-spaces,
(Recently wiz@ updated many xorg things, and several people are having
issues. Apparently there is some discussion on pkgsrc-changes@, but I
think these issues are important enough to warrant tech-pkg@ discussion
- my view is that pkgsrc-changes-d is really for minor followups about
non-controversial not-particularly-important things.)
Thmoas wrote:
On Mon, Jun 04, 2012 at 11:23:50AM +0200, Jörn Clausen wrote:
> What's the status of this problem? I get the same error
>
> checking if cc -std=gnu99 supports -Werror=implicit... no
> checking if cc -std=gnu99 supports -errwarn=E_NO_EXPLICIT_TYPE_GIVEN
> -errwarn=E_NO_IMPLICIT_DECL_ALLOWED... eval: 1: Syntax error: Bad
> substitution
>
> when compiling x11/libICE, and I expect similar problems on the other
> X11 packages that were recently updated. This is NetBSD 5.1.
It's a check for a Solaris compiler option which has spaces inside
(and thus in the shellscript variables) and causes problems in the
shell, due to a bug (AFAIWT).
So first, we should understand what's going on, and if this really is a
shell bug.
I realize we have stable branches, but I think pkgsrc head should have a
goal of trying to be working, where a notion of working necessarily
implies a set of OS/version/arch. I'd argue that currently the single
most important target is the netbsd-5 branch for amd64 and i386, and
that we should consider the notion that massive updates should be tested
on one of those. I say massive, because for many other changes, they
can be backed out quickly and easily, but the recent X changes are hard
to do that for, and backing them out is not really a reasonable thing to
do. I am considering netbsd-5 more important than current because -5
systems tend to be used in situations requiring stability. Again, I
know we have quarterly branches, but a desire for stability is a
continuum.
Speaking as an old-school unix user, it seems bizarre of Solaris to have
compiler options with spaces in them; no one who actually writes code
and uses command-line tools would do that. But when reading configure
(in libfontenc), it seems the problem is that two distinct error options
are tested at the same time, rather than separately. This seems
irregular in and of itself. It seems the point is to replace
-Werror=implicit with two -errwarn invocations, but I don't see why the
configure code can't simply try to enable each error flag separately,
and use the ones that are ok.
Do we already have an easy mechanism to require a different sh for
running configure? My view is that the 5.1 sh failing is a clue that
the configure code is too hairy (even if the 5.1 sh is found to be
buggy).
The actual issue is:
+ eval ${xorg_cv_cc_flag__errwarn_E_NO_EXPLICIT_TYPE_GIVEN
_errwarn_E_NO_IMPLICIT_DECL_ALLOWED+:} false
eval: 1: Syntax error: Bad substitution
Is it really legitimate to expect
eval \${a b}
to evaluate the value of a variable with name "a b"?
Home |
Main Index |
Thread Index |
Old Index