Portage 2.1.7.13 (default/linux/x86/10.0, gcc-4.4.2-asneeded, glibc-2.11-r1, 2.6.32 i686) ================================================================= System uname: Linux-2.6.32-i686-Quad-Core_AMD_Opteron-tm-_Processor_2350-with-gentoo-2.0.1 Timestamp of tree: Fri, 11 Dec 2009 00:00:01 +0000 distcc 3.1 i686-pc-linux-gnu [disabled] ccache version 2.4 [enabled] app-shells/bash: 4.0_p35 dev-java/java-config: 1.3.7-r1, 2.1.10 dev-lang/python: 2.6.4, 3.1.1-r1 dev-python/pycrypto: 2.0.1-r8 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.8.0 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.5.3 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.4_p6-r1, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.3, 1.11.1 sys-devel/binutils: 2.20 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="*" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/openfire/resources/security/ /opt/openjms/config /usr/lib/ccs/conf /usr/share/X11/xkb /usr/share/bufrtables /usr/share/config /usr/share/qpsmtpd/plugins /var/bind /var/lib/hsqldb /var/phxd /var/qmail/alias /var/qmail/control /var/spool/torque /var/vpopmail/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -pipe" DISTDIR="/var/cache/distfiles" FEATURES="assume-digests ccache distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms split-log strict test test-fail-continue unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="http://ftp.uni-erlangen.de/pub/mirrors/gentoo" INSTALL_MASK=" /usr/share/doc /usr/share/info" LANG="en_US.utf8" LDFLAGS="-Wl,-O1" MAKEOPTS="-j14" PKGDIR="/var/spool/portage/packages" PORTAGE_COMPRESS="" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/cache/portage/tree-tinderbox" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl berkdb bzip2 cli cracklib crypt cups cxx dri fortran gdbm gpm iconv ipv6 java5 java6 modules mudflap ncurses nls nostatic nptl nptlonly openmp pam pcre perl pppd python qt3support readline reflection ruby session spl ssl sysfs tcpd unicode x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias auth_digest" ELIBC="glibc" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" RUBY_TARGETS="ruby18" USERLAND="GNU" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, LC_ALL, LINGUAS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Diego, could you attach the build log of this failure?
Created attachment 212913 [details] Build log Sorry I was called on the phone so it lagged behind :(
No problem. I did not notice how recent the bug was (6 minutes between filing and my comment - oops), so I thought perhaps you had been interrupted and forgot to come back. The build failed because, at least as orsa builds it, /usr/include/mpicxx.h requires -fexceptions, but orsa built with -fno-exceptions. Since the emerge --info does not show -fno-exceptions in CXXFLAGS, I assume this was added by orsa itself. Diego, what package provides /usr/include/mpicxx.h for you? I checked sys-cluster/openmpi-1.4, which has an mpicxx.h, but line 183 is the middle of a batch of forward declarations, so I clearly have the wrong version of that header.
Right in this moment it's sys-cluster/mpich2 but I cannot be sure if that was the same provider when the tinderbox reached orsa.
sys-cluster/mpich2-1.2.1 appears to provide an mpicxx.h with a function of the correct name on the correct line. Deeper investigation shows this may be some sort of configuration/build system bug. The ebuild for orsa 0.7.0 specifies "mpi? ( sys-cluster/openmpi )". The ebuild for openmpi forbids having mpich2 installed, both via a RDEPEND blocker, and implicitly via the file collision that both provide mpicxx.h, and the one from openmpi is not the one you used. Thus, orsa must have been built with USE=-mpi (and inspection of the build log confirms --without-mpi was used), but tried to use MPI functionality anyway. Indeed, the configure summary printed after the tests states: * MPI.....: yes Investigation of the configure script (macros/acx_mpi.m4, cached in aclocal.m4) reveals that this is the standard AC_ARG_WITH mistake in Autotools: treating argument #3 as the "--with-FOO" case, rather than as ACTION-IF-GIVEN. Since the ebuild specifies a decision, the configure script assumes MPI is wanted, without looking at the decision itself. It then enables MPI without regard to the value of $USE.
I agree that this package needs some work. My build log also selects MPI: yes even though I'm only on a Pentium IV (single CPU/core) and even though my USE flags are "-mpi". There are a number of problems in the configure process detecting the presence or lack thereof of sci-libs/cln (which is installed) and sci-libs (also installed) with errors of the form: ./configure: line 9095: /no/such/file/bin/gsl-config: No such file or directory But the configure process does manage to get through those. The build killer on my system is: ccache i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./misc -I./.. -DQT_THREAD_SUPPORT -D_REENTRANT -g -Wall -W -pipe -ftemplate-depth-64 -O3 -fno-exceptions -funroll-loops -fstrict-aliasing -fno-gcse -c orsa_secure_math.cc -MT orsa_secure_math.lo -MD -MP -MF .deps/orsa_secure_math.TPlo -fPIC -DPIC orsa_secure_math.cc: In function 'double orsa::secure_pow(double, double)': orsa_secure_math.cc:44: error: 'sprintf' was not declared in this scope and 6 similar errors. That is clearly a case of a missing include for stdio. I checked the source file and I don't see an include for stdio (but I don't really understand C++ include processes so I'm not sure if there is something else going on. This is a rebuild of a previously compiled build on my system: sci-astronomy/orsa-0.6.1 USE="opengl -cln -fftw -ginac -gsl -mpi (-qt3%)" I think the rebuild is taking place because I'm in the process of switching over from qt3 to qt4, though I did recently upgrade to linux-headers-2.6.32.
Created attachment 220425 [details] My emerge --info System information.
Created attachment 220427 [details] My build.log Log showing the various errors.
(In reply to comment #6) > My build log also selects MPI: yes even though I'm only on a Pentium IV (single > CPU/core) and even though my USE flags are "-mpi". Yes. The upstream configure script has a bug which causes this, irrespective of your system hardware. > There are a number of problems in the configure process detecting the presence > or lack thereof of sci-libs/cln (which is installed) and sci-libs (also > installed) with errors of the form: > ./configure: line 9095: /no/such/file/bin/gsl-config: No such file or directory You have not set USE=cln or USE=gsl, so by default the ebuild tries to build without those features. However, the Gentoo maintainer chose a rather strange way of preventing use of these packages. Rather than passing an appropriate --without-cln, the ebuild instead passes --with-cln-prefix=/no/such/file. This may have been because the upstream configure does not properly understand --without-cln, and the maintainer did not wish to fix it. > That is clearly a case of a missing include for stdio. I checked the source > file and I don't see an include for stdio (but I don't really understand C++ > include processes so I'm not sure if there is something else going on. This may be the result of using new gcc/glibc. System headers include less than they once did, so some packages now fail to compile because they wrongly relied on system headers including what the package code needed. C++ include processing is very similar to C include processing, so if you are comfortable reading C code, you can apply that knowledge to the includes here. > This is a rebuild of a previously compiled build on my system: > sci-astronomy/orsa-0.6.1 USE="opengl -cln -fftw -ginac -gsl -mpi (-qt3%)" You probably built it back when you had system packages that were more tolerant of upstream mistakes. The package could use a fair amount of maintenance. If you are not comfortable developing a patched ebuild to address the issues, post back and I will see what I can do. Note that I am not a Gentoo developer, so you would need to place my proposed fixes in an overlay in order to use them immediately.
There are 13 files that need some minor work (mostly header file additions). However in src/liborsa/orsa_file.cc, there is a code segment: Vector LocationFile::ObsPos(const string obscode, const Date &date) { std::list<std::string>::iterator it_find = find(codes.begin(),codes.end(),obscode); if (it_find == codes.end()) { char err_msg[1024]; sprintf(err_msg,"ERROR: obscode %s not found in file %s",obscode.c_str(),GetFileName().c_str()); ORSA_ERROR_MACRO(err_msg); Vector obspos; return obspos; } which is throwing the error: error: no matching function for call to 'find(std::_List_iterator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::_List_iterator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, const std::string&)' which it isn't clear to me how to fix. Adding "#include <string>" doesn't do it and I can't seem to find a "find" function anywhere else. Also a reference on how to build a diff listing / patch file for the old vs. new sources would be useful. I've looked at the SourceForge project for this and they don't appear to have changed in several years so it would currently appear to be "unsupported".
Created attachment 229019 [details, diff] Patch to add the required <algorithm> include to src/liborsa/orsa_file.cc The find in the cited code snippet appears to be std::find, which is declared by including <algorithm>. Adding a "#include <algorithm>" should fix it. Unless you work with C++ and STL regularly, I would not expect you to know that. :) Since this is a C++ template function, its definition is included in the STL headers shipped with gcc, rather than placed somewhere under /usr/include, as would be the case for C library functions. See </usr/lib/gcc/$CHOST-pc-linux-gnu/$COMPILER_VERSION/include/g++-v4/bits/stl_algo.h> if you want to read the definition. The code seems to be using namespace std, but qualifying some names anyway. This does not affect the generated code, but does make it less consistent to read. For generating diffs, the easiest approach would be to prepare two copies of the source side by side. I often place them in directories named a and b, similar to the git diff output style. Then, run "diff -r -u -N a b". I have attached a sample patch that adds the header I believe to be necessary. However, without compiling orsa, I cannot confirm that this fixes the compilation problems you are seeing.
orsa gone from the tree.
