NIST(National Institute of Standards and Technology) library for iOS - ios

I downloaded some code which contains some source code and some txt files.
The Read me or Installation file says following,
NBIS Open Source Software Installation Guide
(For LINUX and MAC OSX)
----------------------------------------------
Step 1:
Run the following command to setup your build environment:
./setup.sh <TARGET INSTALLATION DIR> [--without-X11]
[--STDLIBS] [--without-OPENJP2] [--32 | --64]
<TARGET INSTALLATION DIR> is replaced by the specific directory path
where you want to install the NBIS applications, libraries,
pre-computed runtime data and manuals.
Option Usage :
--without-X11 Build without X11 support.
--STDLIBS Build without JASPER, OpenJP2 and PNG
image format support.
--without-OPENJP2 Build without OpenJP2 image format
support.
--32 Build on 32-bit architecture machine.
(Only applicable for LINUX build.
If you are compiling on a 64-bit
machine, please have the proper
32-bit libraries installed.)
--64 Build on 64-bit architecture machine
(Only applicable for LINUX build.)
Example:
> ./setup.sh /SRC/NBIS/Main --32
Step 2:
Run the following commands to build "NBIS":
make config
make it
Step 3:
Run the following command to install NBIS executables into the
directory:
make install LIBNBIS=[yes|no]
Step 4: (OPTIONAL)
Run the following command, if you want to generate a list of
API supported in NBIS.
make catalog
Note: If you enable the "LIBNBIS=no" option during make install,
it will create the following libraries:
liban2k.a libclapck.a libfft.a libioutil.a libmindtct.a
libnfseg.a libpcautil.a libutil.a libbozorth3.a libf2c.a
libihead.a libjpegb.a libmlp.a libopenjp2.a libpcax.a
libwsq.a libcblas.a libfet.a libimage.a libjpegl.a libnfiq.a
libpca.a libpng.a libz.a
If you enable the "LIBNBIS=yes" option during make install, it will
combine all the libraries listed above and build libnbis.a.
Can I use the library build using above in my xCode project for iOS.
Thank You,
Subhash

Related

How to package bazel project when it depends on #bazel_tools?

I have an example bazel project that I want to package as tar (to further distribute through homebrew etc...). The project consists of some python files, and a a run shell script.
When trying to use rules_pkg, I run into the following problem - the run script, b.sh, depends on #bazel_tools/tools/bash/runfiles/runfiles.bash to resolve the location of the binary package. #bazel_tools is not provided by default when using #rules_pkg.
What would be the correct approach for creating a distribution of the project above?

Using ZMQ on iOS

