Remove deprecated calls

[jsquyres]

Per thread starting here: http://www.open-mpi.org/community/lists/devel/2014/10/16088.php, remove / update the deprecated calls. These warnings were seen in the new OS X release (Yosemite):

sharedfp_sm_file_open.c: In function 'mca_sharedfp_sm_file_open': 
sharedfp_sm_file_open.c:159:5: warning: 'sem_init' is deprecated (declared at /usr/include/sys/semaphore.h:55) [-Wdeprecated-declarations] 
     if(sem_init(&sm_offset_ptr->mutex, 1, 1) != -1){ 
     ^ 
sharedfp_sm_file_open.c: In function 'mca_sharedfp_sm_file_close': 
sharedfp_sm_file_open.c:214:13: warning: 'sem_destroy' is deprecated (declared at /usr/include/sys/semaphore.h:53) [-Wdeprecated-declarations] 
             sem_destroy(&file_data->sm_offset_ptr->mutex); 
             ^ 

@PHHargrove mentions:

sem_init() and sem_destroy() are POSIX-defined interfaces for UNNAMED semaphores. There are also POSX interfaces, sem_{open,close,unlink}(), that operate on NAMED semaphores.
See for more info:
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/semaphore.h.html
According to the following link Mac OSX only implements the NAMED semaphores and I would guess they are now deprecating the ones that just return -1 and set errno=ENOSYS:
http://stackoverflow.com/questions/1413785/sem-init-on-os-x

[PHHargrove]

Unfortunately, systems conforming to an older POSIX revision will have the init/destroy interfaces and not the open/close/unlink ones. So, one likely solution will need #ifdef to chose the right set (though just raising the bar for this component to a circa 2004 rev of POSIX is another option).

[jsquyres]

@edgargabriel Any progress on this, perchance?

[edgargabriel]

yes, the fix is already in the master (and active by default), just the configure logic to decide when to use named vs. unnamed semaphores is not yet in place. Right now it will always be the named semaphores, but the code for unnamed is still there just ifdef'd out.

[jsquyres]

Cool, thanks. Does this fix need to get moved to the v1.8 branch? Or is it already there (or not needed), and we should close this issue?

[edgargabriel]

Since the previous version is not 'buggy', I would not move it to 1.8. I did not close the ticket yet because of the configure logic thing, but we can if you want.

[jsquyres]

Cool. Let's leave it open -- I just changed the milestone from 1.8.5 to 1.9.