First login?
Lost password?
 
 
cellml-tools-developers AT lists.cellml.org 
A list for the developers of CellML tools

Text archives Help


Re: [[cellml-dev] ] Mac OS X CellML API 1.12


Chronological Thread 
  • From: David Nickerson <david.nickerson AT gmail.com>
  • To: cellml-tools-developers AT lists.cellml.org
  • Subject: Re: [[cellml-dev] ] Mac OS X CellML API 1.12
  • Date: Wed, 14 May 2014 12:07:03 +1200
Hi Ivo,

You can also make use of the DYLD_LIBRARY_PATH to point your environment at
the appropriate location to find the libraries at run time.

In my tools, I use CMake to help "install" my applications and part of this
process will collect libraries and put them in the appropriate location for
the application and rewrite things like the rpath to be the correct values.
This also makes it trivial to then create archives for distribution. I
believe Alan Garny does the same thing in OpenCOR. See
http://www.cmake.org/cmake/help/v3.0/module/BundleUtilities.html for some
more hints on how this is done with CMake.

As OpenCMISS(Iron) and the OpenCMISSExtras move over to using CMake, build
support for platforms other than Linux will become available "natively".


Cheers,
David.


On Wed, May 14, 2014 at 11:54 AM, Ivo Siekmann
<ivo.siekmann AT unimelb.edu.au>wrote:

> Hi David (and others interested in the Mac OS X binaries),
>
> I was able to link to the dynamic libraries provided in the Cell ML SDK
> package... but it is not very convenient to use them.
>
> I believe that the "install name" in the .dylib files (see, for example,
> the response to this question)
> http://stackoverflow.com/questions/10021428/macos-how-
> to-link-a-dynamic-library-with-a-relative-path-using-gcc-ld
> is set to "./". Therefore linking to the libraries in the Cell ML SDK
> works but running the executable fails unless all .dylib files are copied
> to the directory of the executable. I'm not sure if this is the reason that
> the Cell ML SDK package is shown as "damaged or incomplete" by Mac OS X
> 10.9. And I don't know enough about building dynamic libraries on Mac OS X
> that I would have an idea how to fix this. But I'll be happy to enter this
> in the tracker if you think this is a good idea?!?
>
> Cheers
> Ivo
>
> P.S.: I managed to compile the API from source and link to OpenCMISS
> (which was what I wanted), so thanks for the hint!
>
>
> On 6/05/14 10:29 am, David Nickerson wrote:
>
>> Hi Ivo,
>>
>> See https://tracker.physiomeproject.org/show_bug.cgi?id=3673,
>> https://tracker.physiomeproject.org/show_bug.cgi?id=3671, and
>> https://tracker.physiomeproject.org/show_bug.cgi?id=3670 for some
>> recent tracker items regarding building the CellML API under OS X
>> 10.9.
>>
>> The upshot is that you should be able to build the current trunk code
>> (which has some fixes that are not in the 1.12 release, so I would
>> recommend using that), but you will not be able to build all the
>> tests. I have been able to build CellML2C (the code generation test)
>> but haven't tried the other test codes. I use clang for all
>> compilation/linking on OS X:
>> $ clang --version
>> Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
>> Target: x86_64-apple-darwin13.1.0
>> Thread model: posix
>>
>> The 1.12 binaries should work - not sure why you're getting that
>> error. I know I have linked my own code agains the 1.12 binaries
>> (using clang), but generally use my own build of the current trunk
>> code nowadays.
>>
>> If needed, Alan Garny has the OpenCOR development environment all
>> nicely set up so you can probably extract the required binaries from
>> that source.
>>
>>
>> Cheers,
>> Andre.
>>
>> On Mon, May 5, 2014 at 5:12 PM, Ivo Siekmann
>> <ivo.siekmann AT unimelb.edu.au>
>> wrote:
>>
>>> Hi CellMLers,
>>>
>>> I'm trying to get the CellML API running on Mac and I ran into some
>>> difficulties.
>>>
>>> 1) Compiling from source code:
>>> a) This fails with clang (Apple LLVM version 5.1 (clang-503.0.40)),
>>> apparently due to a forward declaration of the << operator in
>>> TestAssert.h
>>> when attempting to build DOMTEST.cpp.o (I don't know much about this but
>>> from some googling it seems to me that clang is stricter about the
>>> standard
>>> than some other compilers. So it may see errors where other compilers
>>> don't).
>>>
>>> b) Compiling with gcc 4.8.2 goes through and passes the tests of
>>> 'CheckCodeGenerator' and 'CheckVACSS' but fails for 'RunTestBin'. I
>>> didn't
>>> find out a lot more about how/why it failed.
>>>
>>> 2) Binaries:
>>> I've downloaded the binaries and Mac OS X complains that the package
>>> can't
>>> be opened "because it may be damaged or incomplete". Well, I can open the
>>> package and look at its contents, so it may be possible to link the
>>> libraries but I haven't tried.
>>>
>>> Any help would be greatly appreciated.
>>> Cheers
>>> Ivo
>>>
>>
>


--

[image: David Nickerson on about.me]

David Nickerson
about.me/david.nickerson
<http://about.me/david.nickerson>

Archive powered by MHonArc 2.6.18.

Top of page