[Pkg-openmpi-maintainers] [Fwd: Bug#657625: FTBFS openmpi 1.5 (experimental) on armel]

[Jeffrey Squyres]

On Feb 27, 2012, at 10:38 AM, Sylvestre Ledru wrote:

>> What's your timeline for wheezy?
> We are going to freeze in June. 
> We would need about a month to perform the transition. Maybe less if you
> haven't changed the ABI between 1.4 and 1.5.

ABI definitely changed between 1.4 and 1.5 -- it's constant for 1.5 and 1.6 (that's our release methodology).  FWIW, it's going to change between 1.5/1.6 and 1.7/1.8, too.

> Do you have an idea when 1.6 is going to be released ?

We're rolling another 1.5.5 rc right now; I should have 1.5.5rc3 out by the end of today if all goes well.  1.6 will be "soon" after that (we're actually just looking for an excuse to launch 1.6, so we queued up a bunch of minor bug fixes after 1.5.5 has shown now to be a disaster, so ... "soon").

>>> /bin/sh ../../../libtool --tag=CC   --mode=link gcc  -DNDEBUG -Wall -g
>>> -O2 -finline-functions -fno-strict-aliasing -pthread -fvisibility=hidden
>>> -export-dynamic   -o orte-checkpoint
>>> orte-checkpoint.o ../../../orte/libopen-rte.la -lnsl -lutil  -lm 
>>> libtool: link: gcc -DNDEBUG -Wall -g -O2 -finline-functions
>>> -fno-strict-aliasing -pthread -fvisibility=hidden
>>> -o .libs/orte-checkpoint orte-checkpoint.o
>>> -Wl,--export-dynamic  ../../../orte/.libs/libopen-rte.so -lnsl -lutil
>>> -lm -pthread -Wl,-rpath -Wl,/usr/lib/openmpi/lib
>>> /usr/bin/ld: orte-checkpoint.o: undefined reference to symbol
>>> 'opal_class_initialize'
>>> /usr/bin/ld: note: 'opal_class_initialize' is defined in
>>> DSO /home/sylvestre/dev/debian/openmpi/branches/openmpi-1.4.5/build/shared/opal/.libs/libopen-pal.so.0 so try adding it to the linker command line
>>> /home/sylvestre/dev/debian/openmpi/branches/openmpi-1.4.5/build/shared/opal/.libs/libopen-pal.so.0: could not read symbols: Invalid operation
>>> 
>>> with
>>> ../../configure --build i486-linux-gnu --with-ft=cr --with-blcr=/usr
>>> --with-blcr-libdir=/usr/lib --with-libnuma=/usr
>>> --with-libnuma-libdir=/usr/lib --with-devel-headers
>>> --enable-heterogeneous --with-tm
>> 
>> That doesn't sound familiar.  I can't imagine how libopen-pal.so.0 could have unreadable symbols.  Is your build arch different than your host arch?  This might not be something we have tested well.
> no, purely 32 bits.


Can you send the full build info?  

-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/