> * install-sh not found > > To resolve the install-sh problem, I've added --srcdir to the configure > options, that way the path to the install-sh script is an absolute path. > [...]
That's a good workaround which doesn't hurt on any platform, so I've taken over this. > * compile error: > > cc: Error: /tmp/openpkg/RPM/TMP/gcc-3.4-20040414/libiberty/floatformat.c, > line 319: In this statement, the libraries on this platform do not yet > support compile-time evaluation of the constant expression "0.0/0.0". > (constfoldns) > dto = NAN; > --------------^ > make[1]: *** [floatformat.o] Error 1 > make: *** [all-libiberty] Error 2 > > The Compaq C compiler needs the option -ieee to compile this source. So the > spec checks if the cc command is /bin/cc and sets l_libcflags to -ieee if it > is. (note: the cc command is also present in /usr/bin/cc, so maybe this > needs checking too?!) Hmmm... I'm now using -ieee always on Tru64 because the check for a particular "cc" will always be too weak and it shouldn't really hurt if we always use -ieee on Tru64. I especially wanted to reduce the .spec file hacking for Tru64 to an absolute minimum (see below). > * with_binutils > > GNU as/ld aren't supported on Tru64. Therefor skip the --with-gnu-ld/as / > -pipe options even if with_binutils=yes is set. Well, as the chief architect of OpenPKG I'm forced to reject this, because Tru64 is currently no officially supported platform in OpenPKG and the amount of changes necessary to the gcc.spec just for this platform problem is not in balance to the amount of the platform importance. Especially, because building the "gcc" package with an explicit "with_binutils=no" solves the problem on Tru64 equally well, right? It is just that under this particular platform one has to remember to set this option. But we have a similar situation already for "with_optimize=no" which is required on some platforms, too. So, please be not disappointed by this, but a package has to build out-of-the-box only on officially supported platforms. If we can get it building on not supported platforms with a less intrusive patch, I'm fully fine with this (see the --srcdir and --ieee patches). But if we take over more intrusive patches for not supported platforms, we end up too easily with horrible .spec files although the primary and supported platforms do not require this at all. So, please understand that this GNU binutils problem for Tru64 I would like to see solved by a platform specific FAQ entry about Tru64 or some other approach. > Side note: gcc34 supports a profiledbootstrap. Has this been tried yet?! I've added now an additional option "with_profile" which provides support for this target. But it works only if you already have GCC installed. See http://cvs.openpkg.org/chngview?cn=16055 for details. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ______________________________________________________________________ The OpenPKG Project www.openpkg.org Developer Communication List [EMAIL PROTECTED]
