[MPICH] ch3:sctp configure broken

[Brad Penoff]

hey Steve,

I learned what I think you're problem is...

I had seen in the config.log that you sent me that it couldn't find your 
libsctp.  It used to be that all sctp_XXX() API calls were in a library 
called libsctp for all platforms;  this is still the case for most OS's.

In recent FreeBSD 7 implementations, I've been told that these API calls 
have snuck into libc itself.  On this end, we had explicitly built libsctp 
previously, we so didn't see the problem building ch3:sctp.  For you 
however, no libsctp will be a problem because unfortunately, the configure 
script in its current state requires libsctp to exist, and sctp_recvmsg to 
be a part of it.

So for now, the suggested solution is to make some ficticious libsctp.a 
somewhere and have it be a soft-link to your libc.a assuming that...
find / -name libc.a | xargs nm | grep sctp_
...returns something.  Pass the location of your libsctp.a soft-link into 
--with-sctp-lib (or just set the location yourself in your LDFLAGS) when 
you run configure.

If...
find / -name libc.a | xargs nm | grep sctp_
...doesn't return anything, then we need to contact the FreeBSD 7 
developers soon (I think the deadline for their final commit is 
approaching soon).

On a semi-related note, can you let me know also if netinet/sctp.h exists 
somewhere within your system's CPPFLAGS?

Thanks,
brad

On Wed, 23 May 2007, Brad Penoff wrote:

> hey Steve,
>
> I've tried to answer below in-line.
>
> brad
>
> On Tue, 22 May 2007, Steve Kargl wrote:
>
>> On Tue, May 22, 2007 at 06:53:16PM -0700, Brad Penoff wrote:
>>> 
>>> I have been running mpich2-1.0.5p4 ch3:sctp on FreeBSD 6.1, 6.2, and 7.0
>>> very recently (EuroPVM/MPI deadline) so I'm surprised it's failing.  I 
>>> had
>>> a few questions about your setup...
>>> 
>>> 1) Just curious, but do you have SCTP-capable kernels?
>> 
>> yes.
>
> So I'm assuming "options SCTP" is in the kernel config?
>
>> 
>>> 2) Which FreeBSD and which kernel are you using?
>> 
>> FreeBSD-7.0 built from source on Friday a few hours
>> before the gcc-4.2 import.  Hardware is 7 nodes
>> that are all Tyan K8SR based amd64 systems.  See
>
> I've sent an email to our FreeBSD colleagues so I'll get back to you on this. 
> Just curious but where exactly do you obtain your source from?
>
>> 
>> http://troutmask.apl.washington.edu/~kargl/hpc.html
>> 
>> I just added node16, so some numbers at the URL don't
>> add up correct.
>> 
>>> 3) Do non-MPI/"normal" SCTP-based applications work?
>> 
>> Haven't tried any other sctp apps.  Do you have a suggestion?
>
> I could give you some but first see #5 below...
>
>> 
>>> 4) What arguments did you supply to configure?
>> 
>> None of the following work
>> 
>> ./configure --with-device=ch3:sctp
>> ./configure --with-device=ch3:sctp --prefix=/usr/local/mpich2
>> ./configure --with-device=ch3:sctp --prefix=/usr/local/mpich2 
>> --enable-fast
>> ./configure --with-device=ch3:sctp --prefix=/usr/local/mpich2 
>> --enable-fast \
>>            --enable-shared
>> ./configure --with-device=ch3:sctp --prefix=/usr/local/mpich2 
>> --enable-fast \
>>            --enable-shared  --enable-static
>> 
>>> 5) Can you send me (off-list) your 
>>> src/mpid/ch3/channels/sctp/config.log?
>> 
>> See follow up email.
>
> I saw your config.log and it can't seem to find libsctp.a or libsctp.so... 
> can you do a find on a your system to see if these exist?  The same can be 
> said about your netinet/sctp.h; these locations need to be pasted into 
> --with-sctp, --with-sctp-lib, and/or --with-sctp-include so that LDFLAGS and 
> CPPFLAGS can be set appropriately (or you can set them yourself).  Or if 
> these files don't exist on your system, we have another problem...
>
>> 
>>> There is some help in the top-level README file; just search for 
>>> ch3:sctp.
>>> There are some stack-specific instructions on how to compile (and if you
>>> followed them already, I don't mean to insult you).
>> 
>> Read it.
>> 
>> BTW, do you use bash?
>
> Generally, yes, and come to think of it, I have when building ch3:sctp almost 
> exclusively.
>
> brad
>
>> 
>> --
>> Steve
>> 
>