Broken build on OS X

[shamisp]

Error:

checking for ANSI C header files... (cached) yes
checking for pkg-config... /opt/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for shm_open in -lrt... no
configure: error: librt not found

librt is not supported on OS X. Do we really need/use it ?

[yosefe]

yes, it's needed for SystemV shared memory
we can change this to conditionally compile out systemV support instead of failing configure.

[shamisp]

@uccs/ucx-dev
Get the code running on OS X involves much more work that I anticipated. There are plenty of linux specific/non-posix codec. I made some progress here https://github.com/shamisp/ucx/tree/osx_fixes I wanna get more OS X users/experts involved. Right now I'm trying to figure out what to do with debug.[ch] and log.[ch] that relays on pthreads and ELF specific code. I think there is no particular reason to make it linux specific. The lock calls we have to wrap with ucs_* calls. I'm not sure what to do with debug.[ch].

[tonycurtis]

On Oct 30, 2014, at 3:35 PM, Pasha <notifications@github.mirror.nvdadr.commailto:notifications@github.com> wrote:

@uccs/ucx-devhttps://github.com/orgs/uccs/teams/ucx-dev
Get the code running on OS X involves much more work that I anticipated. There are plenty of linux specific/non-posix codec. I made some progress here https://github.com/shamisp/ucx/tree/osx_fixes I wanna get more OS X users/experts involved. Right now I'm trying to figure out what to do with debug.[ch] and log.[ch] that relays on pthreads and ELF specific code. I think there is no particular reason to make it linux specific. The lock calls we have to wrap with ucs_* calls. I'm not sure what to do with debug.[ch].

So is the OS X pthread issue the lack of spin_[un]lock calls? At least on my Mac (Yosemite, Xcode 6.1). Could we use a mutex instead?

For the ELF, same issue in the openshmem code. Currently hard-coded for ELF, but we could dream up a small API to present the required info about the executable’s memory layout etc.

tony

[tonycurtis]

On Oct 30, 2014, at 3:35 PM, Pasha <notifications@github.mirror.nvdadr.commailto:notifications@github.com> wrote:

@uccs/ucx-devhttps://github.com/orgs/uccs/teams/ucx-dev
Get the code running on OS X involves much more work that I anticipated. There are plenty of linux specific/non-posix codec. I made some progress here https://github.com/shamisp/ucx/tree/osx_fixes I wanna get more OS X users/experts involved. Right now I'm trying to figure out what to do with debug.[ch] and log.[ch] that relays on pthreads and ELF specific code. I think there is no particular reason to make it linux specific. The lock calls we have to wrap with ucs_* calls. I'm not sure what to do with debug.[ch].

Some code to get the executable name for OS X…

#include <libproc.h>
#include <unistd.h>

const char *
ucs_get_exe (void)
{
#ifdef APPLE
int ret;
static char pathbuf[PROC_PIDPATHINFO_MAXSIZE];
pid_t pid = getpid();

ret = proc_pidpath (pid, pathbuf, sizeof(pathbuf));

return (ret > 0) ? pathbuf : NULL;
#endif /* APPLE */
}

[tonycurtis]

On Oct 30, 2014, at 5:06 PM, Curtis, Tony <arcurtis@Central.UH.EDUmailto:arcurtis@Central.UH.EDU> wrote:

On Oct 30, 2014, at 3:35 PM, Pasha <notifications@github.mirror.nvdadr.commailto:notifications@github.com> wrote:

@uccs/ucx-devhttps://github.com/orgs/uccs/teams/ucx-dev
Get the code running on OS X involves much more work that I anticipated. There are plenty of linux specific/non-posix codec. I made some progress here https://github.com/shamisp/ucx/tree/osx_fixes I wanna get more OS X users/experts involved. Right now I'm trying to figure out what to do with debug.[ch] and log.[ch] that relays on pthreads and ELF specific code. I think there is no particular reason to make it linux specific. The lock calls we have to wrap with ucs_* calls. I'm not sure what to do with debug.[ch].

Some code to get the executable name for OS X…
...

Implicit was an offer to fold it into sys.c with suitable #ifdef guards and do a PReq.

tony

[shamisp]

Pthreads - this part of code we should be able to change to mutex, since it is not critical path (i hope so). The debug part that lookups addresses in libraries is a one that concerns me.

[tonycurtis]

On Oct 30, 2014, at 8:46 PM, Pasha <notifications@github.mirror.nvdadr.commailto:notifications@github.com> wrote:

Pthreads - this part of code we should be able to change to mutex, since it is not critical path (i hope so). The debug part that lookups addresses in libraries is a one that concerns me.

the wikipedia article for Mach-O says

"Some versions of NetBSDhttp://en.wikipedia.org/wiki/NetBSD have had Mach-O support added as part of an implementation of binary compatibility”

I’ll go and browse that, it may give some hints about the things we need to do…

tony

[shamisp]

Actually the problem is not in elf but all these dl_* (example: dl_match_address) functions from link.h
OS X does not have this API at all.

[bosilca]

dladdr seems to provide a somewhat similar functionality as indicated @
https://developer.apple.com/library/mac/Documentation/DeveloperTools/Reference/MachOReference/index.html#//apple_ref/doc/uid/TP40001398-CH1g-315644
.

George.

On Thu, Oct 30, 2014 at 11:00 PM, Pasha notifications@github.com wrote:

Actually the problem is not in elf but all these dl_* (example:
dl_match_address) functions from link.h
OS X does not have this API at all.

—
Reply to this email directly or view it on GitHub
#9 (comment).

[shamisp]

@bosilca - thanks ! I think it will do the job !

[shamisp]

Seems like pthread_spin_lock I would have to wrap with
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/spinlock.3.html

@yosefe there are a lot of pthread_spin calls. Shell we wrap it with ucs_thead_lock/unlock/init to make it more convenient ?

[tonycurtis]

On Oct 30, 2014, at 10:31 PM, Pasha <notifications@github.mirror.nvdadr.commailto:notifications@github.com> wrote:

Seems like pthread_spin_lock I would have to wrap with
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/spinlock.3.html

@yosefehttps://github.com/yosefe there are a lot of pthread_spin calls. Shell we wrap it with ucs_thead_lock/unlock/init to make it more convenient ?

Well, it’s possible that e.g. qthreads or massivethreads could be a drop-in replacement so an abstraction might be useful. Hide the threading implementation in a ucs/ subdirectory.

tony

[shamisp]

@yosefe There is already some wrapper for debug purpose under: src/ucs/type/spinlock.h.
I think we just may extend the wrapper to support OS X.

[yosefe]

@shamisp We could definitely wrap the spinlock as you suggest. There are places we can't settle for a mutex. The wrappers in spinlock.h are for "recursive spinlock" and we can extend that.
Regarding debug, we could disable the whole "detailed backtrace" thing for MAC, see HAVE_DETAILED_BACKTRACE. it will fall back to printing plain addresses.

[shamisp]

spinlock - we will wrap it around with ucs_*

HAVE_DETAILED_BACKTRACE - in my build it is disabled.
There are still debug functions (I guess for attaching debugger?) that relay on sone functionality in the file:
dl_match_address, dl_lookup_address, ucs_debugger_attach,ucs_handle_error and plenty of others.
Some of these functions are linux specific. George proposed a solution for one of the problems, but I'm sure there are more issues to fix.

[devreal]

Just ran into this. Any chance UCX will ever support OS X?

[yosefe]

@devreal currently it doesn't seem there is enough interest to push this. of course, if anyone is willing to invest in this, the contribution will be welcome :)