> > * 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).
It can be a problem if gcc is already installed, as gcc doesn't understand the -ieee parameter and thus the build will fail in that case. I noticed that you put a check for gcc in the .spec file (in the with_profile part). Can this also be used on the -ieee flag!? > > * 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. No problem.. I agree that it was a bit messy.. Just had an idea.. would it be acceptable for the openpkg bootstrap package to create a default ~/.openpkg/build (or suggest one) in which platform specific defines are done?! In that case, the openpkg bootstrap could suggest a build file with '-Dgcc::with_binutils=no' in it for the tru64 platform. The problem with this 'with_binutils' is, that the build fails very late in the compile, and the error message isn't at all clear as to why it fails... but then.. users should read the FAQ anyway.. so I can live with it :-) Karl. ______________________________________________________________________ The OpenPKG Project www.openpkg.org Developer Communication List [EMAIL PROTECTED]
