On 2005-10-02, at 23:45, Paolo Bonzini wrote:
2) Why do you think that symbol versioning is exclusive to glibc?
I don't. I look at the the results of it.
3) You can of course think that glibc is evil, but how is it related?
Oh no... I got just immersed by the GLIBCXX prefixing over there and
guessed that it's related to the glibc instead of the GNU-libstdc++
name. Argh.
4) Who in their right minds would add glibc-specific code naming it
ENABLE_SYMVERS_DARWIN_EXPORT (*darwin*)?
Same answer as to 3).
I'm right now not in the mood to dive myself in to the non-
formal, fragile, how to waste time chasing broken by design
system, world of autoconf/automake.
5) Can you suggest any better alternative? We are all ears.
FreeBSD at least manages much of an paralell build system. A
declarative system, which doesn't rely that much on host system
testing would be helpfull and much easier to handle. I'm quite
convinced that it would require right now far less effort to maintain
then what is spend overall on the autoxxxx stuff.
6) Is this whining reporting significant information, for the
person that wants to fix the bug?
Well on the system in question ppc-apple-darwin-7.8.0 the perl script
in question simply doesn't work. Since there doesn't appear to be
much in the way of it inside acinclude.m4 it appears that setting
unconditionally enable_symvers inside the following:
# Turn a 'yes' into a suitable default.
if test x$enable_symvers = xyes ; then
if test $enable_shared = no ||
test "x$LD" = x ; then
enable_symvers=no
elif test $with_gnu_ld == yes ; then
enable_symvers=gnu
else
case ${target_os} in
darwin*)
enable_symvers=darwin-export ;;
*)
AC_MSG_WARN([=== You have requested some kind of symbol
versioning, but])
AC_MSG_WARN([=== you are not using a supported linker.])
AC_MSG_WARN([=== Symbol versioning will be disabled.])
enable_symvers=no ;;
esac
fi
fi
seems to be not quite right.
