I'm trying to link my project with static openssl. I've noticed that there is flag static in openssl package: https://github.com/NixOS/nixpkgs/blob/d6a12e8d9e0a4ac35ed401881e0d3160c764ac36/pkgs/development/libraries/openssl/default.nix#L5 but i have no idea how it can be set when using it. (pkgs.openssl ...?).
Currently I "solved" it by using pkgs.pkgsStatic.openssl, but it have very annoying side effect on form of gcc and other not related dependencies being recompiled statically (what the hell?).
How can use openssl package with static flag enabled?
You can change the arguments passed to a package with override. This is enough if you just want to build a static openssl:
pkgs.openssl.override {
static = true;
}
To build other packages using this customised openssl, it must be added back into nixpkgs using an overlay:
self: super: {
openssl = super.openssl.override {
static = true;
};
}
This overlay can be placed in ~/.config/nixpkgs/overlays/openssl-static.nix or added to configuration.nix's nixpkgs.overlays.
Related
I have an issue with SPM remote package dependencies. Right now, due to proxy and VPN issues, some co-workers have to replace remote packages with local folders.
The remote packages are declared in the project file under the tab "Package Dependencies".
Example of the Xcode project file section:
/* Begin XCRemoteSwiftPackageReference section */
2C45251029658D430029D665 /* XCRemoteSwiftPackageReference "OCHamcrest" */ = {
isa = XCRemoteSwiftPackageReference;
repositoryURL = "https://github.com/hamcrest/OCHamcrest.git";
requirement = {
kind = exactVersion;
version = 9.0.1;
};
};
// other remote dependencies from Github or Bitbucket to follow in this section
My question is how can I isolate this configuration into a separate file that can be easily replaced with a local file version to avoid the constant clicks to point to local dependencies? Would an xcconfig file work for this? I haven't found any examples on the web for this case.
Any suggestions are very much appreciated.
In our Kotlin Mobile Multiplatform project for iOS and Android, we're trying to access TrustWalletCore cocoapod from Kotlin.
// build.gradle.kts (:shared)
cocoapods {
version = "1.0"
podfile = project.file("../iosApp/Podfile")
pod("WalletCore")
}
And the Podfile is
target 'iosApp' do
pod 'TrustWalletCore'
end
This successfully enables import cocoapods.WalletCore.* in shared/iosMain - without the above cocoapods {...} the import is unavailable.
However, only a Crypto class is available from this package (and CryptoMeta which doesn't look too different).
By the looks of it, it's generated from the Pod/library by commonizer in 0_WalletCore.knm (about 15 expect functions in total - a couple here for illustration):
#kotlin.commonizer.ObjCCallable public open external expect fun base58Encode(data: platform.Foundation.NSData): kotlin.String { /* compiled code */ }
#kotlin.commonizer.ObjCCallable public open external expect fun generateMnemonicFromSeed(seed: platform.Foundation.NSData): kotlin.String { /* compiled code */ }
It has mnemonic-related functionality, as well as signHash/verifySignature but not much else.
I was hoping to see - available to import in Kotlin - classes like HDWallet, EthereumSigningInput etc.
I can use these library classes in Swift, via pod TrustWalletCore in Xcode (import WalletCore).
WHY can I not get a similar/full set of classes via native.cocoapods plugin?
Try to declare dependency with moduleName parameter:
kotlin {
cocoapods {
...
pod(name = "TrustWalletCore", version = "3.1.0", moduleName = "WalletCore")
}
}
I've just installed Apache NetBeans IDE 11.1, JDK 13, openjfx-13, and JNA-platform-5.4.0, on Win10 x64. I can't get to first base using JNA. The following code flags Native in the import statement for com.sun.jna.Native as an unknown symbol. The call to Native.load and the import statements are taken directly from https://github.com/java-native-access/jna/blob/master/www/GettingStarted.md
This screen shot shows the project library list 1:
package jrailroad;
import com.sun.javafx.PlatformUtil;
import com.sun.jna.platform.win32.Kernel32;
import com.sun.jna.platform.win32.Kernel32Util;
import com.sun.jna.Native;
public class ComPort
{ // class ComPort
public int os;
public static final int OS_WINDOWS = 0; // a Windows platform
public Kernel32 k32 = null;
ComPort()
{ // ComPort.ComPort
os = -1;
if (PlatformUtil.isWindows())
{ // windows
os = OS_WINDOWS;
k32 = (Kernel32) Native.load("kernel32", Kernel32.class);
} // windows
} // ComPort.ComPort
} // class ComPort
As the Getting Started link that you posted states,
Java Native Access (JNA) has a single component, jna.jar; the
supporting native library (jnidispatch) is included in the jar file.
... Begin by downloading the latest release of JNA and referencing
jna.jar in your project's CLASSPATH.
You did not include jna.jar, but rather you included the user-contributed mappings to various platforms, jna-platform.jar. The link you noted in your comment includes links to both of these files:
JNA
jna-5.4.0.jar
This is the core artifact of JNA and contains only the binding library
and the core helper classes.
JNA Platform
jna-platform-5.4.0.jar
This artifact holds cross-platform mappings and mappings for a number
of commonly used platform functions, including a large number of Win32
mappings as well as a set of utility classes that simplify native
access.
And as mentioned in the comments, manually including jar files quickly becomes unsustainable when your dependencies have dependencies themselves. You should learn how to use a package manager such as Maven, Gradle, or Ivy. Your IDE has a process for this, just search for, e.g., "netbeans maven" for more guidance.
I'm trying to create an iOS Titanium Module using a pre-compiled CommonJS module. As the README file says:
All JavaScript files in the assets directory are IGNORED except if you create a
file named "com.moduletest.js" in this directory in which case it will be
wrapped by native code, compiled, and used as your module. This allows you to
run pure JavaScript modules that are pre-compiled.
I've created the file like this:
function ModuleTest(url){
if(url){
return url;
}
}
exports.ModuleTest = ModuleTest;
I'm using the 5.1.2.GA SDK (also tried with 5.3.0.GA) and I can build the module successfully either with python build.py or titanium build --platform iOS --build-only.
Then, in my test app doing:
var test = require('com.moduletest');
var url = new test.ModuleTest('http://url');
Gives me this error:
undefined is not a constructor.
I've been trying a lot of alternatives but nothing seems to work and I didn't find any help on documentation about pre-compiled JS modules for iOS. Actually, the same process works great for Android!
Do you have some idea why?
My environment:
XCode 7.3.1
Operating System
Name - Mac OS X
Version - 10.11.5
Architecture - 64bit
# CPUs - 8
Memory - 16.0GB
Node.js
Node.js Version - 0.12.7
npm Version - 2.11.3
Appcelerator CLI
Installer - 4.2.6
Core Package - 5.3.0
Titanium CLI
CLI Version - 5.0.9
node-appc Version - 0.2.31
Maybe this is something related to my Node version or appc CLI, not sure =/
Thank you!
There are 2 solutions.
1) Don't put it in assets, but in the /app/lib folder as others have mentioned.
2) wrap it as an actual commonjs module, like the module I wrote
In both cases, you can just use require('modulename'). In case 2 you will need to add it to the tiapp.xml file just like any other module.
The path of your file will come in /modules/commonjs/modulename/version/module.js or something similar. My linked module will show you the requirements and paths needed.
I use a slightly different pattern that works excellent:
First a small snippet from my "module":
Stopwatch = function(listener) {
this.totalElapsed = 0; // * elapsed number of ms in total
this.listener = (listener != undefined ? listener : null); // * function to receive onTick events
};
Stopwatch.prototype.getElapsed = function() {
return this.totalElapsed;
};
module.exports = Stopwatch;
And then this is the way I use it:
var StopWatch = require('utils/StopWatch');
var stopWatch = new StopWatch(listenerFunction);
console.log('elapsed: ' + stopWatch.getElapsed());
I have a very tiny Objective-C library built for iOS and I want to export it to Unity. I understand the basic process of writing a csharp wrapper that marshals all the invocations to native library, but I completely have no idea where to start. Could anyone please explain step-by-step how to create a unity package with my library so I could also distribute it to other developers.
Unity3d documentation is pretty brief and does not explain anything.
Thanks.
Okay, after playing few days with Unity3d on Mac I finally figured it out. All the code in this guide is dummy. I have written this stuff in 15 minutes or so, so don't be bothered by mistakes and typos.
1) Open Unity, create new project (File -> New Project) and save it somewhere
2) When the project is generated it has the following structure:
ProjectName/Assets (That's what you need)
ProjectName/Library (Nevermind what's there)
ProjectName/ProjectSettings (You don't care about it)
ProjectName/ProjectName.sln (MonoDevelop project)
3) Go to ProjectName/Assets and create the following folders: Plugins/iOS, so in the end you'll have a folder structure like this: ProjectName/Assets/Plugins/iOS
4) Put your compiled library (.a) file and necessary headers inside of ProjectName/Assets/Plugins/iOS or copy the source code of your library there (.mm, .h, .m, etc..). Remember, normally you can only access C-functions from C#, so you'll have to wrap your Objective-C stuff in C-code somehow, in my case all Objective-C objects were implemented in a form of Singleton so it wasn't hard to make a C-style wrapper around, for instance:
CWrapper.h:
extern "C" void MySDKFooBarCFunction();
CWrapper.mm
#import "CWrapper.h"
#import "MyObjectiveCLibrary.h" // your actual iOS library header
void MySDKFooBarCFunction() {
[MyObjectiveCLibrary doSomeStuff];
}
5) Then go to ProjectName/Assets and create a folder for CSharp wrapper class(es), call it whatever you want, for example: ProjectName/Assets/MySDK
6) Inside of MySDK folder create MySDK.cs file, the dummy example of C# wrapper would look like this:
using UnityEngine;
using System;
using System.Runtime.InteropServices;
public class MySDK
{
// import a single C-function from our plugin
[DllImport ("__Internal")]
private static extern void MySDKFooBarCFunction();
// wrap imported C-function to C# method
public static void FooBarCFunction() {
// it won't work in Editor, so don't run it there
if(Application.platform != RuntimePlatform.OSXEditor) {
MySDKFooBarCFunction();
}
}
}
7) Create a shell script to pack this stuff into .unitypackage and put it next to your project folder (not inside). Adjust EXPORT_PATH and PROJECT_PATH variables in the script for your needs.
#!/bin/sh
WORKDIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
UNITY_BIN="/Applications/Unity/Unity.app/Contents/MacOS/Unity"
EXPORT_PATH="${WORKDIR}/ProjectName.unitypackage"
PROJECT_PATH="${WORKDIR}/ProjectName"
ASSETS_PATH="Assets"
$UNITY_BIN -batchmode -quit \
-logFile export.log \
-projectPath $PROJECT_PATH \
-exportPackage $ASSETS_PATH $EXPORT_PATH
8) Run the created bash script to get your package build. All stuff from Assets will be included in XCode project for your Unity Project when you generate it via File -> Build Settings in Unity Editor. You can use generated package to distribute your code to other developers so they can simply include your library to their Unity projects by double clicking on the package file.
Don't forget to shutdown Unity Editor when you run this script, otherwise it may fail to build a package.
If you have some issues and package does not show up, this script always prints log to export.log
Next steps make sense only if you want to make a Demo unity project for your library (good for testing at least)
9) You can put created Unity project (ProjectName.unity) to Assets/MySDKDemo so you have a demo inside of your package.
10) Create a simple script for your Demo Unity3d scene at Assets/MySDKDemo/MySDKDemo.cs, for example:
using UnityEngine;
using System;
using System.Collections;
public class MySDKDemo : MonoBehaviour
{
private GUIStyle labelStyle = new GUIStyle();
private float centerX = Screen.width / 2;
// Use this for initialization
void Start ()
{
labelStyle.fontSize = 24;
labelStyle.normal.textColor = Color.black;
labelStyle.alignment = TextAnchor.MiddleCenter;
}
void OnGUI ()
{
GUI.Label(new Rect(centerX - 200, 20, 400, 35), "MySDK Demo", labelStyle);
if (GUI.Button(new Rect(centerX - 75, 80, 150, 35), "DoStuff"))
{
MySDK.FooBarCFunction();
}
}
}
11) Go to Unity Editor. Find the "Main Camera" in left sidebar in Unity Editor, select it and in the bottom of Inspector panel (right sidebar) click on AddComponent, select Scripts -> MySDKDemo script
12) Build the XCode project and run on device.
Few notes
1) Plugins don't work in Unity Editor, simply because they're not compiled in the real-time, well, not sure but probably until you use C# in your plugins, probably C# stuff gets linked immidiately and works in Editor environment.
2) This post does not cover marshaling, or data/memory management between native <-> managed code, as it is very well documented.
Interop with Native Libraries # Mono project
3) Callbacks from C# to C can be passed using C# delegates, on C-side you use standard functions declarations, on C# side you declare delegates with the same signature. It seems that booleans, integers and strings (C: char*) are marshalled flawlessly (I don't talk about memory management policy and who's responsible to release memory or return value policies).
However it will not work on iOS builds out-of-box due to platform limitations, but C#-to-C callbacks still can be implemented using MonoPInvokeCallbackAttribute, useful links on this topic:
Reverse Callbacks # Xamarin Docs
MonoPInvokeCallbackAttribute example # Xamarin Forums
Actually in Unity 4 there's AOT.MonoPInvokeCallbackAttribute already implemented, it's limited to static delegates that can be passed to unmanaged code, but still better than nothing.
4) There's a way to get Unity RootViewController using UnityGetGLViewController function. Just declare this function in your implementation file, i.e.:
extern UIViewController *UnityGetGLViewController();
And use UnityGetGLViewController() whenever you need to get an access to RootViewController.
5) There's much more magic and ugly stuff in details, keep your C interfaces as simple as possible otherwise marshalling can become your nightmare and also keep in mind that managed-to-unmanaged is generally expensive.
6) You definitely use some frameworks in your native code and you don't want linker problems. For example, if you use Keychain in your library then you need to include Security.framework into Xcode project.
I suggest to give a try to XUPorter, it helps Unity to integrate any additional dependencies into Xcode project.
Good luck!