I am working on a ESP32 project that required firmware update, so i am using the following
void update_fwm(void)
{
esp_http_client_config_t config = {
.url = "https://myserver.net/firmware/ESP32/Device1/fmw.bin",
//.cert_pem = (char *)server_cert_pem_start,
};
esp_err_t ret = esp_https_ota(&config);
if (ret == ESP_OK) {
esp_restart();
} else {
return ESP_FAIL;
}
return ESP_OK;
}
When i preform a build i get the followin:
../main/azure_iot_freertos_esp32_main.c:10:10: fatal error: esp_https_ota.h: No such file or directory
#include "esp_https_ota.h"
If I understood it correctly with ESP32 IDF, all libraries are inbuild into the compiler?
Is there reason for this error?
Without further details I assume that there is propably a problem with your toolchain (linking). If the setup is done correctly this esp-lib should be "found".
Please refer to the official Espressif documentation for the correct setup of the toolchain on your system: Espressif Get Started
If used in a (self-written) component, make sure to use REQUIRES <lib> in the CMakeLists-file.
You will need REQUIRES esp_https_ota in CMakeLists.txt if you are also using set(COMPONENTS "main").
Here, or here for a complete version, you can find a sample GRPC "Hello World" project for Unity. Only the first version, that is built for Unity and wrapped in a DLL is working perfectly fine in Unity IDE and on Standalone build. The Raw Grpc.Core files are referencing everything correctly in IDE but they have Marshaling problem.
Unfortunately, it cannot get build for UWP with IL2CPP backend. Unity builds the project and creates a .sln project. But Visual Studio always gives LNK2001 for GRPC properties on the final compilation.
Here are first error codes:
LNK2001 unresolved external _grpccsharp_init#0
LNK2001 unresolved external _grpccsharp_shutdonw#0
LNK2001 unresolved external _grpccsharp_version_string#0
...
Ok, thanks to #Sunius, I digged into it a little bit more. There are some points, I am going to add to the question:
There are two methods regarding referencing extern methods in GRPC C# package. They are named static and shared libs.
internal class DllImportsFromStaticLib
{
private const string ImportName = "__Internal";
[DllImport(ImportName)]
public static extern void grpcsharp_init();
[DllImport(ImportName)]
public static extern void grpcsharp_shutdown();
...
}
and
internal class DllImportsFromSharedLib
{
private const string ImportName = "grpc_csharp_ext";
[DllImport(ImportName)]
public static extern void grpcsharp_init();
[DllImport(ImportName)]
public static extern void grpcsharp_shutdown();
...
}
I tried to test it with the shared one, I got another linking error file which is a little bit different.
LNK2001 unresolved external _dlopen#8
LNK2001 unresolved external _dlsym#8
...
In two separate methods, extern methods are getting connected to the internal interface:
public NativeMethods(DllImportsFromStaticLib unusedInstance)
{
this.grpccsharp_init = DllImportsFromStaticLib.grpccsharp_init;
this.grpccsharp_shutdown = DllImportsFromStaticLib.grpccsharp_shutdonw;
...
}
and
public NativeMethods(DllImportsFromSharedLib unusedInstance)
{
this.grpccsharp_init = DllImportsFromSharedLib.grpccsharp_init;
this.grpccsharp_shutdown = DllImportsFromSharedLib.grpccsharp_shutdonw;
...
}
And which method will get called is defined here:
private static NativMethods LoadNativeMethodsUnity()
{
switch(PlatformApis.GetUnityRuntimePlatform())
{
case "IPhonePlayer":
return new NativeMethods(new NativeMethods.DllImportsFromStaticLib());
default:
return new NativeMethods(new NativeMethods.DllImportsFromSharedLib());
}
}
Some updates:
Thanks to #jsmouret, there is Stub.c file in his Grpc Github with fake methods, so Linker does not complain about Grpc_init methods anymore.
Next Error: dlopen, dlsym, dlerror:
First, I tried to use the same, Stub technique, but it did not help in this case, or maybe I did it wrong.
Thanks to #Sunius, I commented out all of "__Internal" dll import codes. So I am not getting any dlopen, dlsym, and dlerror errors.
Next Error: It happens from inside application, not the visual studio debugger. It tells me: "exception: to marshal a managed method, please add an attribute named 'MonoPInvokeCallback' to the method definition."
exception: error loading the embedded resource "Grpc.Core.roots.pem"
and
exception: To marshal a managed method, please add an attribute named 'MonoPInvokeCallback' to the method definition.
After I googled it, I know my options, but the question it, for which method should I do that?!
Thanks to my colleague Alice, #Sunius and #jsmouret, at the end, grpc works on UWP on Unity Platform through this steps:
Download Grpc.Core folder from Google Grpc Github.
Download Grpc Unity plugin from their official site.
Copy the runtime folder to your Grpc.Core folder. Please remove Grpc.Core.dll that you get from Grpc Unity Plugin, since we are using their source code.
Grpc should be in a folder called, Plugins in Unity, otherwise it will not be recognized.
Include this file in your runtime folder.
Include the Stub also from the Unity Plugin Inspector for WSA.
Find runtime .dll for Windows and include them in WSA from Unity Plugin Inspector.
By now, you should be getting _dlopen error.
Search through your Unity Solution with an IDE for "__Internal". There are not so many places, but comment them out. Also some methods that are depended on "__Internal"s, like dlopen and dlsym.
By now, you are not getting anymore build error but you need to make Grpc work.
Search for something like "DefaultSslRootsOverride" and comment out like below:
internal static class DefaultSslRootsOverride
{
const string RootsPemResourceName = "Grpc.Core.roots.pem";
static object staticLock = new object();
/// <summary>
/// Overrides C core's default roots with roots.pem loaded as embedded resource.
/// </summary>
public static void Override(NativeMethods native)
{
lock (staticLock)
{
//var stream = typeof(DefaultSslRootsOverride).GetTypeInfo().Assembly.GetManifestResourceStream(RootsPemResourceName);
//if (stream == null)
//{
// throw new IOException(string.Format("Error loading the embedded resource \"{0}\"", RootsPemResourceName));
//}
//using (var streamReader = new StreamReader(stream))
//{
// var pemRootCerts = streamReader.ReadToEnd();
// native.grpcsharp_override_default_ssl_roots(pemRootCerts);
//}
}
}
}
Search for something like "static void HandWrite" and add an attribute like something in below:
[MonoPInvokeCallback(typeof(GprLogDelegate))]
private static void HandleWrite(IntPtr fileStringPtr, int line, ulong threadId, IntPtr severityStringPtr, IntPtr msgPtr)
{
try
{
var logger = GrpcEnvironment.Logger;
string severityString = Marshal.PtrToStringAnsi(severityStringPtr);
string message = string.Format("{0} {1}:{2}: {3}",
threadId,
Marshal.PtrToStringAnsi(fileStringPtr),
line,
Marshal.PtrToStringAnsi(msgPtr));
switch (severityString)
{
case "D":
logger.Debug(message);
break;
case "I":
logger.Info(message);
break;
case "E":
logger.Error(message);
break;
default:
// severity not recognized, default to error.
logger.Error(message);
break;
}
}
catch (Exception e)
{
Console.WriteLine("Caught exception in native callback " + e);
}
}
I guess, you are done. In case, it did not work for your UWP, let me know, maybe I can help. :)
It looks like your plugin uses "__Internal" P/Invoke to call those native functions:
https://github.com/grpc/grpc/blob/befc7220cadb963755de86763a04ab6f9dc14200/src/csharp/Grpc.Core/Internal/NativeMethods.Generated.cs#L542
However, the linker cannot locate those functions and thus fails. You should change that code to either specify the DLL file name where the functions are implemented, or drop the source files with definitions for those functions into your Unity project. Or, if that code path isn't actually invoked (since you said it works on the standalone player), #ifdef it out from UWP build.
You can find more information about "__Internal" P/Invoke here:
https://docs.unity3d.com/Manual/windowsstore-plugins-il2cpp.html
I am using POCO library 1.6.0 on OS X 10.10 and XCode 6.1.1 for building a mac application.
I have compiled it for static linking using the following configuration:
./configure --omit=Data/ODBC,MonoDB,Data/MySQL,Data/SQLite --config=Darwin64-clang-libc++ --static
This results in successful compilation and produces .a files.
I have linked the libraries in XCode under linked frameworks and libraries.
The app runs successfully.
Questions:
However on execution of Poco::Net::HTTPRequest to http://example.org, it fails with error : Net Exception Address family not supported. There is a closed issue here as well: https://github.com/pocoproject/poco/issues/657.
This happens only when the Build Configuration is set to "Debug" and not "Release" which is strange.
Here is the code:
void test(){
Poco::JSON::Object result;
result.set("error", "0");
result.set("errorMessage","");
result.set("response","");
result.set("success", "true");
try {
Poco::URI uri("http://example.org/?time=12345");
Poco::Net::HTTPClientSession session(uri.getHost(), uri.getPort());
Poco::Net::HTTPRequest req(Poco::Net::HTTPRequest::HTTP_GET,uri.getPath(), Poco::Net::HTTPMessage::HTTP_1_1);
req.set("User-Agent","Chrome/3.2");
session.sendRequest(req); // sends request, returns open stream
// Get response
Poco::Net::HTTPResponse res;
std::istream& is = session.receiveResponse(res);
std::string str=std::string((std::istreambuf_iterator<char>(is)),
std::istreambuf_iterator<char>());
std::cout<<str;
} catch (Poco::Exception& e) {
result.set("error", 103);
result.set("errorMessage",e.what()+e.message());
result.set("success", "false");
}
std::ostringstream stream;
result.stringify(stream);
std::string str = stream.str();
std::cout<<""<<str<<"";
}
I've searched around and can't find anything that relates to my problem.
#include "Ogre\ExampleApplication.h"
class Example1 : public ExampleApplication
{
public:
void createScene()
{
}
};
int main(void)
{
Example1 app;
app.go();
return 0;
}
Steps I've taken:
added ...\OgreSDK_vc10_v1-7-4\include to the include path of my project.
added ...\OgreSDK_vc10_v1-7-4\boost_1_42 to the include path of my project.
added ...\OgreSDK_vc10_v1-7-4\boost_1_42\lib to my library path.
added ...\OgreSDK_vc10_v1-7-4\lib\debug to my library path.
linked OgreMain_d.lib and OIS_d.lib
I've also tried it the way the Ogre site teaches you. But I get the same errors.
Using Visual Studio 2010.
It seems the library name is misspelled. It should be OgreMain_d.lib, not OrgeMain_d.lib.
I write the code in I/O Kit Driver template in the following way:
#include <IOKit/IOService.h>
class com_osxkernel_driver_IOKitTest : public IOService
{
OSDeclareDefaultStructors(com_osxkernel_driver_IOKitTest)
public:
virtual bool init (OSDictionary* dictionary = NULL);
virtual void free (void);
virtual IOService* probe (IOService* provider, SInt32* score);
virtual bool start (IOService* provider);
virtual void stop (IOService* provider);
};
#include "IOKitTest.h"
#include <IOKit/IOLib.h>
#define super IOService
OSDefineMetaClassAndStructors(com_osxkernel_driver_IOKitTest, IOService)
bool com_osxkernel_driver_IOKitTest::init (OSDictionary* dict)
{
bool res = super::init(dict);
IOLog("IOKitTest::init\n");
return res;
}
void com_osxkernel_driver_IOKitTest::free(void)
{
IOLog("IOKitTest::free\n");
super::free();
}
IOService* com_osxkernel_driver_IOKitTest::probe (IOService* provider, SInt32* score)
{
IOService *res = super::probe(provider, score);
IOLog("IOKitTest::probe\n");
return res;
}
bool com_osxkernel_driver_IOKitTest::start (IOService *provider)
{
bool res = super::start(provider);
IOLog("IOKitTest::start\n");
return res;
}
void com_osxkernel_driver_IOKitTest::stop (IOService *provider)
{
IOLog("IOKitTest::stop\n");
super::stop(provider);
}
When I build this code, I get four errors:
Expected function body after function declarator
stray '\357' in program
stray '\277' in program
stray '\274' in program
Can you see the error?
Can you see the error?
No. But the compiler can. And Xcode will show it to you.
I pasted your code into a new project and did compile it:
All three stray characters are in the same part of the code.
If such a stray '\something' error happens you have a character in your code that can't be compiled, and you usually can't see them. They often come from a copy and paste that went wrong.
Just delete the line with the error and write it again. Don't copy and paste or anything.
I took that part of the code and opened it in a hex editor. So you can see where these errors come from.
For anyone that uses KATE (KDE Advanced Text Editor), I was able to fix similar 'stray errors' by opening up the files causing the error and Unchecking the "Add Byte Order Mark (BOM)" option which can be found under the Tools menu. The file will not appear to have been changed after you uncheck this setting so you will need to actually save (Ctrl+S) the file. When you re-compile, the error will be gone.