It appears a lot of externs are required for cast_receiver.js. Is there an existing extern file for cast_receiver.js?
Thanks
Alex
For now, we don't have a public version of that available.
Related
I'm using the GTK provided Rust example from https://www.gtk.org, and am wondering how to nail down GTK as a dependency (or other type of prerequisite) so that the Rust program given there will build with cargo.
Here's the code, copied from there without modification:
use gio::prelude::*;
use glib::clone;
use gtk::prelude::*;
// When the application is launched…
fn on_activate(application: >k::Application) {
// … create a new window …
let window = gtk::ApplicationWindow::new(application);
// … with a button in it …
let button = gtk::Button::new_with_label("Hello World!");
// … which closes the window when clicked
button.connect_clicked(clone!(#weak window => move |_| window.close()));
window.add(&button);
window.show_all();
}
fn main() {
// Create a new application
let app = gtk::Application::new(Some("com.github.gtk-rs.examples.basic"), Default::default())
.expect("Initialization failed...");
app.connect_activate(|app| on_activate(app));
// Run the application
app.run(&std::env::args().collect::<Vec<_>>());
}
As is, without any Cargo.toml definitions for gtk, gtk symbols will not resolve when compiling the program.
How would you go about it most idiomatically?
I do have GTK installed on my system of course.
Thanks!
Rust can call code using the C ABI, but as #Herohtar explains, it is not automatic. You need to give the compiler the information about the extern "C" functions to be able to call them.
For commonplace libraries, there may be existing bindings out there. These are Rust library crates that contain all the glue already written for you. They work like any other Rust dependency that you put in your Cargo.toml file.
So indeed I ended up following the suggested approach of using the gtk-rs rust integration project rather than pursue any gtk wrapper of my own. My initial source of confusion has been that the gtk website just gave the gtk-rs sample code without any reference or mention of the gtk-rs project being assumed.
The public crate which that code assumes, even though not explicitly stated in the original code sample page, is called gtk; I guess that's the default naming convention: that the namespace and crate name are typically the same.
Including that crate in the build indeed satisfies the gtk namespace appearing in the code. And the same trivial naming convention applies for the gio and glib namespace requirements appearing in the sample code. They all seem to come from the gtk-rs project, though unlike other programming languages, this is not explicitly evident in the crate specification as only the name of the create, not the project containing it, are specified in cargo.
As to versions, I have chosen the most recent version of the gtk crate (as per suggestion from my VSCode rust plugin) and the newest crate feature providing support for GTK's latest supported API.
And I have also arbitrarily plucked versions of the gio and glib crates off another gtk-rs project hoping for seamless interoperability between the last two and the gtk crate itself, as they seem to need to be separately specified and not brought in by the gtk crate itself.
So with the following dependency definitions in my Cargo.toml, the sample code works:
[dependencies]
gtk = { version = "0.9.2", features = ["v3_22"] }
glib = "0.10"
gio = { version = "0.9", features = ["v2_56"] }
I'm new to rust but I might at present time think some of this is more complicated than it could be or would be in the case of other rust projects, or, that using the sample code assumes familiarity with the compatibility scheme of gtk-rs crates or that of the underlying native compatibility of gtk with glib and gio versions!
The latter aspect might be simple enough but not explicitly discussed where gtk-rs documentation discusses versioning.
An odd sticking point for me was that the following method had to be replaced by me with the one following it, perhaps this code sample is just slightly outdated compared to the latest version of the crate (?!).
provided code sample:
gtk::Button::new_with_label
actual method that is defined:
gtk::Button::with_label
I currently need to call a C++ function in my Flutter project, for a Linux desktop application (using dart:ffi). This page https://flutter.dev/docs/development/platform-integration/c-interop#first-party-library doesn't explain how to configure this kind of projects on Linux (neither for Windows).
After a few try, I'm unable to correctly link the C++ library.
The C++ Function
#include<iostream>
extern "C" {
void do_something(const char *program_name, const char *password)
{
//Do something with data
}
}
I added the following lines to the CMakeLists.txt :
add_library(my_native STATIC ../native_lib/my_native.cpp)
target_link_libraries(${BINARY_NAME} PUBLIC my_native)
And finally, I'm linking in Dart the following way :
// Since the CMake code was added in the executable CMakeLists.txt, it seems that it
// is supposed to be done that way, with DynamicLibrary.executable() rather than DynamicLibrary.process()
// method
final DynamicLibrary lib = DynamicLibrary.executable();
final doSomethingFuncPointer = lib.lookup<NativeFunction<do_something_signature>>("do_something");
It compiles fine, but at startup, the program returns the following error :
[ERROR:flutter/lib/ui/ui_dart_state.cc(171)] Unhandled Exception: Invalid argument(s): Failed to lookup symbol (/home/me/Documents/flutter/desktop_installer_framework/build/linux/debug/bundle/installer: undefined symbol: do_something)
I also tried with dynamic linking (marking the library as SHARED in CMakeLists.txt and linking it with DynamicLibrary.open("libmy_native.so")). Also tried calling DynamicLibrary.process() and putting the CMake lines inside the second CMakeLists.txt (the one in linux/flutter). It never finds symbols. So, I think I'm missing something here.
Any help would be appreciated.
Best regards
You've shown the definition; is that also the declaration? If so (which seems likely since you have the extern there) you are missing the visibilty and used annotations that the page you linked to described needing for C++, which would explain why the symbol isn't in the resulting binary.
I would like to prevent loading of malicious DLLs that may be possible through access of the current working directory as described in http://msdn.microsoft.com/en-us/library/ff919712(VS.85).aspx
The solution implemented in our C++ apps was to make a WinAPI call to SetDllDirectory(""), which would effectively remove the current working directory from the Windows DLL loading search path. However, it seems this solution is not available for our Delphi apps because the SetDllDirectory() function doesn't exist.
Is there an equivalent call in Delphi that does the same thing as SetDllDirectory("")? Thanks!
This should do the trick:
function SetDllDirectory(lpPathName:PWideChar): Bool; stdcall; external 'kernel32.dll' name 'SetDllDirectoryW';
Calling SetDllDirectory('') doesn't work? I see that it is declared properly in the latest versions of Windows.pas. If you have a version of Delphi in which it isn't declared, you can upgrade to the latest version of Delphi, or declare it yourself.
Update: And there you go... Jens just posted the declaration.
uses DSiWin32;
if not DSiSetDllDirectory('path') then
....
DSiSetDllDirectory will also take care of dynamic linking and will fail gracefully on pre-XP SP1 systems.
DSiWin32 is released as a freeware.
I'm trying to link my XPCOM extension against the 1.9.3a3pre SDK and I get the following:
error LNK2001: unresolved external symbol _moz_xmalloc
So, what lib do I need to link to? The documentation doesn't say.
This is on Windows right now, but I'll need it to build on Mac and Linux (32bit/64bit) as well.
Edit: Now with bounty.
Edit: Update: Turns out FF3.7 was cancelled. So I don't have to worry about this until FF4.
I have same error, and linking to mozalloc helps for that.
define 'XPCOM_GLUE' in C++ Preprocessor Definition property. It will fix the linking error.
Try defining MOZ_NO_MOZALLOC when compiling your extension, you will then get a DLL that uses your CRT's allocators. (Don't forget to use the NS_* allocators for XPCOM-compatible memory.)
Add MOZ_NO_MOZALLOC in C++->Preprocessor->Definition property.
Use xpcomglue_s_nomozalloc.lib instead of xpcomglue_s.lib in Linker->Input->Additional Dependencies
It will be OK!
reminder note: another option that can cause this even though everything else seems to be configured correctly in the project, is pointing at the wrong libs folder - such as 32 bit version for a 64 bit build.
edit v40 mozalloc.lib has changed name to mozglue.lib and has some additional methods.
edit v41 mozglue.lib has changed name to mozcrt.lib
I'm trying to test out a library that provides a VC++ example; however, I use gcc/g++ for all of my projects.
Well, the way the VC++ example accesses the library is it uses the #import directive, passing the location of the library DLL, then it does a using namespace LIBRARYNAME, and then it's able to create some undefined type (I'd assume it's defined in the DLL) and create a new instance of it with __uuidof. From then on, to call one of the library functions the example just does a createdObj->foo() and that's that.
Well... g++'s #import is different from VC++'s import (see here), so this example won't work for me.
Is there any way this can be converted to compile under g++, or am I SOL until the library developer provides me with a static library I can try out?
If you are using cygwin, then this page: http://www.cygwin.com/cygwin-ug-net/dll.html will provide you with all the help you need.
If you are using mingw, you can accomplish the same thing, but you probably won't have grep and sed, so you'll have to use some other method of doing the filtering to get your .def file.
If you were using #import in VC++ it means the DLL isn't a regular DLL, it's a COM DLL.
Since gcc doesn't have COM support, you'll just have to wait for the library author to write a non-COM version.
Maybe it could have helped you to use the OLEViewer and "View type information" to extract the basics of the IDL. Or maybe you could just use the VC++ generated .tlh and .tli files and import them into your G++ project.
I guess this answer is way too late, but right now I'm encountering similar issues myself so I just got into this thread. Hope you found the solution on time.
Regards.