I am trying to build an iOS app that is exposed to a fairly extensive Rust project, but I am having issues with one of the dependencies in the project. The Rust project has a ZMQ dependency, and while I am able to build the project on my Mac, when I try to incorporate the Rust project I get the following error:
error: failed to run custom build command for `zmq-sys v0.8.3`
Caused by:
process didn't exit successfully: `/Users/lisa/company/project/project_detail/target/debug/build/zmq-sys-16dfc88dff84d855/build-script-build` (exit status: 101)
--- stdout
cargo:rerun-if-env-changed=LIBZMQ_NO_PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_aarch64-apple-ios
cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_aarch64_apple_ios
cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_ALLOW_CROSS
cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS
cargo:rerun-if-env-changed=PKG_CONFIG_aarch64-apple-ios
cargo:rerun-if-env-changed=PKG_CONFIG_aarch64_apple_ios
cargo:rerun-if-env-changed=TARGET_PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_aarch64-apple-ios
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_aarch64_apple_ios
cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_SYSROOT_DIR
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
--- stderr
thread 'main' panicked at 'Unable to locate libzmq:
pkg-config has not been configured to support cross-compilation.
Install a sysroot for the target platform and configure it via
PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_PATH, or install a
cross-compiling wrapper for pkg-config and set it via
PKG_CONFIG environment variable.', /Users/lisa/.cargo/registry/src/github.com-1ecc6299db9ec823/zmq-sys-0.8.3/build.rs:31:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
I am trying to build the appropriate library for the iOS and iOS simulator architectures without relying on pkg-config, but if someone can provide useful instructions for configuring pkg-config for cross-compilation, I am not opposed to it, I just don't know how and can't find any up to date resources.
I have cloned the libzmq project from this github: https://github.com/zeromq/libzmq.git, then navigate into libzmq.
Inside libzmq, I run ./autogen.sh followed by ./configure --prefix [directory location] --target "aarch64-apple-ios", then make and make install.
The above procedure without the --target flag is how I got the project to compile on my Mac in the first place, and with the target flag in place make and make install both complete successfully, but when I try to build the project using PROJECT_DIR="${PWD}/ProjectName" ./ProjectName/build-rust.sh,
I get the previously posted error.
I am following the Swift-Bridge Book (https://chinedufn.github.io/swift-bridge/building/xcode-and-cargo/index.html) to try to load the Rust libraries into Xcode.
One thing to note: In the libzmq git hub, there is a folder called builds/ios/ and inside this folder is what looks to be a build file for all of the iOS archs, but I haven't been able to get the repo to build with that file. I think figuring out how to use the build_ios.sh build file as opposed to the standard build.sh provided might be the answer, but I've tried dropping build_ios.sh where build.sh is, and ./autogen.sh doesn't work, because it complains that it can't find configure.ac, even though this file does exist.

Electron executable not recognized by Nautilus

I'm not able to build an executable file of an Electron App with the following command:
electron-packager . electron-tutorial-app --overwrite --asar=true --platform=linux --arch=x64 --prune=true --out=release-builds
The build file, which is a shared library file (application/x-sharedlib), is not executing on Ubuntu 18. Instead, I'm getting the following error message when opening the file in Nautilus:
Could not display "electron-tutorial-app"
There is no application installed for "shared library" files. Do you
want to search for an application to open this file?
[No] [Yes]
Is there any way around to do this?
TL;DR: the produced files are actually executables of a new format. There's nothing wrong with them. Nautilus/file managers mistakenly don't recognize them as executables. There are solutions, such as creating a *.desktop file to launch the application.
Analysis
This phenomenon occurs as a side-effect of a change in how Electron builds Linux binaries. The commit 9294facf changed the binary format from ELF to PIE. The change is quite small and only affects a single file (BUILD.gn). The change has landed in Electron starting with version 4.0.0.
File managers utilize the file command to decide what to do with a file (e.g. open an image viewer, a text editor or execute the file). file cannot distinguish between shared libraries and PIE executables and therefore misclassifies PIE files (see the corresponding bug report).
Solutions
Run from terminal
Since the problem only exists for graphical file managers, you can simply run the executable from the terminal or from a script. This is somewhat involved for non-technical end users and not what the OP wants.
Wait for upstream fix
Wait for file to recognize PIE as executable files. In turn, this will likely lead to file managers such as Nautilus to launch the PIEs correctly. It's not clear if or when this will happen. If it happens, it will likely only be included in future distro releases.
Use a desktop file
Create a desktop file to launch the application. This is a common way desktop applications are launched anyway.
Create a file called myapp.desktop with the following contents.
[Desktop Entry]
Name=My Application
Exec=/path/to/binary
Terminal=false
Type=Application
StartupNotify=true
Encoding=UTF-8
Then, mark the desktop file executable by issuing chmod +x myapp.desktop. Double clicking the file should launch the application as expected.
Further information
The corresponding discussion in the electron-packager project: https://github.com/electron-userland/electron-packager/issues/901. (Gist: This issue was not caused by electron-packager, look upstream)
The corresponding issue in the electron project is https://github.com/electron/electron/issues/15406. (Gist: they wanted to enable PIE on Linux. Not our bug, look upstream)
For Linux(Ubuntu):
Downgrade Electron package:
npm install electron#3.1.6 --save-dev
For global (If needed)
npm install -g electron#3.1.6
Execute electron-packager command - for linux:
electron-packager . electron-tutorial-app --overwrite --asar --platform=linux --arch=all --prune=true --out=release-builds
This will result in 4 Linux folders(arch=all). Select a working executable according to your OS.
This is an issue when electron-packager is used to package a Linux app with Electron version 4.0.x, whereas there was no problem with previous Electron versions, such as 3.1.x.
For some reason, in Electron 4.0.x, the produced app file is a shared library instead of an executable.
From a Terminal window, running the file command on the app file path gives:
ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0,
BuildID[sha1]=b9e8ba37118dad1bf605affef41026f813215bc6, stripped
while it used to be:
ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32,
stripped
Fortunately, it is still possible, albeit cumbersome, to run the app by launching it from a Terminal window, for instance by dragging the app file icon onto the terminal prompt, then typing Enter.

How to include a own libary into the toolchain(SDK) for an embeeded Linux generated by Yocto?

I am looking for an example where is shown how to include an own library into the toolchain.
Let's call the library "myLib". For it I created an recipe "myLib.bb" and added:
BBCLASSEXTEND = "native nativesdk"
In my "local.conf" I added:
IMAGE_INSTALL_append = " myLib"
When building the SDK by:
$ bitbake myTarget -c populate_sdk
It produces a installer for the SDK and two manifest files. "myLib" is only included at the target manifest and not on the host. How can I include myLib on the host system?
The idea is, that a other person can build software on his system without the Yocto system. Only by using the toolchain he can generate binaries, which can be transferred and executed at the evalboard.
As long as your library myLib is installed into the image, it's supposed to be part of your generated SDK. Which you also say that it is, at least as part of the target manifest.
Ensure that you install the required header files for your library, then you should be able to cross-compile against your library.
Do you need to use myLib on the developers build machine? Otherwise, why do you want to have it added to the nativeskd part? (I.e. the host manifest). This is for applications that needs to run on the host machine, i.e. the cross-compiler, code generators etc.

How do I compile libffi for iOS & macOS?

I'm trying to use libffi in one of my projects, but I can't seem to compile for iOS (or macOS, for that matter). Here is one of the various errors I've encountered while building for the iOS Simulator:
bash: src/arm/gentramp.sh: No such file or directory
Update 1: Since the question remains unanswered, I've decided to open an issue at the official repository as well.
Update 2: Question has been answered and the issue has been closed!
If you check the repository you will see that the file you require was deleted in this commit. You can find the last version of this file here.
generate-darwin-source-and-headers.py and the libffi.xcodeproj need to be updated to include all currently relevant source files.
The gentramp.sh script is not needed anymore and the current upstream xcodeproj is not up to date either with compilation settings and to be included source files for 64-bit on iOS. A patched fork can be found at https://github.com/ksjogo/libffi
sh autogen.sh
python generate-darwin-source-and-headers.py --only-ios
open libffi.xcodeproj
select scheme libffi-iOS and device Generic iOS Device
click "Product - Build"
If success, you would see a "Product/libffi.a" in the side bar, you can right click it to get the lib in the finder.
Please make sure you are following the installing libffi instructions released on the TBD or git project: https://github.com/libffi/libffi
Here some of the main Highlights:
First you must configure the distribution for your particular
system. Go to the directory you wish to build libffi in and run the
"configure" program found in the root directory of the libffi source
distribution.
If you're building libffi directly from version control, configure won't
exist yet; run ./autogen.sh first.
You may want to tell configure where to install the libffi library and
header files. To do that, use the --prefix configure switch. Libffi
will install under /usr/local by default.
If you want to enable extra run-time debugging checks use the the
--enable-debug configure switch. This is useful when your program dies
mysteriously while using libffi.
Another useful configure switch is --enable-purify-safety. Using this
will add some extra code which will suppress certain warnings when you
are using Purify with libffi. Only use this switch when using
Purify, as it will slow down the library.
For iOS builds, the 'libffi.xcodeproj' Xcode project is available.
Configure has many other options. Use "configure --help" to see them all.
Once configure has finished, type "make". Note that you must be using
GNU make. You can ftp GNU make from ftp.gnu.org:/pub/gnu/make .
To ensure that libffi is working as advertised, type "make check".
This will require that you have DejaGNU installed.
To install the library and header files, type "make install".
Alternatively, try merging one of the following git projects to your project in order to include the missing files. Please make sure the files are not outdated before merging.
1 https://github.com/pandamonia/libffi-iOS
2 https://github.com/influitive/libffi-iOS
3 https://github.com/landonf/libffi-ios

Resources