MathGroup Archive 2013

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Getting an array into a C program through mathlink

  • To: mathgroup at smc.vnet.net
  • Subject: [mg130343] Re: Getting an array into a C program through mathlink
  • From: John Fultz <jfultz at wolfram.com>
  • Date: Wed, 3 Apr 2013 22:51:57 -0400 (EDT)
  • Delivered-to: l-mathgroup@mail-archive0.wolfram.com
  • Delivered-to: l-mathgroup@wolfram.com
  • Delivered-to: mathgroup-newout@smc.vnet.net
  • Delivered-to: mathgroup-newsend@smc.vnet.net
  • References: <khsbap$35l$1@smc.vnet.net> <20130401050011.AD2D46AE5@smc.vnet.net> <3098095B-C283-4E66-9677-1556474225FC@wolfram.com> <515B55FE.2070906@cox.net>

If MathLink is broken, Mathematica is broken.  MathLink is not just some 
toss-off library used in a few corner cases by a few random users and 
barely supported by Wolfram.  It is a core part of the system, and if 
it's busted, Mathematica won't even run.  I could point to a dozen 
binaries in the Mathematica distribution that work MathLink harder than 
most user programs do, but I really only need to point to two -- the 
Mathematica kernel and the Mathematica front end.  MathLink is the one 
and only mechanism by which these two components communicate with each 
other.

It is true that there can be dependencies on versions of operating 
systems and libraries.  And to maintain maximum compatibility with a 
wide range of systems, we're very careful about which build systems and 
libraries we build our binaries (MathLink, FE, kernel, etc.) against, 
generally favoring somewhat older versions so we don't accidentally 
slurp in newer dependencies that could break on legacy systems.  The 
range of operating systems and libraries Mathematica (and thus MathLink) 
work against are generally pretty well advertised, and we've done a 
pretty good job of supporting operating systems at least 5 years out of 
date (save on MacOS, where the user culture tends to be highly 
aggressive about updating operating systems, so the support window is a 
bit shorter).

In summary, I would claim that, to the extent that your worries about 
MathLink are true, they apply to Mathematica itself.  The fact that 
Mathematica is not constantly broken on every new Linux distribution 
suggests that your concerns, while not invalid, are not as serious as 
you seem to suggest.

Sincerely,

John Fultz
jfultz at wolfram.com
User Interface Group
Wolfram Research, Inc.



On Apr 2, 2013, at 5:04 PM, "John D. Hendrickson and Sara Darnell" <johnandsara2 at cox.net> wrote:

> Ok I think you asked for a little more info about why mathlink which seems fine on developer's machine might not be fine elsewhere.
>
> Why is because to work mathlink needs to link against OS libraries which change.
>
> 
http://reference.wolfram.com/mathematica/tutorial/MathLinkDeveloperGuide-Unix.html#725481284
>
> clearly says it is library hooked and versional to specific libraries.
>
> 
http://support.wolfram.com/search/?query=mathlink&lang=en&noImg=1&submit.x=0&submit.y=0
>
> are some problem reports of:
>
> LinkConnect::"linkc": "\!\(\[LeftSkeleton] 1 \[RightSkeleton]\) is dead; attempt to connect failed."
>
> (there were many unsure if wr has removed them.  or search Google and find some.  it's hard to believe you looked hard if you can't find any.)
>
> For example I have Mathematix Version zzz.  I later upgrade Linux. Mathlink is now broken.  I may be able to run simple pre-compiled ones (unlikely to be available for my exact linux disto) but most won't work because the libs have changed or they are for a different linux distro.  You'd think "just recompile mathlink apps".  NO.
>
> To resolve this I need to run Mathematica and any mathlink apps in a chroot of a previous Linux version.  Compilation of other people's mathlink apps would also have to be done in the chroot - which won't work for newer mathlink apps.  Too much effort.
>
> You'd think I can just compile against older libs: surprise that works at compile time but not run-time since libML.a is loaded accessed through the newer libs and it is older: IT WON'T EVER WORK.
>
> My other choice is to buy new mathematica.  But if I had any mathlink apps I needed I'd have to rewrite them since they won't compile with the new linux libs / environment.  This also requires a new computer. $$  And how long is it until it's all broken again?
>
> (obviously upgrading Mathematica is better if you have time and money for the "upgrade escapade")
>
> (Note I mean Linux distribution, the linux kernel isn't usually involved.  unlike the old days: often binaries today often won't work when copied from one distro to another, due to lib variations they keep uploading)
>
> Obviously there's another answer: wolfram releases a different mathlink that doesn't rely on lib offsets runtime :)  I won't go into it but I know what breaks it.
>
> --------------------------------
>
> John Fultz wrote:
>> That's an interesting observation, but I can't say it matches my own experience.  I've found MathLink to be remarkably compatible across major version number changes of Mathematica, and to be generally robust. It is the only way the FE and the kernel communicate with each other (not to mention other lesser components of the system), and the nature of that connection is not simple; I would say it uses a majority of the features that MathLink has to offer.
>> It's not clear to me exactly what you're referring to as "Wolfram problem reports".  But I'd certainly be interested in knowing about any issues that you or anyone else may be experiencing with MathLink.
>> John Fultz
>> jfultz at wolfram.com
>> User Interface Group
>> Wolfram Research, Inc.
>> On Apr 1, 2013, at 12:00 AM, debguy <johnandsara2 at cox.net> wrote:
>>> my advice is to avoid mathlink because library issues cause
>>> compatibility problems (see Wolfram problem reports).  ie after or
>>> without upgrade it's broken for someone trying to use.
>>>
>>> if you can accept fast but not fastest results I suggest this:
>>>
>>> to use "exec" in C to call math binary with piped commands (we're
>>> talking text input output) and use Put to get what into a file (can
>>> even be forked, run in background, doing it that way).  then your
>>> application reads file when done (fread is fast, maybe not fast as
>>> direct read from mathlink).
>>>
>>> most tasks can be done without ever using C.  doing some special
>>> graphics or something?
>>>
>




  • Prev by Date: Re: Packages with data sets
  • Next by Date: Problem with function definition inside DynamicModule
  • Previous by thread: Re: Getting an array into a C program through mathlink
  • Next by thread: Re: Getting an array into a C program through mathlink