lam-mpi version 7.0.4 (marked as stable) works fine. However, after upgrading it a newer to version 7.0.6 (also marked as stable) programs can no longer link with the flags -llam and -lmpi due to undefined references to 'pthread_create' etc. Below is a full list of messages from make: (...) -I/usr/include/mysql -I/usr/local/include -L ./ -lANN -lQuantLib -lm -lmysqlclient -L/home/chris/Projects/gccImageLib-0.0.3/lib -limage -lmpi -llam /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../liblam.so: undefined reference to `pthread_create' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../liblam.so: undefined reference to `sem_destroy' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../liblam.so: undefined reference to `sem_wait' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../liblam.so: undefined reference to `sem_post' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../liblam.so: undefined reference to `openpty' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../liblam.so: undefined reference to `sem_init' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../liblam.so: undefined reference to `sem_trywait' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../liblam.so: undefined reference to `pthread_mutex_trylock' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../liblam.so: undefined reference to `pthread_join' collect2: ld returned 1 exit status make: *** [correlation3] Error 1 Unmerging lam-mpi 7.0.6 and emerging lam-mpi 7.0.4 (downgrading it) fixes the problem. The newer version 7.0.6 that has been marked as stable does not seem to behave as a stable ebuild. Reproducible: Always Steps to Reproduce: 1.emerge lam-mpi 7.0.6 2.attempt to compile a C/C++ program linking to -llam and -lmpi Actual Results: Received undefined references from the linker: -I/usr/include/mysql -I/usr/local/include -L ./ -lANN -lQuantLib -lm -lmysqlclient -L/home/chris/Projects/gccImageLib-0.0.3/lib -limage -lmpi -llam /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../liblam.so: undefined reference to `pthread_create' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../liblam.so: undefined reference to `sem_destroy' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../liblam.so: undefined reference to `sem_wait' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../liblam.so: undefined reference to `sem_post' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../liblam.so: undefined reference to `openpty' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../liblam.so: undefined reference to `sem_init' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../liblam.so: undefined reference to `sem_trywait' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../liblam.so: undefined reference to `pthread_mutex_trylock' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../liblam.so: undefined reference to `pthread_join' collect2: ld returned 1 exit status make: *** [correlation3] Error 1 Expected Results: It should have compiled the program without any errors/problems. Using a lower version of lam-mpi 7.0.4 instead of 7.0.6 works without any problems/error messages. There is no separate mpich library installed on my system. The only mpi library is the joint lam-mpi package. Being unable to compile programs with the version 7.0.6 means a major feature (compilation) is broken. A temporary solution is to downgrade a package to a previous stable version 7.0.4.
Probably an NPTL issue. emerge info, please? We might need to add a USE flag for nptl -- I think there's a configure option.
Emerge info: Portage 2.0.50-r11 (default-x86-2004.2, gcc-3.3.4, glibc-2.3.3.20040420-r1, 2.6.8-gentoo-r3) ================================================================= System uname: 2.6.8-gentoo-r3 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz Gentoo Base System version 1.4.16 distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -mcpu=pentium4 -march=pentium4 -fomit-frame-pointer -mfpmath=sse -ffast-math -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -mcpu=pentium4 -march=pentium4 -fomit-frame-pointer -mfpmath=sse -ffast-math -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://mirror.nutsmaas.nl/gentoo/ http://gd.tuwien.ac.at/opsys/linux/gentoo/ http://gentoo.tiscali.nl/gentoo/" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X alsa apm arts avi berkdb bitmap-fonts cdr crypt cups dvd encode esd f77 foomaticdb gdbm gif gnome gpm gtk gtk2 imlib java jpeg kde libg++ libwww madmikmod motif mozilla mpeg mysql ncurses nls oggvorbis opengl oss pam pdflib perl png ppds python qt quicktime readline sdl slang spell ssl svga tcpd tetex truetype x86 xml2 xmms xprint xv zlib"
Further to the original issue/bug posting. Although using lam-mpi 7.0.4 allows you to compile and link with -lmpi and -llam libraries, running mpi-enabled programs results in the same linking errors with undefined "sem_destroy" etc. So whilst the version 7.0.6 bombs out during compilation, the 7.0.4 allows you to compile only to "bomb out" during the actual execution. I am running a stable x86 2.6.8 kernel system without any NPTL support. The system was bootstrapped using a bootstrap.sh script as in the Gentoo installation handbook, not the bootstrap-2.6.sh script. I read on the internet (after googling) that support for NPTL wasn't stable enough yet in a stable x86 Gentoo tree. In the end I ended up unmerging lam-mpi and installing mpich instead. With mpich the mpi-enabled programs both compile and as well as execute without any problems.
Which version of linux-headers?
Below is the answer: emerge -s linux-headers Searching... [ Results for search key : linux-headers ] [ Applications found : 1 ] * sys-kernel/linux-headers Latest version available: 2.4.21-r1 Latest version installed: 2.4.21-r1 Size of downloaded files: 27,864 kB Do you think it would be worth trying to add a flag "nptl" to make.conf, then do " emerge -C linux-headers", "emerge -C gentoo-dev-sources", "emerge linux26-headers" and ""USE="nptl" emerge glibc" + reboot? Would one need to recompile the kernel as well with the nptl flag? Is this a safe procedure to do on an already-installed and stable system?
I found the real reason behind problems with threads in lam-mpi (and not mpich). It was to do with me not using the mpiCC wrapper to compile lam-enabled programs. I have always used a gcc compiler with added lam-mpi libraries to link against. The problems with the more recent lam-mpi versions (7.0.4 and 7.0.6) is that a few extra libraries had to be added when calling gcc: "-llam -lmpi -pthread -llammpio-llammpi++ -lutil" The "-pthread" solved the threading errors and the others solved some subsequent linking problems. In the end there was no need to enable NPTL support. But in any case I have added the NPTL support to one of my three Gentoo Linux systems following the instructions from "http://gentoo-wiki.com/HOWTO_Gentoo_2004.2_for_linux_2.6_and_NPTL" (section "Getting NPTL to work on already-running systems") and no anomalies were observed so far with native POSIX threads. So I guess this issue can be closed. It was no so much a bug as simply me not keeping up with the changes to linking libraries introduced in newer lam-mpi versions.
Ahh, OK. Thanks for checking this out.
I'm formally changing the status from "Resolved Fixed" to "Closed". Thanks for your involvement!