HTTP POST on LabVIEW 2012 for Mac Error: -1967362015

[fred@solarlogic]

So I'm in the process of moving a labview application to a mac platform and I've run into some functionality issues with the HTTP Client Vi's.

The connections work fine both with http and https requests in the project view, but begin to fail when compiled into an executable. I was able to isolate the error to code -1967362015, which reads as a failure to load library error. While reading other posts I was given the idea to symlink the ni_httpclient libraries to the NI folder, but this did not solve my issue. Could this have anything to do with the fact that the LabVIEWHTTPClient.lvlib considers the NI_InternetTK_Core_VIs.lvlib:SSL.vi to be a "friend" library?

The vi I've attached is one that tries a get or a post request without ssl and receives the same error on both when built as an executable. It's tough to debug since the http client vi's are locked down. Any help would be awesome!

[JasoNI]

Hello,

It sounds like you found this forum (http://forums.ni.com/t5/LabVIEW/get-HTTP-on-LabVIEW-2010-for-Mac/m-p/1591860#M580442) and tried the solution, is that correct?

Another option is to move the ni_httpClient_nossl.framework from HD:Applications:National Instruments: LabVIEW 2012: Resources to HD:Applications:National Instruments: LabVIEW 2012

I hope this helps!

Regards,

Jason D

Applications Engineer

National Instruments

[fred@solarlogic]

Yes that's the article I discovered. And the file move didn't seem to resolve the issue unfortunately.

[freighTrain]

Hi fred@solarlogic,

Do other executables run correctly? I'm assuming you have the LabVIEW 2012 Run-Time Engine installed. 

[fred@solarlogic · Accepted solution]

We were able to get NI phone support on the issue, and it turns out it was an issue with LabVIEW 2012 on the Mac platform. The workaround to the library issue was as follows: Located in the  /Library/Frameworks/LabVIEW\ 12.0\ Runtime.framework/resource/ folder there should be a file called ni_httpClient.framework.  Please rename this file to ni_httpClient.framework.bak.  Then rebuild the executable.

This solved the issue of building applications using the http client vi's, but there are still outstanding issues building applications using SSL.

Thank you for the suggestions.

[brunobraun]

Thanks for this hint!

It also solves problems with http_get.

Seems, we can not skip our JAVA code yet. Hopefully, NI will fix this issue in their runtime environemnt. In the meantime it semas, that a "customized" runtime must be distributed with our software.