Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Building ohNet for Mac OS X
26-03-2012, 10:56 AM
Post: #11
RE: Building ohNet for Mac OS X
(25-03-2012 09:28 PM)simoncn Wrote:  I've been doing a bit more web searching to find another solution. On Mac OS X, the normal extension for shared libraries is .dylib, although .so is also allowed. Mac OS X Java accepts .dylib as an alternative to .jnilib for JNI libraries. So if libohNet.so and libohNetJni.so are renamed to libohNet.dylib and libohNetJni.dylib, the test cases work with no need to change the .java files. The change from .so to .dylib also has the advantage of conforming to standard Mac OS X naming conventions.

Thanks. I've committed the change to name shared objects as .dylib.

I wonder whether we could get away with 'dealing' with the install_name issue now by ignoring it?
Find all posts by this user
26-03-2012, 12:32 PM
Post: #12
RE: Building ohNet for Mac OS X
(26-03-2012 10:56 AM)simonc Wrote:  Thanks. I've committed the change to name shared objects as .dylib.

I wonder whether we could get away with 'dealing' with the install_name issue now by ignoring it?

Thanks for doing this.

Unfortunately I don't think it's possible to ignore the install_name issue. This is because the current build actually does put an install_name into libOhNet.dylib, and this name that's in there is unsuitable for any purpose other than running the test cases.

To explain further:

The current Makefile builds libohNet.dylib without an install_name, which means that the linker gives it a default install_name of Build/Obj/Mac/Release/libohNet.dylib (the path specified on the link command). This install_name works when running test cases from the ohnet directory (because libohNet.dylib happens to be at this exact relative path from the ohnet directory), but it doesn't work for any application executable or other shared library that wants to use libohNet.dylib.

To cater for this situation, the Mac OS X linker provides the -install_name linker option. which specifies either an abolute path where the shared library must always be installed, or a relative path that uses one of three special prefixes.

The absolute path form is appropriate for shared libraries that are always installed in a fixed position on the Mac OS X file system. This doesn't apply to libOhNet.dylib, because this is intended to be packaged with an application. To cover this case, the -install_name option allows specifying a relative path based on one of the following special prefixes:

@executable_path
This is is the folder containing the currently running executable. This is intended for shared libraries that are always called by an executable and never called by another shared library. For example, if shared library C.dylib is called by executables A and B, the linker command for C.dylib could specify -install_name @executable_path/C.dylib, and copies of C.dylib would be placed in the same directories as both A and B.

@loader_path
This is is the folder containing the object that's calling the shared library. This object can be either an executable or another shared library. This is equivalent to @executable_path for shared libraries that are called by executables, but it also supports the case of shared libraries that are called by another shared library. For example, if shared library C.dylib is called by executable A and shared library B, the linker command for C.dylib could specify -install_name @loader_path/C.dylib, and copies of C.dylib would be placed in the same directories as both A and B.

@rpath
This provides more flexibility because it allows the calling application or shared library to control the load path explicitly. The disadvantage is that this requires the application to be linked with special options. For example, if shared library C.dylib is called by executable A and shared library B, the linker command for C.dylib could specify -install_name @rpath/C.dylib. This requires both A and B to be linked with the -rpath option specifying a value that the linker will substitute at runtime for @rpath when it searches for C.dylib.

A fuller description can be found in this article.

I think the best choice for the install_name in libohNet.dylib is @loader_path/libohNet.dylib. This means that the linker will load libohNet.dylib when it's in the same directory as any calling application or other shared library. Ths works for the test cases (both non-Java and Java), because libOhNet.dylib, libohNetJni.dylib and the test case executables are in the same build directory. It also works for any ohNet Java application that packages libOhNetJni.dylib and libohNet.dylib in the same directory, and it works for any ohNet non-Java application that packages libohNet.dylib in the same directory as its executable and/or shared libraries. Finally, unlike @rpath, it doesn't need the application to specify any special linker options.

I hope this was useful!
Find all posts by this user
26-03-2012, 03:22 PM
Post: #13
RE: Building ohNet for Mac OS X
Thanks, that was very informative Smile. I'll add install_name in tomorrow.
Find all posts by this user
26-03-2012, 04:30 PM
Post: #14
RE: Building ohNet for Mac OS X
(26-03-2012 03:22 PM)simonc Wrote:  Thanks, that was very informative Smile. I'll add install_name in tomorrow.

Thanks very much!
Find all posts by this user
28-03-2012, 04:18 PM
Post: #15
RE: Building ohNet for Mac OS X
(26-03-2012 04:30 PM)simoncn Wrote:  
(26-03-2012 03:22 PM)simonc Wrote:  Thanks, that was very informative Smile. I'll add install_name in tomorrow.

Thanks very much!

I've been watching the commits, but I haven't seen one for this yet. I'd like to pull down a new version to pick up this change as well as chrisc's JavaScript example (and one or two other interesting recent commits). Smile Please can you post an update here when this change is available on GitHub. Thanks!
Find all posts by this user
29-03-2012, 04:23 PM
Post: #16
RE: Building ohNet for Mac OS X
(28-03-2012 04:18 PM)simoncn Wrote:  I've been watching the commits, but I haven't seen one for this yet. I'd like to pull down a new version to pick up this change as well as chrisc's JavaScript example (and one or two other interesting recent commits). Smile Please can you post an update here when this change is available on GitHub. Thanks!

The changes should all be on github now
Find all posts by this user
30-03-2012, 08:31 PM
Post: #17
RE: Building ohNet for Mac OS X
(29-03-2012 04:23 PM)simonc Wrote:  The changes should all be on github now

Thanks! I've built this new version on Mac OS X. Everything's fine except for the usual problem with include T4Linux.mak. A uset4 option would be very nice! Smile

Thanks also for adding the code to detect adapter changes (disable/enable) on Mac OS X. It's working well when I sleep and resume my Mac.
Find all posts by this user
02-04-2012, 10:30 AM
Post: #18
RE: Building ohNet for Mac OS X
(30-03-2012 08:31 PM)simoncn Wrote:  Thanks! I've built this new version on Mac OS X. Everything's fine except for the usual problem with include T4Linux.mak. A uset4 option would be very nice! Smile

Thanks for the reminder. I've changed this locally so it should be available on github this evening.
Find all posts by this user


Forum Jump: