www.phidot.org

Hello all,

I have been trying to get the MARK executable to run on Mac OS Yosemite at my new working place.
I followed the steps outlined on the webpage, and installed the newest versions of XCode and gfortran. Upon trying to call mark from the command line, I kept getting the same error:

dyld: Library not loaded: /usr/local/lib/libquadmath.0.dylib
Referenced from: /Users/chloern/Downloads/mark
Reason: image not found

I checked within gfortran, and the specified library was present, and gfortran was running without a problem for a dummy program.

When I installed and ran my colleague's (older, and likely 32-bit) MARK executable, the error did not appear and I was able to run MARK using the RMark interface with no issues.

It looks like there may be some communication problem between the newer versions of the MARK executable and gfortran. Any ideas what could be causing this, and how it could be solved?

Ganieda wrote:Hello all,

I have been trying to get the MARK executable to run on Mac OS Yosemite at my new working place.
I followed the steps outlined on the webpage, and installed the newest versions of XCode and gfortran. Upon trying to call mark from the command line, I kept getting the same error:

dyld: Library not loaded: /usr/local/lib/libquadmath.0.dylib
Referenced from: /Users/chloern/Downloads/mark
Reason: image not found

I checked within gfortran, and the specified library was present, and gfortran was running without a problem for a dummy program.

When I installed and ran my colleague's (older, and likely 32-bit) MARK executable, the error did not appear and I was able to run MARK using the RMark interface with no issues.

It looks like there may be some communication problem between the newer versions of the MARK executable and gfortran. Any ideas what could be causing this, and how it could be solved?

First, remember that the basic rule for MARK under OS/X is 'if it works for you, great. Otherwise, you're on your own'. MARK is a Windows program that does exactly what its supposed to do on Windows-based machines. I've got it compiled so that it does exactly what it is supposed to do on GNU/Linux based machines.

But, for a lot of technical reasons, getting MARK compiled in 'generic' and 'robust' way is more complicated than it should be. There is also a basic logistical limit -- I don't have an OS/X based machine of recent vintage, and [rant on] Apple is too 'authoritarian' to allow people to *easily* install recent incarnations of OS/X in a virtual machine to develop/support applications under OS/X (please note that Apple is the only major 'computer company' that puts those sorts of limits in place). I suppose I could try to throw Darwin (probably pureDarwin) into a VM, but I haven't had a chance to try that. So, unless someone wants to buy me a Mac laptop or some such, there are limits to what I can do to support things at the moment -- short of the VM solution which is probably the only practical path forward. Of course, you could go get yourself a machine running Windows or GNU/Linux, but that's the more Draconian solution. [/rant off]

Having said that, the simple form of the technical challenge is that MARK is compiled with dynamic libraries (on a Windows machine, these are the familiar .DLL files). This means that for MARK to run properly, it needs to dynamically load various libraries at runtime. To do this, it looks in 'standard locations' for various things (libraries). If it finds them, it works. If it doesn't, it throws errors of the 'can't find xyz library' variety.

Now, one solution is to blog all the libraries together 'statically' so that they're bundled into the MARK executable. The executable is larger, but is less dependent on the vagaries of where the operating system 'hides' various libraries that MARK needs. Unfortunately, haven't been able to figure out how to successfully get MARK to compile statically, regardless of platform/OS. It's on my to-do list.

In the meantime, you put on your 'techie hat' (the Mac-approved one be only available via iTunes), and start trying to figure out out what libraries MARK is looking for. In a terminal window, in the (sub)directory where you've stashed the MARK executable, you can LDD the executable to find out what it 'requires', then tweak the LD_LIBRARY_PATH as needed. I *think* OS/X using the same basic LD path conventions as Linux, but can't be positive.

You might also do some Google searches on the error your report -- the following search result might be informative: https://github.com/JuliaLang/julia/issues/389

From what I've read, there may be multiple versions of various libraries on your Mac, and MARK may simply be finding the 'wrong one'. See for example https://stackoverflow.com/questions/175 ... ies-on-osx

cooch wrote:Now, one solution is to blog all the libraries together 'statically' so that they're bundled into the MARK executable. The executable is larger, but is less dependent on the vagaries of where the operating system 'hides' various libraries that MARK needs. Unfortunately, haven't been able to figure out how to successfully get MARK to compile statically, regardless of platform/OS. It's on my to-do list.

I *may* have solved the static compilation issue, at least on GNU/Linux machines -- still need to do a fair number of tests to confirm that beyond the statically-linked MARK executable 'running' (a key first step), that it is, in fact, returning the same results as the dynamically linked version.

In principle, the same approach should work under OS/X (but basic lack of access to an OS/X-based machine that I can 'futz' with limits anything further there).

cooch wrote:

cooch wrote:Now, one solution is to blog all the libraries together 'statically' so that they're bundled into the MARK executable. The executable is larger, but is less dependent on the vagaries of where the operating system 'hides' various libraries that MARK needs. Unfortunately, haven't been able to figure out how to successfully get MARK to compile statically, regardless of platform/OS. It's on my to-do list.

I *may* have solved the static compilation issue, at least on GNU/Linux machines -- still need to do a fair number of tests to confirm that beyond the statically-linked MARK executable 'running' (a key first step), that it is, in fact, returning the same results as the dynamically linked version.

In principle, the same approach should work under OS/X (but basic lack of access to an OS/X-based machine that I can 'futz' with limits anything further there).

Looks like the static compilation works. The executable is bigger, but (i) it is 'standalone', and runs on machines even without gfortran installed, and (ii) it is somewhat faster than the dynamically linked executable (which in hindsight makes some sense -- MARK doesn't need to spend time going out and finding, and then loading, needed library functions from the host machine -- they're built-in).

So, for the moment, I'm going to throw both the dynamically-linked and statically-linked executable *for Linux* into a common tarball that is downloadable off the website. The Linux user can then decide which of the two to use (simply be renaming one or the other as needed, and making sure RMark knows which want to point at).

As for the OS/X folks, that will need to wait until I can lay my hands on a Mac of recent vintage, and convince the owner of said machine to allow me to install gfortran and other tools, MARK source, and do the compilation. Stay tuned....might happen once the students start flooding back to campus. I can always use 'grading leverage' (you wanna pas this class?) to get access to their machines. Or something like that...

cooch wrote:In principle, the same approach should work under OS/X (but basic lack of access to an OS/X-based machine that I can 'futz' with limits anything further there).

OK, managed to lay my hands on a very new Mac -- installed all the dev tools (Xcode, gcc, gfortran and all that), loaded up the MARK source, and compiled a dynamically linked version with no problems.

However, when I tried to compile a statically linked version (as per discussions earlier in this thread), crashed and burned. After much fooling, and talking to some high-end Mac types, I learned the following (right from the folks in Cupertino):

Static linking of user binaries is not supported on Mac OS X. Tying user binaries to the internal implementation of Mac OS X libraries and interfaces would limit our ability to update and enhance Mac OS X. Instead, dynamic linking is supported (linking against crt1.o automatically instead of looking for crt0.o, for example).

We strongly recommend that you consider the limitations of statically linking very carefully, and consider your customer and their needs, plus the long-term support you will need to provide.

So there you have it. The folks at Apple have decided that since a statically linked binary that works *today* might not work *tomorrow* -- say, following an OS/X update, and since anything that doesn't work would 'degrade from the users experience', they flatly don't let you do it.

Which leaves me with 3 conclusions:

1\ even post-Jobs Apple is still anal compulsive when it comes to 'locking things down'

2\ even after considering the 'limitations of statically linking' (as per their missive), it isn't even clear that it is possible at all. Whereas it is possible, and (as it turns out) straightforward on Windows, GNU/Linux, Unix, Solaris....

3\ so, no statically linked MARK executable for OS/X people. Meaning (going back to the beginning), if you can get things working with the dynamically linked version of MARK, then....great! If not, you're either 'out of luck', or destined to spend some quality time figuring out how to change (typically) paths to various libraries under OS/X. If you manage to figure it out, please post the steps you took, so that others (including me) can benefit from your experiences (and not have to spin their wheels reinventing the wheel...). Or, if there is someone out there who knows the obscure (i.e., not obvious) steps I'd need to do to do a static linking under OS/X, I'll buy you a virtual beer of your choice.

Either that, or [rant] invest in a computer with an operating system that actually lets you (the person who forked over the money) do whatever you want with it...[/rant]

For grins, I just uploaded the latest 'dynamically' linked version of the OS/X-based MARK executable. Who knows, the most recent compilation might actually 'work' for those folks who have been having problems. Worth a try. Let me know if it does indeed 'solve any problems'.

Looks like Dave Koons and one of his students have solved the problem (or, at least, pointed strongly in the direction of a solution).

See his detailed post at: viewtopic.php?f=21&t=3233