GraalVM native-image allow us to convert Java libraries into local executable. It also allow to compile to shared library as mentioned https://www.graalvm.org/docs/Native-Image/user/README
An native image can be built as a standalone executable, which is the
default, or as a shared library by passing --shared to native-image.
For an image to be useful, it needs to have at least one entry point
method.
The closest thread I found is this one https://github.com/oracle/graal/issues/373, but still can't find any guide to do so for iOS, is that possible? Any guide I can follow?
Related
I'm trying to setup the files from LuaBinaries (specifically Lua 5.2.4 64-bit), and there are a few things I'm confused about.
There are two zip files provided, the binaries: lua-*_Win*_bin.zip and the libraries: lua-*_Win*_*_lib.zip
So, these are my questions:
For the libraries, two versions are provided, static and dynamic. What's the difference?
The zip file for the dynamic libraries contains a lua*.dll, but a file with the same name is provided in the zip file for the binaries. Which one should I use?
Some of the library zip files (the older ones?) contains a liblua*.a file, is this supposed to be a misnamed lua*.lib file?
For the libraries, two versions are provided, static and dynamic. What's the difference?
The static library can be embedded into your own program. While the dynamic library is linked to your program, so the system will search for it when running your program. If the search for the dynamic library failed, the system won't be able to run your program correctly.
The zip file for the dynamic libraries contains a lua*.dll, but a file with the same name is provided in the zip file for the binaries. Which one should I use?
The lua*.dll under lua-*_Win*_bin.zip is the dynamic link library(.dll) used by lua.exe and luac.exe. An error will be thrown by Windows if you run lua.exe after deleting it.
Which one should you use? It depends on your purpose. Usually you want to use the static library in you project.
Running different versions of Lua bytecode (e.g., runs the bytecode created by luac v5.1.4 with lua v5.2.4) is forbidden (by checking the header of bytecode files).
Lua sometimes brings breaking changes upon upgrading, and some public APIs vary between different versions. If you build and install Lua from source code, only the binaries and the static library are produced.
Lua is a very tiny language (the static library under Linux is about 356K(v5.1.4) or 440K(v5.3.3), measured by du -sh liblua.a), so embedding the static library with your program is fine for many high-end devices.
If you feel familiar with make command, you can build Lua from source code and load it into your project. Or, just use the static library in your project. (I don't think most Windows users have a lua*.dll in their enviroment.)
Some of the library zip files (the older ones?) contains a liblua*.a file, is this supposed to be a misnamed lua*.lib file?
No, the libxxx.a and libxxx.so is the static and dynamic library naming conventions under *nix systems, like Linux and FreeBSD.
I am trying to use codeblocks to compile the code available here
The thing is every time I try to build and run, I run into the following error:
|/.../head_pose_estimation/opencv2/core/core.hpp|48|fatal error: opencv2/core.hpp: No such file or directory
Does anyone know how I can fix this? Thank you!
You do not have the pre-built (compiled) version of OpenCV, what you currently have are the source files. If you want to do something special with OpenCV (Target/GPU SUpport etc) then you will need to build the framework using an appropriate guide.
If however you simply want to use OpenCV in the most common way then download the pre-built libraries from the OpenCV.org website.
NOTE:
If you are using OpenCV with MinGW compiler, I do not remember if the pre-built is actually pre-built for MinGW. (I dont think they do) In this case you will HAVE to built the libraries. You can find a guide here
Looking at the cross-platform nature of potrace http://potrace.sourceforge.net/, is it possible to compile this for iOS? If so, how?
Yes, it is possible to compile potrace for iOS.
As a matter of fact, most open source libraries using standard (GNU) configure tools that compile on MacOS X will easily compile on iOS, because they are likely free of platform-specific code (e.g. linuxisms) and standard configure tools allow cross-compilation.
You can compile these libraries in the shell by pointing configure to the proper toolchain and SDKs. Paths changed with Mavericks and Xcode 5, but fortunately automated scripts exist for more popular libraries such as expat.
The proposed solution is based on the x2on/expat-ios project on GitHub. Their script fixes expat's config.sub which doesn't know about arm64 target. Do does potrace 1.11's config.sub. However, a simpler approach consists in downloading a more recent version of config.sub. Unlike expat, potrace doesn't seem to need any patch to compile for iOS.
Full script build-potrace.sh is available here:
https://gist.github.com/pguyot/dce18af64a71b93c0204
Please note that potrace is licensed under the GPLv2. You might want to check Is it legal to publish iOS apps under the GNU GPLv3 open-source license? question.
I'm working on porting a library onto AIX. It works on Solaris, Windows and Linux but AIX is giving me headaches. I'm at a point where it builds and runs but I have an issue with some of the libraries it's linking in. Ideally I want to be able to ship a library that just requires the c runtime to be available with no other dependencies. At the moment I'm having a problem with libpthread which I can see is a symlink to an AIX specific threading library.
My issue is this:
If I don't link pthread (I don't seem to need to on Solaris for the same code base) then I get undefined symbols. That's fine I am using pthreads. If I link it in then it works fine, except that any calling application also has to link to pthreads. I don't really understand is why does my calling app, which has no dependency on pthread, need to link against it just because it's calling a library which links to the shared object?
I'm on AIX 6.1 using gcc 4.2.4.
I'd be OK with shipping a library that requires pthreads to be present on the library path (ideally we'd get a static version) but I'm a bit unhappy about shipping a library that places linker rqeuirements on the client.
Any ideas on what I might be doing wrong?
I defeinitely seem to be going in circles. I removed the -shared flag on the linker to resolve an earlier problem and that, of course, makes the library static. So the behaviour is just normal behaviour in that if you depend on a dynamic library from a static one you have to link both into your app. So I've put the shared flag back and now half of my functions are no longer accessible. It does explain the problem I was seeing though.
Has anyone used Bluetooth on Mac OS X with Lazarus or FreePascal? There is a bluetooth unit, but it currently only supports Linux.
Information about existing unit:
http://wiki.freepascal.org/Bluetooth
I plan to enhance this to support Mac OS, but it would be nice to know if anyone has written any code to use BlueTooth on Mac OS already to avoid duplicated work.
On the other hand, if you have used XCode to access Bluetooth, what libraries did you use? I am sure I can discover this with the XCode profiler by opening some Bluetooth applications.
Note: Mac OS X doesn't appear to use the BlueZ library that Linux has, so I don't think the solution is as easy as changing the library path. Instead, it has IOBluetooth "Framework", located at /System/Library/Frameworks/IOBluetooth.framework.
Having a look, it looks like:
kaikei.ocn.ntt.com:IOBluetooth.framework $ file *
CodeResources: XML document text
Headers: directory
IOBluetooth: Mach-O universal binary with 3 architectures
IOBluetooth (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
IOBluetooth (for architecture i386): Mach-O dynamically linked shared library i386
IOBluetooth (for architecture ppc7400): Mach-O dynamically linked shared library ppc
Resources: directory
Versions: directory
On the other hand, I think if anyone had done this already, I would probably be able to find it on Google.... On the off chance I am wrong, please reply and let me know.
Clarification: I have created bindings for normal shared libraries before (f.e. sqlite3), but not for a "framework". If nobody has created bindings or otherwise used the MacOS Bluetooth framework from FreePascal, advice on how to use framework functions from FreePascal in general woule be appreciated. (And normally the functions I am porting are C based, not Obj-C, so I am not sure how to declare Obj-C methods in FPK, although I am sure I will be able to find some samples if I keep searching).
The main svn repository for translated Mac OS X framework C headers is http://svn.freepascal.org/svn/macosxintf/trunk
From time to time, FPC releases are synchronised with the latest versions hosted there. Note that the files in that repository (in the MPPInterfaces subdirectory) are in a generic format that can be automatically translated into either FPC, GPC or CodeWarrior Pascal versions.
To generate the FPC versions, use "make fpcpinterfaces", and find the results in the Build/FPCPinterfaces folder.
To translate new headers, execute something like this from inside a checked out copy of the macosxintf repository:
./Scripts/Convert.pl /System/Library/Frameworks/IOBluetooth.framework/Headers/IOBluetooth.h FORCE MPPInterfaces
Afterwards, you'll still have to edit the resulting file to add/remove units and clean up some other things not handled by the automatic translation process. Once finished, you may want to submit a bug report at bugs.freepascal.org with the finished units.
(note: because I'm unregistered, I can only add in one url per post, so the next url's are a bit mangled to get around that restriction)
You can also subscribe to the Mac Pascal list (lists.sonic.net/mailman/listinfo/mac-pascal) and ask there whether someone already translated those headers.
The Bluetooth framework indeed also contains some Objective-C headers. Objective-Pascal support is only available in the latest FPC svn versions, as described on the FPC wiki (google FPC_PasCocoa). You need this support in order to interface with Objective-C.
Translating Objective-C is probably easiest using the script elsewhere in FPC's svn (svn.freepascal.org/svn/fpc/trunk/packages/cocoaint/utils/)
You may want to ask for help on the above-mentioned Mac Pascal list, as all people maintaining the aforementioned translations and translation tools are subscribed there.